On 1/31/12 1:16 AM, "Laine Stump" <laine@xxxxxxxxx> wrote: > On 01/30/2012 08:16 PM, Roopa Prabhu wrote: >> Laine, I haven't gone through your whole email yet. Was just curious about >> one quick thing, >> >> For sriov VF's, are we expecting that a net device (eth interface) be >> present on the host if its being used as a hostdev ?. > > > Either should be possible. If the VF is bound to a net dev, it can be > specified either with dev='ethxx' or using its pci address, and will be > unbound before assigning to the guest. If it's not bound to a net dev, > then a pci address must be used to describe it in the config. > > >> If yes, then libvirt >> will need to do an unbind of the driver on the VF before assigning it to the >> VM. Which today it does not do (correct me if I am wrong). > > > That may have been the case in the past, but with libvirt-0.9.9 (the > first version that I've tested with sriov and PCI passthrough - I'm a > newbie to both), the net driver is unbound prior to assigning to the > guest, and when the the device is detached from the guest, the net > driver is once again bound to the device. > > >> Which is still >> ok. Just wanted to call that out. >> Plus ideally it would be nice to not have an expectation that a vf netdevice >> be present on the host. Because for sriov vf's, it would mean that the vf >> driver has to be loaded on the host. Which is really not required for vfs >> because mac and port profile can be set via the pf with the vf index as >> argument. > > Right. For sriov VFs, I intend that the MAC address will always be set > via the PF. I hadn't previously thought through the details for > non-sriov devices, but your event sequence list below made me realize > that, at least for non-sriov, the MAC address and virtual port setup > will need to be done *before* unbinding the driver (my intent, for sriov > at least, was that this would happen *after* unbinding the driver). I > guess that will take some experimentation. > > Anyway, at the moment I'm slogging around in the data structures. > ok. Thanks Laine. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list