Re: [PATCH-for-5.0 1/2] hw/acpi/piix4: Add 'system-hotplug-support' property

[Philippe Mathieu-Daudé]

On 8/3/20 7:33 PM, Marcelo Tosatti wrote:
> On Mon, Aug 03, 2020 at 07:10:11PM +0200, Philippe Mathieu-Daudé wrote:
>> Hi Igor, Paolo.
>>
>> On 3/23/20 12:04 PM, Marcelo Tosatti wrote:
>>> On Mon, Mar 23, 2020 at 09:05:06AM +0100, Paolo Bonzini wrote:
>>>> On 22/03/20 17:27, Philippe Mathieu-Daudé wrote:
>>>>>>>
>>>>>> That 'ugly' is typically used within QEMU to deal with such things
>>>>>> probably due to its low complexity.
>>>>>
>>>>> OK. Can you point me to the documentation for this feature? I can find
>>>>> reference of GPE in the ICH9, but I can't find where this IO address on
>>>>> the PIIX4 comes from:
>>>>>
>>>>> #define GPE_BASE 0xafe0
>>>>
>>>> It's made up.  The implementation is placed in PIIX4_PM because it is
>>>> referenced by the ACPI tables.  Real hardware would probably place this
>>>> in the ACPI embedded controller or in the BMC.
>>>>
>>>> Paolo
>>>
>>> Yes, there was nothing at 0xafe0 at the time ACPI support was written.
>>>
>>
>> Igor earlier said:
>> "it's already pretty twisted code and adding one more knob
>> to workaround other compat knobs makes it worse."
>>
>> Is that OK to rename this file "hw/acpi/piix4_twisted.c" and
>> copy/paste the same content to "hw/acpi/piix4.c" but remove the
>> non-PIIX4 code (GPE from ICH9)?
>>
>> This seems counterproductive from a maintenance PoV, but the PIIX4 bug
>> (https://bugs.launchpad.net/qemu/+bug/1835865) is more than 1 year old
>> now...
>>
>> If someone has a clever idea, I'm open to listen and implement it, but
>> keeping ignoring this issue is not good.
>>
>> Note there is a similar issue with the LPC bus not existing on the
>> PIIX, so maybe renaming this to something like "piix_virt.c" and having
>> someone writing the specs (or differences with the physical datasheet)
>> is not a such bad idea.
>>
>> Thanks,
>>
>> Phil.
> 
> Make the port address architecture specific ? 

I find it worse than using a property set on the PC machine only
(that would make the piix4 compiled for each target instead on only
once in common-obj as now). But if Igor is OK with that, I don't
mind much, let's move forward.

Thanks,

Phil.