qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gabriel L. Somlo
Subject: Re: [Qemu-devel] [RFC PATCH v2] qemu: x86: ignore ioapic polarity
Date: Sun, 2 Mar 2014 11:15:15 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

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 <address@hidden>
> 
> 
> Acked-by: Michael S. Tsirkin <address@hidden>
> Reviewed-by: Michael S. Tsirkin <address@hidden>
> 
> 
> 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.

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

> 
> 
> > ---
> > 
> > > 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]