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

[Marcelo Tosatti <mtosatti@redhat.com>]

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 ?