Re: [Qemu-devel] [RFC PATCH v2] qemu: x86: ignore ioapic polarity

["Michael S. Tsirkin" <mst@redhat.com>]

On Sun, Mar 02, 2014 at 11:15:15AM -0500, Gabriel L. Somlo wrote:
> On Sun, Mar 02, 2014 at 04:52:22PM +0200, Michael S. Tsirkin wrote:
> > On Fri, Feb 28, 2014 at 01:57:19PM -0500, Gabriel L. Somlo wrote:
> > > Both QEMU and KVM have already accumulated a significant number of
> > > optimizations based on the hard-coded assumption that ioapic polarity
> > > will always use the ActiveHigh convention, where the logical and
> > > physical states of level-triggered irq lines always match (i.e.,
> > > active(asserted) == high == 1, inactive == low == 0). QEMU guests
> > > are expected to follow directions given via ACPI and configure the
> > > ioapic with polarity 0 (ActiveHigh). However, even when misbehaving
> > > guests (e.g. OS X <= 10.9) set the ioapic polarity to 1 (ActiveLow),
> > > QEMU will still use the ActiveHigh signaling convention when
> > > interfacing with the emulated ioapic.
> > > 
> > > This patch modifies the emulated ioapic to completely ignore polarity
> > > as set by the guest OS, enabling misbehaving guests to work alongside
> > > those which comply with the ActiveHigh polarity specified by QEMU's
> > > ACPI tables.
> > > 
> > > Signed-off-by: Gabriel L. Somlo <somlo@cmu.edu>
> > 
> > 
> > Acked-by: Michael S. Tsirkin <mst@redhat.com>
> > Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
> > 
> > 
> > With this, we should be able to change ACPI to specify
> > active-low, which is closer to what real hardware does.
> > But as long as we don't I think there's no need for
> > compatibility with old machine types: we are not
> > breaking any behaviour that wasn't already broken.
> 
> I only really saw ActiveLow on Apple machines' ACPI, though. Not sure
> what the latest-minute PC hardware does, but all late-2000's and
> early-2010's machines I've seen mostly have ActiveHigh in ACPI.

Hmm I experimented a bit and it really seems to depend.

T40 has

            Name (_PRS, ResourceTemplate ()
            {
                IRQ (Level, ActiveLow, Shared, )
                    {3,4,5,6,7,9,10,11}
            })


same for 520
            Name (_PRS, ResourceTemplate ()  // _PRS: Possible Resource Settings
            {
                IRQ (Level, ActiveLow, Shared, )
                    {3,4,5,6,7,9,10,11}
            })

same on several intel servers I have around:
        Name (PRSA, ResourceTemplate ()
        {
            IRQ (Level, ActiveLow, Shared, )
                {3,4,5,6,10,11,12,14,15}
        })



however some AMD boxes I have set polarity dependending on
_PIC method:
active hih for apic mode and active low for pic mode.



> I guess I'd leave ACPI ActiveHigh, these patches are about what
> happens when some stubborn guest OS decides to ignore ACPI :)
> 
> Who knows, in another 5 years and two OS X versions they might start
> actually checking ACPI just like they started checking CPUID for
> monitor/mwait as of 10.8 :) 
> 
> But if the guest OS is well behaved, then logical == physical
> signaling (with ActiveHigh), and that's easier (at least for me) to
> wrap one's head around :)
> 
> Thanks,
> --Gabriel

I agree this is in any case not urgent, and does not
need to block these patches.


> > 
> > 
> > > ---
> > > 
> > > > OK, this would "harmonize" TCG with KVM, in terms of acknowledging
> > > > the realities of hard-coded ActiveHigh behavior throughout the rest
> > > > of the code base.
> > > 
> > > Now with a new and improved commit blurb :)
> > > 
> > > Thanks,
> > >   Gabriel
> > > 
> > >  hw/intc/ioapic.c | 3 ---
> > >  1 file changed, 3 deletions(-)
> > > 
> > > diff --git a/hw/intc/ioapic.c b/hw/intc/ioapic.c
> > > index 652dd47..b527932 100644
> > > --- a/hw/intc/ioapic.c
> > > +++ b/hw/intc/ioapic.c
> > > @@ -93,9 +93,6 @@ static void ioapic_set_irq(void *opaque, int vector, int level)
> > >          uint32_t mask = 1 << vector;
> > >          uint64_t entry = s->ioredtbl[vector];
> > >  
> > > -        if (entry & (1 << IOAPIC_LVT_POLARITY_SHIFT)) {
> > > -            level = !level;
> > > -        }
> > >          if (((entry >> IOAPIC_LVT_TRIGGER_MODE_SHIFT) & 1) ==
> > >              IOAPIC_TRIGGER_LEVEL) {
> > >              /* level triggered */
> > > -- 
> > > 1.8.1.4