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 ?