On Wed, Nov 03, 2010 at 09:51:10AM +0100, Jan Kiszka wrote: > Am 03.11.2010 09:43, 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. > > I understand the problem, but I don't get why the kernel should bother. > User space has to filter the config space access, returning precisely > the value of the INTx disabled bit that the guest wrote. Yes but if guest disables INTx it should not get interrupts :) > > > > 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? > > You mean on the guest IRQ line (host-side sharing is obviously fine)? > Don't know, but that wouldn't be a new issue. Need to study the sources > /wrt IRQ line arbitration and concurrent use. > > Jan > -- 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
