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:41 +0100, Roger Pau Monne wrote:
> 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, 

.. by calling setdefaults though.

I'd like to keep all such logic in setdefaults as far as possible.

libxl__devic_nic_setdefautls is an internal function so we can add
either a domid or type parameter quite easily. Are there any callsites
which would be unable to provide one or the other of those?

Probably domid is best, with setdefaults calling libxl__domain_type as
necessary.

> 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