qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH for-7.1] hw/mips/malta: turn off x86 specific features of PII


From: BB
Subject: Re: [PATCH for-7.1] hw/mips/malta: turn off x86 specific features of PIIX4_PM
Date: Thu, 04 Aug 2022 23:32:45 +0200
User-agent: K-9 Mail for Android


Am 3. August 2022 20:00:18 MESZ schrieb Peter Maydell 
<peter.maydell@linaro.org>:
>On Wed, 3 Aug 2022 at 18:26, Bernhard Beschow <shentey@gmail.com> wrote:
>>
>> On Tue, Aug 2, 2022 at 8:37 AM Philippe Mathieu-Daudé via 
>> <qemu-devel@nongnu.org> wrote:
>>>
>>> On 28/7/22 15:16, Igor Mammedov wrote:
>>> > On Thu, 28 Jul 2022 13:29:07 +0100
>>> > Peter Maydell <peter.maydell@linaro.org> wrote:
>>> >
>>> >> On Thu, 28 Jul 2022 at 12:50, Igor Mammedov <imammedo@redhat.com> wrote:
>>> >>> Disable compiled out features using compat properties as the least
>>> >>> risky way to deal with issue.
>>>
>>> So now MIPS is forced to use meaningless compat[] to satisfy X86.
>>>
>>> Am I wrong seeing this as a dirty hack creeping in, yet another
>>> technical debt that will hit (me...) back in a close future?
>>>
>>> Are we sure there are no better solution (probably more time consuming
>>> and involving refactors) we could do instead?
>>
>>
>> Working on the consolidation of piix3 and -4 soutbridges [1] I've stumbled 
>> over certain design decisions where board/platform specific assumptions are 
>> baked into the piix device models. I figure that's the core of the issue.
>>
>> In our case the ACPI functionality is implemented by inheritance while 
>> perhaps it should be implemented using composition. With composition, the 
>> ACPI functionality could be injected by the caller: The pc board would 
>> inject it while the Malta board wouldn't. This would solve both the crash 
>> and above design problem.
>>
>> I'd be willing to implement it but can't make any promises about the time 
>> frame since I'm currently doing this in my free time. Any hints regarding 
>> the implementation would be welcome, though.
>
>
>For the 7.1 release (coming up real soon now) can we get consensus
>on this patch from Igor as the least risky way to at least fix
>the segfault ? We can look at better approaches for 7.2.

Hi,

My proposal isn't 7.1 material. I merily intended to start a design discussion 
how to proceed after 7.1 that would make Phil's maintainer life easier and 
provide further insights for my consolidation work.

I don't feel qualified enough to judge the impact of Igor's patch, so I'd leave 
that for the competent.

Best regards,
Bernhard

>
>thanks
>-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]