From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bader Subject: Re: [libvirt] Setting devid for emulated NICs (Xen 4.3.1 / libvirt 1.2.0) using libxl driver Date: Fri, 20 Dec 2013 12:04:57 +0100 Message-ID: <52B42459.3080609@canonical.com> References: <52B07D09.5060008@canonical.com> <1387299534.1025.19.camel@dagon.hellion.org.uk> <52B08AA9.8010809@canonical.com> <1387369646.27441.129.camel@kazak.uk.xensource.com> <52B19F4E.8010601@canonical.com> <1387373284.28680.18.camel@kazak.uk.xensource.com> <52B1B842.4090306@canonical.com> <52B2415A.3030903@suse.com> <1387448340.9925.30.camel@kazak.uk.xensource.com> <52B3278D.3000607@canonical.com> <52B33D6C.6010608@suse.com> <1387534262.17289.34.camel@kazak.uk.xensource.com> <52B41BED.5000808@canonical.com> <1387535806.17289.50.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0456092593948240062==" Return-path: In-Reply-To: <1387535806.17289.50.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============0456092593948240062== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dvtGUVoRitJ0QjaO0m6nFHKeBKQcIr3Aw" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dvtGUVoRitJ0QjaO0m6nFHKeBKQcIr3Aw Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 20.12.2013 11:36, Ian Campbell wrote: > On Fri, 2013-12-20 at 11:29 +0100, Stefan Bader wrote: >> On 20.12.2013 11:11, 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 od= d things when >>>>> moving from xm to xl stack from libvirt: libvirt defaults to the ne= tfront 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 unle= ss >>>> 'type=3Dnetfront' is explicitly specified. As you say, the guest ge= ts to >>>> choose what to do with them. E.g. PXE boot using the emulated devic= e, >>>> or have the driver for the PV device unplug the emulated one. I don= 't >>>> think libxl supports this right? >>> >>> It should do, in fact I thought it was the default. >>> >>> How are you initialising the libxl_device_nic? Type =3D=3D 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 libx= l, >>> but I thought they were fixed even before 4.2) >> >> Right now, what I take from libvirt git HEAD, it checks for a set mode= l name. If >> one is set and it is not "netfront", then type gets set to IOMEU, othe= rwise to VIF. >=20 > But there is no "IOEMU" type, only VIF or IOEMU+VIF. >=20 > tools/libxl/_libxl_types.h: LIBXL_NIC_TYPE_UNKNOWN =3D 0, > tools/libxl/_libxl_types.h: LIBXL_NIC_TYPE_VIF_IOEMU =3D 1, > tools/libxl/_libxl_types.h: LIBXL_NIC_TYPE_VIF =3D 2, >=20 >> So currently, by the time the dm gets launched, the xen libxl side cal= ls >> setdefault which in case of an unset model, sets it to rtl8139. The co= de later >> accepts the NIC_TYPE_VIF set already (if unset, the default would be >> NIC_TYPE_VIF_IOEMU). >=20 > If libvirt is asking for NIC_TYPE_VIF then it sounds like libxl is doin= g > as it is asked. >=20 > The model field of libxl_device_nic is irrelevant if the type =3D=3D VI= F, > AFAIK. >=20 >>> I don't think there is an option to have just the emulated device -- >>> there is always a PV VIF there even if the guest doesn't use it. >> >> That is what I end up with when having no specific model in my libvirt= config. >> Which works kind of but prevents any BIOS recognized network. >=20 > It sounds like you have a VIF-only config, which is available, but is > expected to not provide a BIOS usable device (e.g. no emulation). >=20 > What I said was that there is no option to have only an emulated NIC. Oh ok, yes there is not. >=20 >> And libxl does work as xm in the way that having an emulated NIC only = matters >> for early stages. There is always a PV NIC present in parallel which c= auses the >> emulated one to get unplugged when the OS supports this. So right now,= I can >> explicitly set an emulated model in libvirt and then get the emulated = one during >> boot and use the virtual one from within the guest. >=20 > I think someone needs to spell out the precise set of fields which > libvirt is setting in the NIC device in the various cases, because I'm > now confused about what the issue you are seeing even is. I try: config specifies no model or model =3D=3D netfront: - nic->model unset, nic->type =3D NIC_TYPE_VIF config specifies any other mode: - nic->model =3D , nic-type =3D NIC_TYPE_VIF_IOEMU In libxl__device_nic_setdefault: - nic->model unset -> nic->model =3D "rtl8139" - For HWM domain - nic->type unset -> nic-type =3D NIC_TYPE_VIF_IOEMU I am only "complaining" about the case of having no NIC model set in the = libvirt configuration. This sets NIC_TYPE_VIF but leaves nic->model unset. libxl sets the nic->model later but that has no effect because the type i= s set to VIF only. And the default used to be VIF+IOEMU with rtl8139 as model. >=20 > Ian. >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >=20 --dvtGUVoRitJ0QjaO0m6nFHKeBKQcIr3Aw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJStCRZAAoJEOhnXe7L7s6jaH8QAMa6KZO1K1M+MsoLKXRi6Nea +BrsC+ASo+f2t1bRvf4jryQNDsoURMfHqCCRcI+bPITEQrAJLGQGVxiTDJmaAFp8 QrHvwfvY4yOKVLZKkcmLzWXZXolTCOdqCJESkVo8XufftYrC3MLz4nhxeAhKv4Wm z53QRSVhPBkCqFLNt1pwrPGGHiYjarz0nIlLJxjmhbWVPMpkOJ3CNjtT2SR2j8J1 sC3YcHJEO6ngv4dWYp9bJ8OXlluipbrA28am6SQpwcnaELMjeA+d1K3BQ7KeqhFL vPpUam3oCJBxT+X+Ovtbg4VuRXRsgglCxWoZbYk483e7PgPk9PY1GFbWyQagT7ZV 0NL7p431WbOraMi+xACM6TXrUArsabHsjPsYOwvqrVzcbFd3pDdNBLzuAVaZAE5y ZClrEHSbs3MSZGRilpCP3Zzp7usfolPIiLbMS3oAmSuNUH8Tk8zfDnb+Cjw23MfY cL4zKz1NHcraUT6ZV5BZWSFHZkCPumwwph7HQ8g3ha+TLETSNPmnHq+gWIpsV8gV iWqayuPFUH5HEU+v0de7ZFuTJ+1tSvKZR8aX3SO2QG7/llBrRzVKOL2DXrcGh4NO S3sqbOo1u7xC2XtIia2qlefyfcx+3RY66rGNqfisQlpJpzrQzV2TOu17G9gPx8ha nO9HxPFm/0qetKVh9N0V =jvxC -----END PGP SIGNATURE----- --dvtGUVoRitJ0QjaO0m6nFHKeBKQcIr3Aw-- --===============0456092593948240062== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0456092593948240062==--