On Wed, Nov 03, 2010 at 06:27:50PM +0100, Jan Kiszka wrote: > Am 03.11.2010 16:57, Alex Williamson wrote: > > On Wed, 2010-11-03 at 10:43 +0200, Michael S. Tsirkin wrote: > >> On Wed, Nov 03, 2010 at 09:11:16AM +0100, Jan Kiszka wrote: > >>> From: Jan Kiszka <jan.kiszka@xxxxxxxxxxx> > >>> > >>> PCI 2.3 allows to generically disable IRQ sources at device level. This > >>> enables us to share IRQs of such devices between on the host side when > >>> passing them to a guest. This feature is optional, user space has to > >>> request it explicitly. > >>> > >>> Signed-off-by: Jan Kiszka <jan.kiszka@xxxxxxxxxxx> > >> > >> > >> I just realized something. > >> With this patch, if guest ever looks at > >> interrupt disable bit, it will go crazy as that bit goes on/off by > >> itself. I guess we could have an ioctl to set/clear the bit on > >> device, and have qemu call that on config write into command/status > >> register. > >> > >> There's also something I don't completely unerstand with current code: > >> how does interrupt sharing work? E.g. can assigned and emulated > >> devices share an interrupt? > > > > I've been pondering this with VFIO too. There it seems to work, even > > when I enable irqfd. The VFIO kernel/qemu driver needs to filter EOIs > > based on whether the interrupt was actually asserted by the device, but > > I think we're likely relying somewhat on interrupts being reasserted to > > help us keep everything serviced. > > I don't think this filtering exists. The ack notifier that is fired on > EOI matches the GSI, hitting anyone who is registered. > I think the problem is that, while user space properly or's the input of > all PCI devices on a IRQ line (e.g. in piix3_set_irq), kernel-side users > apparently prefer to mess directly with the irqchip. Unless I'm missing > something, that is long broken. > > Jan Well we do check host_irq_disabled. I think this is why it's there. > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
