[libvirt] [PATCH 3/4] virnetdevvportprofile: Changes to support portprofiles for hostdevs

[Laine Stump]

On 03/01/2012 11:55 AM, Stefan Berger wrote:
> On 03/01/2012 11:32 AM, Roopa Prabhu wrote:
>>
>>
>> On 3/1/12 7:52 AM, "Stefan Berger"<stefanb at linux.vnet.ibm.com>  wrote:
>>
>>> On 03/01/2012 10:32 AM, Roopa Prabhu wrote:
>>>>
>>>> On 3/1/12 4:39 AM, "Stefan Berger"<stefanb at linux.vnet.ibm.com>  
>>>> wrote:
>>>>
>>>>> On 03/01/2012 04:02 AM, Roopa Prabhu wrote:
>>>>>> From: Roopa Prabhu<roprabhu at cisco.com>
>>>>>>
>>>>>> This patch includes the following changes
>>>>>> - removes some netlink functions which are now available in
>>>>>> virnetdev.c
>>>>>> - Adds a vf argument to all port profile functions
>>>>>>
>>>>>> For 802.1Qbh devices, the port profile calls can use a vf
>>>>>> argument if
>>>>>> passed by the caller. If the vf argument is -1 it will try to
>>>>>> derive the vf
>>>>>> if the device passed is a virtual function.
>>>>>>
>>>>>> For 802.1Qbg devices, This patch introduces a null check for the
>>>>>> device
>>>>>> argument because during port profile assignment on a hostdev,
>>>>>> this argument
>>>>>> can be null. Stefan CC'ed for comments
>>>>> I agree to the change per se since entering the function with a NULL
>>>>> parameter would be fatal, though I am wondering under what condition
>>>>> this can occur. I don't see this happening in the Associate call path
>>>>> for example.
>>>> It happens in patch 4/4 where we call associate for a hostdev and
>>>> there is
>>>> no macvtap available there.
>>>>
>>> So this hostdev related code can only be used by 802.1Qbh because the
>>> type of device does not exist for 802.1Qbg?
>> Not really. The hostdev device is just a pci device. But looking at
>> 802.1Qbg
>> port profile related code..i was not sure how it can be done when the
>> device
>> is a hostdev.
>
> My guess is that in the 802.1Qbg case we would have to build a macvtap
> device on top of the linkdev to have the macvtap_ifname parameter
> available. Well, maybe the point of intercept would be to check the
> type of profile in 4/4 and make sure it's a 802.1Qbh type and only
> then invoke the function -- like a switch() statement where 802.1Qbh
> type of profile is supported and 802.1Qbg is not (yet).

In the case of hostdev though, there is not necessarily any netdev
driver at all in the host (and thus no "linkdev" to attach a macvtap
to), certainly not after it's attached to the guest - control of the PCI
device is given over to the guest.

So is the problem here that 802.1QbX stuff can only work if there's an
associated macvtap device? Although it might be possible to temporarily
create a macvtap device and attach it to the PCI device's netdev driver
prior to passing it through, that would only work if a netdev driver was
bound to the PCI device (which isn't always the case, especially for
SRIOV VFs), yet that netdev driver would then immediately need to be
unbound prior to assigning the device to the guest, and most likely that
would kill the macvtap device; even if the setup done using that macvtap
device wasn't undone in the process, would it be possible to undo it
later when the guest terminates (or the device is detached from the guest)?

>
>>
>>> I think that at least there
>>> should be an error message logging the fact that the function was
>>> called
>>> without an interface name.  Also the return error code should probably
>>> be -1 and not be overloaded with -E*.
>> Ok This can be done.
>>
>>> If possible (unless already done)
>>> the combination of hostdev and 802.1Qbg should probably even be
>>> prevented on the XML level.
>> This is not done yet. I think I will do it. And then if someone knows
>> how to
>> do it for 802.1Qbg they can open this up.
>>
>
>    Stefan
>
>