From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Gabriel L. Somlo" Subject: Re: [PATCH RFC] kvm: ignore apic polarity Date: Thu, 27 Feb 2014 16:41:03 -0500 Message-ID: <20140227214102.GG17184@ERROL.INI.CMU.EDU> References: <20140211182330.GC29329@ERROL.INI.CMU.EDU> <20140211195444.GB10951@redhat.com> <20140214211311.GH29329@ERROL.INI.CMU.EDU> <20140214220600.GI29329@ERROL.INI.CMU.EDU> <2CEB9F8C-E983-4182-A514-44EC568E18D8@suse.de> <20140216114151.GB30056@redhat.com> <1392562020.15608.437.camel@ul30vt.home> <20140216162300.GI30056@redhat.com> <20140227170549.GA23037@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alex Williamson , "kvm@vger.kernel.org" , "eddie.dong@intel.com" , Alexander Graf , "qemu-devel@nongnu.org" , pbonzini@redhat.com To: "Michael S. Tsirkin" Return-path: Received: from mail-qa0-f44.google.com ([209.85.216.44]:35431 "EHLO mail-qa0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752493AbaB0Vna (ORCPT ); Thu, 27 Feb 2014 16:43:30 -0500 Received: by mail-qa0-f44.google.com with SMTP id f11so4653041qae.31 for ; Thu, 27 Feb 2014 13:43:29 -0800 (PST) Content-Disposition: inline In-Reply-To: <20140227170549.GA23037@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Feb 27, 2014 at 07:05:49PM +0200, Michael S. Tsirkin wrote: > apic polarity in KVM does not work: too many things assume active high. > Let's not pretend it works, let's just ignore polarity flag. If we ever > want to emulate it exactly, this will need a feature flag anyway. > > Also report this to userspace: this makes it > possible to report the interrupt active-low > in ACPI, this way we are closer to real hardware. > > This patch fixes OSX running on KVM. > > Reported-by: "Gabriel L. Somlo" > Signed-off-by: Michael S. Tsirkin > > --- > > Gabriel, could you confirm this fixes OSX for you? > If you can play with linux tweaking interrupt > to active low, that would be very nice too: > it's weekend here. With Fedora 20 Live x86_64: If all I do is 's/ActiveHigh/ActiveLow/' in hw/i386/[q36-]acpi-dsdt.dsl, but otherwise don't try to change how QEMU deals with "logical" vs. "physical" ioapic polarity, things work great. Printk's show polarity set to 1, but with the ignore-polarity patch things work fine. With normal (ActiveHigh) ACPI, printk reports polarity set to 0, and things *still* work exactly the same. So, the way I understand this (and I'm writing this mainly for myself, to make sure I understand correctly, so please kick me if I got it wrong), ACPI tells the guest OS how to configure "physical" ioapic polarity. With ActiveHigh, "physical" == "logical", i.e. "high" == "asserted" and "low" == "deasserted". With ActiveLow, "physical" == !"logical", so the other way around. QEMU being hard-coded to ActiveHigh is the moral equivalent of always sending the kernel (KVM) "logical" line states, rather than "physical" ones. Assuming KVM's userland clients are all coded for ActiveHigh, we can (should, for sanity's sake) just assume line states from userland are logical, and stop paying attention the polarity bits. That way, misbehaving guests [*] can configure their ioapics as they please, and things will just work OK regardless. As you pointed out earlier, even KVM itself already kind-of assumes ActiveHigh (e.g. in __kvm_irq_line_state(), which should be coded differently if ActiveLow were a serious possibility, and, BTW, irq_states[irq] would probably have to be initialized to all-1's if ActiveLow wre used, etc, etc). [*] All Apple hardware is ActiveLow, and OS X has this as a hardcoded assumption (it ignores ACPI's hints to the contrary). So OS X is one of the misbehaving clients I mention above... > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > index 902f124..db29b27 100644 > --- a/include/uapi/linux/kvm.h > +++ b/include/uapi/linux/kvm.h > @@ -674,6 +676,7 @@ struct kvm_ppc_smmu_info { > #define KVM_CAP_ARM_EL1_32BIT 93 > #define KVM_CAP_SPAPR_MULTITCE 94 > #define KVM_CAP_EXT_EMUL_CPUID 95 > +#define KVM_CAP_X86_IOAPIC_POLARITY_IGNORED 96 For one thing, on current kvm git, this conflicts with #define KVM_CAP_HYPERV_TIME 96 but the rest of the patch works (I've already been using it for quite a while to get OS X guests to work... Thanks much, --Gabriel > > #ifdef KVM_CAP_IRQ_ROUTING > > diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c > index 2d68297..ad170b4 100644 > --- a/virt/kvm/ioapic.c > +++ b/virt/kvm/ioapic.c > @@ -328,7 +328,6 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int irq_source_id, > irq_level = __kvm_irq_line_state(&ioapic->irq_states[irq], > irq_source_id, level); > entry = ioapic->redirtbl[irq]; > - irq_level ^= entry.fields.polarity; > if (!irq_level) { > ioapic->irr &= ~mask; > ret = 1; > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60439) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJ8k0-0005Jt-GS for qemu-devel@nongnu.org; Thu, 27 Feb 2014 16:43:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WJ8jq-0000qL-EH for qemu-devel@nongnu.org; Thu, 27 Feb 2014 16:43:40 -0500 Received: from mail-qa0-x22c.google.com ([2607:f8b0:400d:c00::22c]:54279) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJ8jq-0000qH-85 for qemu-devel@nongnu.org; Thu, 27 Feb 2014 16:43:30 -0500 Received: by mail-qa0-f44.google.com with SMTP id f11so4630647qae.3 for ; Thu, 27 Feb 2014 13:43:29 -0800 (PST) Date: Thu, 27 Feb 2014 16:41:03 -0500 From: "Gabriel L. Somlo" Message-ID: <20140227214102.GG17184@ERROL.INI.CMU.EDU> References: <20140211182330.GC29329@ERROL.INI.CMU.EDU> <20140211195444.GB10951@redhat.com> <20140214211311.GH29329@ERROL.INI.CMU.EDU> <20140214220600.GI29329@ERROL.INI.CMU.EDU> <2CEB9F8C-E983-4182-A514-44EC568E18D8@suse.de> <20140216114151.GB30056@redhat.com> <1392562020.15608.437.camel@ul30vt.home> <20140216162300.GI30056@redhat.com> <20140227170549.GA23037@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140227170549.GA23037@redhat.com> Subject: Re: [Qemu-devel] [PATCH RFC] kvm: ignore apic polarity List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: "kvm@vger.kernel.org" , "eddie.dong@intel.com" , Alexander Graf , "qemu-devel@nongnu.org" , Alex Williamson , pbonzini@redhat.com On Thu, Feb 27, 2014 at 07:05:49PM +0200, Michael S. Tsirkin wrote: > apic polarity in KVM does not work: too many things assume active high. > Let's not pretend it works, let's just ignore polarity flag. If we ever > want to emulate it exactly, this will need a feature flag anyway. > > Also report this to userspace: this makes it > possible to report the interrupt active-low > in ACPI, this way we are closer to real hardware. > > This patch fixes OSX running on KVM. > > Reported-by: "Gabriel L. Somlo" > Signed-off-by: Michael S. Tsirkin > > --- > > Gabriel, could you confirm this fixes OSX for you? > If you can play with linux tweaking interrupt > to active low, that would be very nice too: > it's weekend here. With Fedora 20 Live x86_64: If all I do is 's/ActiveHigh/ActiveLow/' in hw/i386/[q36-]acpi-dsdt.dsl, but otherwise don't try to change how QEMU deals with "logical" vs. "physical" ioapic polarity, things work great. Printk's show polarity set to 1, but with the ignore-polarity patch things work fine. With normal (ActiveHigh) ACPI, printk reports polarity set to 0, and things *still* work exactly the same. So, the way I understand this (and I'm writing this mainly for myself, to make sure I understand correctly, so please kick me if I got it wrong), ACPI tells the guest OS how to configure "physical" ioapic polarity. With ActiveHigh, "physical" == "logical", i.e. "high" == "asserted" and "low" == "deasserted". With ActiveLow, "physical" == !"logical", so the other way around. QEMU being hard-coded to ActiveHigh is the moral equivalent of always sending the kernel (KVM) "logical" line states, rather than "physical" ones. Assuming KVM's userland clients are all coded for ActiveHigh, we can (should, for sanity's sake) just assume line states from userland are logical, and stop paying attention the polarity bits. That way, misbehaving guests [*] can configure their ioapics as they please, and things will just work OK regardless. As you pointed out earlier, even KVM itself already kind-of assumes ActiveHigh (e.g. in __kvm_irq_line_state(), which should be coded differently if ActiveLow were a serious possibility, and, BTW, irq_states[irq] would probably have to be initialized to all-1's if ActiveLow wre used, etc, etc). [*] All Apple hardware is ActiveLow, and OS X has this as a hardcoded assumption (it ignores ACPI's hints to the contrary). So OS X is one of the misbehaving clients I mention above... > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > index 902f124..db29b27 100644 > --- a/include/uapi/linux/kvm.h > +++ b/include/uapi/linux/kvm.h > @@ -674,6 +676,7 @@ struct kvm_ppc_smmu_info { > #define KVM_CAP_ARM_EL1_32BIT 93 > #define KVM_CAP_SPAPR_MULTITCE 94 > #define KVM_CAP_EXT_EMUL_CPUID 95 > +#define KVM_CAP_X86_IOAPIC_POLARITY_IGNORED 96 For one thing, on current kvm git, this conflicts with #define KVM_CAP_HYPERV_TIME 96 but the rest of the patch works (I've already been using it for quite a while to get OS X guests to work... Thanks much, --Gabriel > > #ifdef KVM_CAP_IRQ_ROUTING > > diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c > index 2d68297..ad170b4 100644 > --- a/virt/kvm/ioapic.c > +++ b/virt/kvm/ioapic.c > @@ -328,7 +328,6 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int irq_source_id, > irq_level = __kvm_irq_line_state(&ioapic->irq_states[irq], > irq_source_id, level); > entry = ioapic->redirtbl[irq]; > - irq_level ^= entry.fields.polarity; > if (!irq_level) { > ioapic->irr &= ~mask; > ret = 1; > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html