From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: RFC: ioapic polarity vs. qemu os-x guest Date: Sun, 16 Feb 2014 07:47:00 -0700 Message-ID: <1392562020.15608.437.camel@ul30vt.home> References: <20140130204423.GK29329@ERROL.INI.CMU.EDU> <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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Alexander Graf , "Gabriel L. Somlo" , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" , "eddie.dong@intel.com" , pbonzini@redhat.com To: "Michael S. Tsirkin" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:20818 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752280AbaBPOrG (ORCPT ); Sun, 16 Feb 2014 09:47:06 -0500 In-Reply-To: <20140216114151.GB30056@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Sun, 2014-02-16 at 13:41 +0200, Michael S. Tsirkin wrote: > On Fri, Feb 14, 2014 at 11:13:04PM +0100, Alexander Graf wrote: > > > > On 14.02.2014, at 23:06, Gabriel L. Somlo wrote: > > > > > On Fri, Feb 14, 2014 at 10:21:09PM +0100, Alexander Graf wrote: > > >> > > >> Can't you just turn the polarity around in the pci host adapter? > > > > > > I tried this: > > > > > > diff --git a/hw/pci/pci.c b/hw/pci/pci.c > > > index 1221f32..0e86d21 100644 > > > --- a/hw/pci/pci.c > > > +++ b/hw/pci/pci.c > > > @@ -118,13 +118,13 @@ static int pci_bar(PCIDevice *d, int reg) > > > > > > static inline int pci_irq_state(PCIDevice *d, int irq_num) > > > { > > > - return (d->irq_state >> irq_num) & 0x1; > > > + return !(d->irq_state >> irq_num) & 0x1; > > > } > > > > > > static inline void pci_set_irq_state(PCIDevice *d, int irq_num, int level) > > > { > > > d->irq_state &= ~(0x1 << irq_num); > > > - d->irq_state |= level << irq_num; > > > + d->irq_state &= ~(level << irq_num); > > > } > > > > > > static void pci_change_irq_level(PCIDevice *pci_dev, int irq_num, int change) > > > @@ -229,7 +229,7 @@ static void pcibus_reset(BusState *qbus) > > > } > > > > > > for (i = 0; i < bus->nirq; i++) { > > > - assert(bus->irq_count[i] == 0); > > > + assert(bus->irq_count[i] != 0); > > > } > > > } > > > > > > --- > > > > > > but now OS X freezes during boot right after > > > > > > [ PCI configuration begin ] > > > [ PCI configuration end, bridges 1, devices 10 ] > > > RTC: Only single RAM bank (128 bytes) > > > > > > which all looks normal, except the process is supposed to continue on > > > from there and doesn't :) > > > > > > On Linux, I get Fedora 20 live all the way up with no obvious/loud > > > complaints, but mouse and keyboard don't work at all... > > > > > > I have to admit I'm a bit out of my depth here, though :) > > > > Yeah, another thing we have to take into account is vhost-net which generates IRQs directly through irqfd. I guess for those we'll have to configure the polarity in the irq routing table? > > > > > > Alex > > What will be affected is VFIO which uses IRQFD > for level interrupts with KVM_IRQFD_FLAG_RESAMPLE. > I suspect this will need a kernel change, maybe > a new flag for IRQFD: KVM_IRQFD_FLAG_ACTIVE_LOW, > since at the moment that does: > > static void > irqfd_inject(struct work_struct *work) > { > struct _irqfd *irqfd = container_of(work, struct _irqfd, inject); > struct kvm *kvm = irqfd->kvm; > > if (!irqfd->resampler) { > kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 1, > false); > kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 0, > false); > } else > kvm_set_irq(kvm, KVM_IRQFD_RESAMPLE_IRQ_SOURCE_ID, > irqfd->gsi, 1, false); > } As you said in a previous message, devices just want assert & de-assert, 1 & 0, which is what we have here. I would think that what asserted means only needs to be interpreted at the IOAPIC, so I'd hope we could get it right w/o an API change. Thanks, Alex From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59719) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WF2zv-0003hf-3w for qemu-devel@nongnu.org; Sun, 16 Feb 2014 09:47:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WF2zp-00014V-47 for qemu-devel@nongnu.org; Sun, 16 Feb 2014 09:47:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:61186) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WF2zo-00014O-Ru for qemu-devel@nongnu.org; Sun, 16 Feb 2014 09:47:05 -0500 Message-ID: <1392562020.15608.437.camel@ul30vt.home> From: Alex Williamson Date: Sun, 16 Feb 2014 07:47:00 -0700 In-Reply-To: <20140216114151.GB30056@redhat.com> References: <20140130204423.GK29329@ERROL.INI.CMU.EDU> <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> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest 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" , "Gabriel L. Somlo" , pbonzini@redhat.com On Sun, 2014-02-16 at 13:41 +0200, Michael S. Tsirkin wrote: > On Fri, Feb 14, 2014 at 11:13:04PM +0100, Alexander Graf wrote: > > > > On 14.02.2014, at 23:06, Gabriel L. Somlo wrote: > > > > > On Fri, Feb 14, 2014 at 10:21:09PM +0100, Alexander Graf wrote: > > >> > > >> Can't you just turn the polarity around in the pci host adapter? > > > > > > I tried this: > > > > > > diff --git a/hw/pci/pci.c b/hw/pci/pci.c > > > index 1221f32..0e86d21 100644 > > > --- a/hw/pci/pci.c > > > +++ b/hw/pci/pci.c > > > @@ -118,13 +118,13 @@ static int pci_bar(PCIDevice *d, int reg) > > > > > > static inline int pci_irq_state(PCIDevice *d, int irq_num) > > > { > > > - return (d->irq_state >> irq_num) & 0x1; > > > + return !(d->irq_state >> irq_num) & 0x1; > > > } > > > > > > static inline void pci_set_irq_state(PCIDevice *d, int irq_num, int level) > > > { > > > d->irq_state &= ~(0x1 << irq_num); > > > - d->irq_state |= level << irq_num; > > > + d->irq_state &= ~(level << irq_num); > > > } > > > > > > static void pci_change_irq_level(PCIDevice *pci_dev, int irq_num, int change) > > > @@ -229,7 +229,7 @@ static void pcibus_reset(BusState *qbus) > > > } > > > > > > for (i = 0; i < bus->nirq; i++) { > > > - assert(bus->irq_count[i] == 0); > > > + assert(bus->irq_count[i] != 0); > > > } > > > } > > > > > > --- > > > > > > but now OS X freezes during boot right after > > > > > > [ PCI configuration begin ] > > > [ PCI configuration end, bridges 1, devices 10 ] > > > RTC: Only single RAM bank (128 bytes) > > > > > > which all looks normal, except the process is supposed to continue on > > > from there and doesn't :) > > > > > > On Linux, I get Fedora 20 live all the way up with no obvious/loud > > > complaints, but mouse and keyboard don't work at all... > > > > > > I have to admit I'm a bit out of my depth here, though :) > > > > Yeah, another thing we have to take into account is vhost-net which generates IRQs directly through irqfd. I guess for those we'll have to configure the polarity in the irq routing table? > > > > > > Alex > > What will be affected is VFIO which uses IRQFD > for level interrupts with KVM_IRQFD_FLAG_RESAMPLE. > I suspect this will need a kernel change, maybe > a new flag for IRQFD: KVM_IRQFD_FLAG_ACTIVE_LOW, > since at the moment that does: > > static void > irqfd_inject(struct work_struct *work) > { > struct _irqfd *irqfd = container_of(work, struct _irqfd, inject); > struct kvm *kvm = irqfd->kvm; > > if (!irqfd->resampler) { > kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 1, > false); > kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 0, > false); > } else > kvm_set_irq(kvm, KVM_IRQFD_RESAMPLE_IRQ_SOURCE_ID, > irqfd->gsi, 1, false); > } As you said in a previous message, devices just want assert & de-assert, 1 & 0, which is what we have here. I would think that what asserted means only needs to be interpreted at the IOAPIC, so I'd hope we could get it right w/o an API change. Thanks, Alex