[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v2] qemu: x86: ignore ioapic polarity
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [RFC PATCH v2] qemu: x86: ignore ioapic polarity |
Date: |
Sun, 2 Mar 2014 19:09:47 +0200 |
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 <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.
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