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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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.

> This is the main problem, I think it should be ok to leave the default 
> type as IOEMU in libxl__device_nic_setdefault and set the type manually 
> to VIF for PV guests in 
> libxl_create.c:libxl__domain_build_info_setdefault, does this sound ok?

Does buildinfo setdefault have the necessary pointer to get at the vifs?
I don't think it does.

> 
> > Where * == current lib(xl) default and&  == proposed default after this 
> > change.
> > and:
> >          type=ioemu =>      LIBXL_NIC_TYPE_IOEMU to be renamed 
> > LIBXL_NIC_TYPE_VIF_IOEMU.
> >          type=vif =>        LIBXL_NIV_TYPE_VIF, no renaming proposed.
> >
> > But if my table is correct then LIBXL_NIC_TYPE_VIF_IOEMU is the right
> > default and shouldn't be changed. Roger can you either confirm or
> > correct my table.
> >
> > Ian.
> >
> 



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