* Etienne Martineau (etmartin101@xxxxxxxxx) wrote: > > > On Tue, 26 Oct 2010, Chris Wright wrote: > > >>***One of the aspect I'm not clear is the strategy for > >>device-assignment under KVM? > >>A) Move to VFIO; [/dev/iommu, /dev/vfio] > > > >Long term, hopefully VFIO > > > >>B) KVM as a driver for the assigned devices; [sysfs/ ioctls..] > > > >Short term (i.e. current qemu-kvm tree...this is what we have now and > >will continue to until plan A) gets more mature). > > > Strictly speaking, I don't really agree with 'B' being the current > implementation. Correct me if I'm wrong but for assigned devices, > kvm does a look up for the device and eventually obtain a handle to > it (struct pci_dev*) without doing a proper 'pci_register_driver'. OK, not a PCI driver per-se (that's pci-stub), but KVM owns the process of registering interrupt handler, programming iommu, etc. > I think we need to register with PCI and provide > 'pci_error_handlers' callback if we wants to receive AER > notification. Right, and adding more to the existing KVM code which we are hoping to push to legacy support mode doesn't sound like a great idea. > In that context, do you think it's acceptable for KVM to be the > driver of the assigned devices? OR should we simply add the AER > logic into existing pci-stub and relay the information to user-space > through eventfd... I'm reluctant to add logic to pci-stub, but VFIO should be able to handle this directly. thanks, -chris -- 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
