Il 04/09/2013 07:29, liu ping fan ha scritto: > On Tue, Sep 3, 2013 at 7:17 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: >> Il 02/09/2013 09:06, Liu Ping Fan ha scritto: >>> note: I rebase it onto Stefan's net-next tree, since pc-1.7 has already >>> been defined there. >>> >>> v4: >>> use standard compat property to set hpet's interrupt compatibility >>> >>> v3: >>> change hpet interrupt capablity on board's demand >>> >>> >>> Liu Ping Fan (3): >>> hpet: inverse polarity when pin above ISA_NUM_IRQS >>> hpet: entitle more irq pins for hpet >>> pc-1.6: add compatibility for hpet intcap on pc-*-1.6 >>> >>> hw/timer/hpet.c | 27 +++++++++++++++++++++++---- >>> include/hw/i386/pc.h | 5 +++++ >>> 2 files changed, 28 insertions(+), 4 deletions(-) >>> >> >> Looks good. But I have one question; should this be changed for PIIX >> too, or should the 1.7 PIIX machine keep the old behavior? (I have no >> idea). >> > Your suspicion is right. When going through PIIX4 spec, I found that > the chipset was without ioapic integrated. So there is divergence for > the compatibility of pc-piix-* and pc-q35-*. Can I code the hpet's > compatiblity in pc-piix-1.7 to resolve this?
You could do something like what people suggested earlier in the review. Change sysbus_try_create_simple to qdev_try_create/sysbus_mmio_map/qdev_init in pc_basic_device_init (this is one patch, going before v4 3/3). Then add a new argument to pc_basic_device_init, and set the intcap property if the new argument is nonzero (another patch, going before v4 3/3; where the new argument is always 0). Finally, piix can pass 4 for the new argument, while q35 can keep passing 0 (squashed in v4 3/3). In other words, PIIX hardcodes the value 4, while Q35 uses compat properties. I still have a doubt. Can the PIIX HPET use interrupt 8? If so, this won't work and we have to go back to the drawing board. But if it can use interrupt 2 only, it will be okay. Paolo
