All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jim Fehlig <jfehlig@suse.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: libvir-list@redhat.com, Stefan Bader <stefan.bader@canonical.com>,
	Xen-devel@lists.xen.org
Subject: Re: [libvirt] Setting devid for emulated NICs (Xen 4.3.1 / libvirt 1.2.0) using libxl driver
Date: Mon, 23 Dec 2013 23:22:42 -0700	[thread overview]
Message-ID: <52B92832.1030705__48010.4082650088$1387866402$gmane$org@suse.com> (raw)
In-Reply-To: <1387534262.17289.34.camel@kazak.uk.xensource.com>

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?
>>     
>
>
> On my 4.3.1 setup, I changed the above to
>
>
>
>   if (hvm) {
>
>   x_nic->nictype = LIBXL_NIC_TYPE_VIF_IOEMU;
>
>       if (l_nic->model) {
>
>           if (VIR_STRDUP(x_nic->model, l_nic->model) < 0)
>
>       return -1;
>
>           if (STREQ(l_nic->model, "netfront"))
>
>               x_nic->nictype = LIBXL_NIC_TYPE_VIF;
>
>       }
>
>   } else {
>
>       x_nic->nictype = LIBXL_NIC_TYPE_VIF;
>
>   }
>
>
>
> which is better initialization logic IMO.  If the domain is hvm, set
> nictype to LIBXL_NIC_TYPE_VIF_IOEMU, unless model 'netfront' is
> specified.  This behavior is consistent with the legacy xen driver. 
> The change seems to work fine and resolves the PXE issue Stefan noted -
> as long as I initialize devid in libvirt.  So we'll need the above fix
> in libvirt, as well as a resolution to the nic devid initialization in
> libxl that started this thread.
>
>
>
> Regards,
>
> Jim
> It should do, in fact I thought it was the default.
>
> How are you initialising the libxl_device_nic?

  if (l_nic->model && !STREQ(l_nic->model, "netfront")) {
      if (VIR_STRDUP(x_nic->model, l_nic->model) < 0)
          return -1;
      x_nic->nictype = LIBXL_NIC_TYPE_VIF_IOEMU;
  } else {
      x_nic->nictype = LIBXL_NIC_TYPE_VIF;
  }

>  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)
>   

On my 4.3.1 setup, I changed the above to

  if (hvm) {
  x_nic->nictype = LIBXL_NIC_TYPE_VIF_IOEMU;
      if (l_nic->model) {
          if (VIR_STRDUP(x_nic->model, l_nic->model) < 0)
      return -1;
          if (STREQ(l_nic->model, "netfront"))
              x_nic->nictype = LIBXL_NIC_TYPE_VIF;
      }
  } else {
      x_nic->nictype = LIBXL_NIC_TYPE_VIF;
  }

which is better initialization logic IMO.  If the domain is hvm, set
nictype to LIBXL_NIC_TYPE_VIF_IOEMU, unless model 'netfront' is
specified.  This behavior is consistent with the legacy xen driver.  The
change seems to work fine and resolves the PXE issue Stefan noted - as
long as I initialize devid in libvirt.  So we'll need the above fix in
libvirt, as well as a resolution to the nic devid initialization in
libxl that started this thread.

Regards,
Jim

  parent reply	other threads:[~2013-12-24  6:22 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-17 16:34 Setting devid for emulated NICs (Xen 4.3.1 / libvirt 1.2.0) using libxl driver Stefan Bader
2013-12-17 16:58 ` Ian Campbell
2013-12-17 17:32   ` Stefan Bader
     [not found]   ` <52B08AA9.8010809@canonical.com>
2013-12-18 12:27     ` Ian Campbell
     [not found]     ` <1387369646.27441.129.camel@kazak.uk.xensource.com>
2013-12-18 13:12       ` [libvirt] " Stefan Bader
     [not found]       ` <52B19F4E.8010601@canonical.com>
2013-12-18 13:28         ` Ian Campbell
     [not found]         ` <1387373284.28680.18.camel@kazak.uk.xensource.com>
2013-12-18 13:57           ` Stefan Bader
2013-12-18 14:59           ` Stefan Bader
     [not found]           ` <52B1B842.4090306@canonical.com>
2013-12-19  0:44             ` Jim Fehlig
2013-12-19 10:19               ` Ian Campbell
     [not found]               ` <1387448340.9925.30.camel@kazak.uk.xensource.com>
2013-12-19 17:06                 ` Stefan Bader
     [not found]                 ` <52B3278D.3000607@canonical.com>
2013-12-19 17:57                   ` Ian Campbell
2013-12-19 18:39                   ` Jim Fehlig
     [not found]                   ` <52B33D6C.6010608@suse.com>
2013-12-20 10:11                     ` Ian Campbell
     [not found]                     ` <1387534262.17289.34.camel@kazak.uk.xensource.com>
2013-12-20 10:29                       ` Stefan Bader
2013-12-20 10:36                         ` Ian Campbell
2013-12-20 11:04                           ` Stefan Bader
2013-12-20 11:22                             ` Ian Campbell
2014-01-06 21:31                               ` Jim Fehlig
2013-12-24  6:22                       ` Jim Fehlig [this message]
     [not found]                       ` <52B92832.1030705@suse.com>
2014-01-06 21:26                         ` Jim Fehlig
     [not found]                   ` <1387475839.17289.20.camel@kazak.uk.xensource.com>
2013-12-20 10:16                     ` Stefan Bader
     [not found]                     ` <52B41906.7010506@canonical.com>
2013-12-20 10:37                       ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='52B92832.1030705__48010.4082650088$1387866402$gmane$org@suse.com' \
    --to=jfehlig@suse.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=Xen-devel@lists.xen.org \
    --cc=libvir-list@redhat.com \
    --cc=stefan.bader@canonical.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.