[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH-for-5.0 1/2] hw/acpi/piix4: Add 'system-hotplug-support' prop
Re: [PATCH-for-5.0 1/2] hw/acpi/piix4: Add 'system-hotplug-support' property
Mon, 3 Aug 2020 14:33:38 -0300
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
> 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.
Make the port address architecture specific ?