Re: [PATCH v6 10/13] libxl: set nic type to VIF by default

[Roger Pau Monne <roger.pau@citrix.com>]

Ian Campbell wrote:
> On Thu, 2012-06-28 at 10:22 +0100, Roger Pau Monne wrote:
>> Ian Campbell wrote:
>>> On Tue, 2012-06-26 at 17:58 +0100, Pasi Kärkkäinen wrote:
>>>> On Tue, Jun 26, 2012 at 05:20:35PM +0100, Roger Pau Monne wrote:
>>>>> Ian Jackson wrote:
>>>>>> Roger Pau Monne writes ("[PATCH v6 10/13] libxl: set nic type to VIF by default"):
>>>>>>> Set the default value for nic interfaces to VIF, since it used to be
>>>>>>> IOEMU, even for PV guests.
>>>>>> If your renaming of IOEMU to VIF_IOEMU is correct, does this not stop
>>>>>> HVM guests getting emulated network interfaces by default ?
>>>>> Yes, if you want emulated interfaces with HVM guests you should use
>>>>> 'type=ioemu', that's how it has always been right?
>>>>>
>>>> With Xen 4.1 you don't have to use "type=ioemu". Emulated interfaces seem to work OK without "type=ioemu".
>>>> (at least with xm/xend). And if you actually do add "type=ioemu" it will break PVHVM for Linux guests..
>>>>
>>>> Quote from: http://wiki.xen.org/wiki/XenLinuxPVonHVMdrivers
>>>>
>>>> "NOTE! If you have "type=ioemu" specified for the "vif"-line, PVHVM
>>>> drivers WILL NOT work! Don't specify "type" parameter for the vif.
>>>> (with type=ioemu the pvhvm nic in the VM will have mac address full of
>>>> zeroes - and thus won't work!). "
>>> mac=00:00:00:00:00 is certainly a bug, if (lib)xl behaves this way too
>>> then we should fix it.
>>>
>>> But surely type=ioemu is supposed to mean "only emulated"? In which case
>>> the actual xend bug is that it created a PV VIF at all.
>> Currently there's no network type that means "emulated only", we have
>> VIF and VIF_IOEMU.
>
> Ah, ok, yes I'm confused.
>
>>> What are the options here? I think they are, with their (lib)xl
>>> behaviour:
>>>
>>> 		PV				HVM
>>> type=ioemu	meaningless / an error		emulated device + paravirt VIF*
>>> type=vif	paravirt VIF device*&		paravirt VIF device only&
>> You are missing a row, the default one when user doesn't specify
>> anything,
>
> That was supposed to be indicated by the * (now) and&  (after your
> patch) symbols above.
>
>>   this currently is:
>>
>> 	PV				HVM
>> default	nic type is set to IEOMU	nic type is set to IOEMU
>>
>> In the past this was not a problem, since when the guest is PV, we
>> didn't launch Qemu, and thus the tap device was never created and the
>> hotplug scripts were not launched. Now that we launch hotplug scripts
>> from libxl this is a problem, because when we call libxl_device_nic_add,
>> libxl has no idea if the domain is a PV or HVM guest, and only sees the
>> network type, which is set to IOEMU by default.
>
> It has a domid so it can ask and/or propagate it down to setdefaults.

I think the most suitable place is 
libxl_create.c:initiate_domain_create, which also sets the defaults for 
disk devices, so I think it's adequate to place something like:

if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV) {
     for (i = 0; i < d_config->num_vifs; i++) {
         d_config->vifs[i].nictype = LIBXL_NIC_TYPE_VIF;
     }
}


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