On 3/2/12 12:54 PM, "Laine Stump" <laine@xxxxxxxxx> wrote: > On 03/02/2012 03:03 PM, Roopa Prabhu wrote: >> On 3/2/12 11:04 AM, "Laine Stump" <laine@xxxxxxxxx> wrote: >>> On 03/01/2012 04:02 AM, Roopa Prabhu wrote: >>>> This patch series is based on laines patches to support <interface >>>> type='hostdev'>. >>>> https://www.redhat.com/archives/libvir-list/2012-February/msg01126.html >>>> >>>> It support to set mac and port profile on an interface of type hostdev. >>>> * If virtualport is specified, the existing virtual port functions are >>>> called to set mac, vlan and port profile. >>> I'm unable to test that part, as I don't have any 802.1QbX capable >>> switches (and it sounds like the design is problematic anyway.) >>> >> The design is still fine for 802.1Qbh. > > > Yes, my apologies for misinterpreting all the exchanges. > > No problem atall. >> I have tested it. 802.1Qbh does not >> need a macvtap device. For 802.1Qbg in v2 (was planning on pushing it the >> next hr), > > > I'll try to review it as quickly as possible. > > >> I have put a check for 802.1Qbg and hostdevs and fail as suggested >> by stefan. > > > I'm quickly learning that I understood much less about 802.1QbX (and in > particular, how it's been implemented) than I thought! (Fortunately, as > a result of all this, I think I now understand it a bit better). > > And I am understanding 802.1Qbg a bit better now :) >>>> * If virtualport is not specified and device is a sriov virtual function, >>>> - mac is set using IFLA_VF_MAC >>> Success!! I tried this for VFs that have a netdev driver attached, and >>> VFs that don't, and it behaved properly in both cases - when the guest >>> is started, the MAC address is set properly for the guest to use, and >>> when the guest is stopped, the MAC address of that VF is restored to its >>> original value (implying that your code to save the old MAC address >>> works properly). >>> >>> >> Nice. Thanks for trying it out. >> >>>> * If virtualport is not specified and device is a non-sriov virtual >>>> function, >>>> - mac is set using existing SIOCGIFHWADDR (This requires that the >>>> netdev be present on the host before starting the VM) >>> This one has a problem, at least with my non-sriov hardware (which >>> happens to be the onboard NetXtreme device of a Thinkstation, using the >>> tg3 driver) it appears the MAC address gets reset to its original >>> setting at some point after libvirt changes it. To help understand what >>> happens - assume the device's original MAC address is o:o:o:o:o:o, and >>> my xml looks like this: >>> >>> <interface type='hostdev' managed='yes'> >>> <mac address='n:n:n:n:n:n'/> >>> ... >>> </interface> >>> >>> When the guest boots up, ifconfig shows there is an interface with mac >>> address o:o:o:o:o:o. >>> >>> Additionally, if I manually change the mac address to p:p:p:p:p:p on the >>> host before starting the guest, when the guest boots, ifconfig shows the >>> mac address as... o:o:o:o:o:o. So, whether or not libvirt is >>> successfully setting the mac address, it's getting reset (probably by >>> the card's firmware). >> Yes this I kind of expected. It depends on the driver. I thought there are >> some drivers that remember the mac address set by SIOCGIFHWADDR. But my >> assumption was totally based on the fact that we wanted to add support for >> all devices. Having the code there just means we try to set the device mac. >> It takes effect only if the hw supports it. > > If there was just a way to determine that at runtime, but it seems that > by the time the MAC address has been reset, we are no longer able to > call the ioctl to check the address :-( > > >>> So perhaps this is another case of wanting to do something that just >>> isn't possible, and the way out is to simply generate an error on domain >>> startup if the netdev being passed through isn't a VF? >>> >>> >> We can do this too. Only support it for sriov vf's. > > Yes, if it's going to silently do the wrong thing, maybe we should leave > the SIOCGIFHWADDR code in there for reference, but also add a failure > condition if the card isn't SRIOV. Ok. Heres what I will do (If I understand you correctly): - I will call the mac/portprofile set functions for sriov devices only. - Throw an error for non-sriov devices - Keep the mac set code for non-sriov devices around for reference > > (I guess this means my effort to make sure USB ethernets were also > supported was kind of pointless, since they're sure to have the same > problems :-P Mostly I only included that support to promote code sharing > and consistency, though, so I'm not really disappointed.) > :) Thanks Laine. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list