* Etienne Martineau (etmartin101@xxxxxxxxx) wrote: > ***Background context: > We are using kvm on a x86 based platform. For performance reason, we > use devices assignment. The type of devices we have to deal with is > mostly custom ASICs but we also have standard stuff (ex 82599EB > 10-GigabitSR-IOV). > > AER handling in guest VM is very important to us. Most of our > drivers assume timely notification in cases of PCIe AER. Failure to > provide such support will result in very undesireable behavior at > the other end :) > > In our cases, AER is not strictly function of the hardware 'quality' > but also tied to the way the user can interact with the system (by > pulling a card on the fly for example). > > ***Q35, VFIO: > I'm aware of the PCIe Q35 chipset work that Isaku is working on. I > have a college that is working actively on merging the change into > our qemu-kvm branch. > > I'm also familiar with VFIO. I've seen the work from Alex on the > qemu VFIO front. Not too sure how this is going to work on qemu-kvm? > OR maybe it's because I'm confused about the long term plan for user > space [qemu vs qemu-kvm] branch? The Plan (TM) is for qemu-kvm to be just a staging branch for qemu. There are a few bits left in qemu-kvm (I'm sure you're aware since you're working with them ;) that aren't yet upstream. The device assignment code is one of those bits. Ideally, we could get KVM out of the business of being a device driver for assigned host devices and move all of that functionality to VFIO. And when looking at adding significant new functionality like AER, scoping VFIO would be very useful. > ***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). 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
