Re: [Xen-devel] [libvirt] Setting devid for emulated NICs (Xen 4.3.1 / libvirt 1.2.0) using libxl driver

[Stefan Bader <stefan.bader@xxxxxxxxxxxxx>]

On 20.12.2013 11:36, Ian Campbell wrote:
> On Fri, 2013-12-20 at 11:29 +0100, Stefan Bader wrote:
>> On 20.12.2013 11:11, Ian Campbell wrote:
>>> On Thu, 2013-12-19 at 11:39 -0700, Jim Fehlig wrote:
>>>> Stefan Bader wrote:
>>>>> Oh, just while talking about setdefault. Jim, this is one of the odd 
>>>>> things when
>>>>> moving from xm to xl stack from libvirt: libvirt defaults to the netfront 
>>>>> NIC
>>>>> when no model is specified and sets the type. The libxl setdefault 
>>>>> function sets
>>>>> the model to rtl8139 but leaves the type untouched.
>>>>
>>>> The xend toolstack always creates both emulated and vif devices unless
>>>> 'type=netfront' is explicitly specified.  As you say, the guest gets to
>>>> choose what to do with them.  E.g. PXE boot using the emulated device,
>>>> or have the driver for the PV device unplug the emulated one.  I don't
>>>> think libxl supports this right?
>>>
>>> It should do, in fact I thought it was the default.
>>>
>>> How are you initialising the libxl_device_nic? Type ==  VIF_IOEMU (which
>>> is the default for a VIF on an HVM guest) means both emulated and pv.
>>> (there were bugs in the semantics here in very early versions of libxl,
>>> but I thought they were fixed even before 4.2)
>>
>> Right now, what I take from libvirt git HEAD, it checks for a set model 
>> name. If
>> one is set and it is not "netfront", then type gets set to IOMEU, otherwise 
>> to VIF.
> 
> But there is no "IOEMU" type, only VIF or IOEMU+VIF.
> 
> tools/libxl/_libxl_types.h:    LIBXL_NIC_TYPE_UNKNOWN = 0,
> tools/libxl/_libxl_types.h:    LIBXL_NIC_TYPE_VIF_IOEMU = 1,
> tools/libxl/_libxl_types.h:    LIBXL_NIC_TYPE_VIF = 2,
> 
>> So currently, by the time the dm gets launched, the xen libxl side calls
>> setdefault which in case of an unset model, sets it to rtl8139. The code 
>> later
>> accepts the NIC_TYPE_VIF set already (if unset, the default would be
>> NIC_TYPE_VIF_IOEMU).
> 
> If libvirt is asking for NIC_TYPE_VIF then it sounds like libxl is doing
> as it is asked.
> 
> The model field of libxl_device_nic is irrelevant if the type == VIF,
> AFAIK.
> 
>>> I don't think there is an option to have just the emulated device --
>>> there is always a PV VIF there even if the guest doesn't use it.
>>
>> That is what I end up with when having no specific model in my libvirt 
>> config.
>> Which works kind of but prevents any BIOS recognized network.
> 
> It sounds like you have a VIF-only config, which is available, but is
> expected to not provide a BIOS usable device (e.g. no emulation).
> 
> What I said was that there is no option to have only an emulated NIC.

Oh ok, yes there is not.

> 
>> And libxl does work as xm in the way that having an emulated NIC only matters
>> for early stages. There is always a PV NIC present in parallel which causes 
>> the
>> emulated one to get unplugged when the OS supports this. So right now, I can
>> explicitly set an emulated model in libvirt and then get the emulated one 
>> during
>> boot and use the virtual one from within the guest.
> 
> I think someone needs to spell out the precise set of fields which
> libvirt is setting in the NIC device in the various cases, because I'm
> now confused about what the issue you are seeing even is.

I try:

config specifies no model or model == netfront:
 - nic->model unset, nic->type = NIC_TYPE_VIF
config specifies any other mode:
 - nic->model = <name>, nic-type = NIC_TYPE_VIF_IOEMU

In libxl__device_nic_setdefault:
 - nic->model unset -> nic->model = "rtl8139"
 - For HWM domain
   - nic->type unset -> nic-type = NIC_TYPE_VIF_IOEMU

I am only "complaining" about the case of having no NIC model set in the libvirt
configuration. This sets NIC_TYPE_VIF but leaves nic->model unset.
libxl sets the nic->model later but that has no effect because the type is set
to VIF only. And the default used to be VIF+IOEMU with rtl8139 as model.

> 
> Ian.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel
>

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel