[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.