[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [libvirt] Setting devid for emulated NICs (Xen 4.3.1 / libvirt 1.2.0) using libxl driver
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 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? > > > > It should do, in fact I thought it was the default. > > > > How are you initialising the libxl_device_nic? 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) > > Right now, what I take from libvirt git HEAD, it checks for a set model name. > If > one is set and it is not "netfront", then type gets set to IOMEU, otherwise > to VIF. But there is no "IOEMU" type, only VIF or IOEMU+VIF. tools/libxl/_libxl_types.h: LIBXL_NIC_TYPE_UNKNOWN = 0, tools/libxl/_libxl_types.h: LIBXL_NIC_TYPE_VIF_IOEMU = 1, tools/libxl/_libxl_types.h: LIBXL_NIC_TYPE_VIF = 2, > So currently, by the time the dm gets launched, the xen libxl side calls > setdefault which in case of an unset model, sets it to rtl8139. The code later > accepts the NIC_TYPE_VIF set already (if unset, the default would be > NIC_TYPE_VIF_IOEMU). If libvirt is asking for NIC_TYPE_VIF then it sounds like libxl is doing as it is asked. The model field of libxl_device_nic is irrelevant if the type == VIF, AFAIK. > > 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. 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). What I said was that there is no option to have only an emulated NIC. > 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 causes > 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. 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. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |