From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bader Subject: Re: Xen 4.x / Linux 3.x (dom0 and HVM domU) and NIC handling Date: Mon, 05 Dec 2011 15:33:45 +0100 Message-ID: <4EDCD649.8050108@canonical.com> References: <4ED798B2.1040309@canonical.com> <20111201180944.GH12984@reaktio.net> <4ED8A45A.3050403@canonical.com> <20111202104110.GL12984@reaktio.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20111202104110.GL12984@reaktio.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: "xen-devel@lists.xensource.com" , Ian Campbell , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 02.12.2011 11:41, Pasi K=E4rkk=E4inen wrote: > On Fri, Dec 02, 2011 at 11:11:38AM +0100, Stefan Bader wrote: >> On 01.12.2011 19:09, Pasi K=E4rkk=E4inen wrote: >>> On Thu, Dec 01, 2011 at 04:09:38PM +0100, Stefan Bader wrote: >>>> Moving to public discussion... >>>> >>>> This was found with Xen hypervisor version supporting device unpluggin= g and the >>>> domU kernel having net-/blkfront and pci platform built-in (or as modu= le). >>>> >>>> The block device is defined as hda and the NIC type=3Dioemu (so theore= tically >>>> guests without pv support would work, too). >>>> >>>> Since both drivers are present, the kernel tries to unplug the emulate= d devices >>>> and succeeds. The blkfront driver detects the xvda device available in= parallel >>>> and is working ok. >>>> >>>> However the network interface does not work. There are entries present= under >>>> sysfs for the xenbus but trying to bring it up fails with errors. And = also there >>>> seems to be no mac address set (all zeros in sysfs). >>>> When the type=3Dioemu is removed in the configuration, this works. >>>> >>>> I have not much more debugging information beyond that, yet. But it so= unds a bit >>>> like NICs should behave the same as block devices. So if there is an e= mulated >>>> device defined there will be an alternate paravirt interface for it an= d after >>>> unplugging the emulated ones we end up with the pv ones. >>>> Is that something that can be seen with newer Xen versions, too (I am = using 4.1.1)? >>>> >>> >>> Hey, >>> >>> Have you seen?: = >>> http://wiki.xen.org/xenwiki/XenLinuxPVonHVMdrivers >>> >>> Especially the following note: >>> "NOTE! If you have "type=3Dioemu" specified for the "vif"-line, PVHVM d= rivers WILL NOT work! Don't specify "type" parameter for the vif. (with typ= e=3Dioemu the pvhvm nic in the VM will have mac address full of zeroes - an= d thus won't work!)." >>> >>> "type=3Dioemu" is not needed, at least with xm/xend toolstack both HVM = and PVHVM guests work OK without it. >>> >>> -- Pasi >>> >> Thanks Pasi, >> >> hmm, so it is documented actually and thus sort of expected. Still it is >> confusing. For one driver it does not make a difference to use the form = of an >> emulated device in the config, for the other it does. The xl stack works= , the xm >> stack does not. >> And then, ok this is probably a quite naive approach, it seemed to make = sense to >> go through the pain of always having potentially both interfaces availab= le >> (emulated and pv) so in theory the same guest config can accommodate a g= uest os >> supporting one or the other (or easily switch from one to the other). Ot= herwise >> I would expect an emulated device only when I have hd? in the config and= a pv >> device when I write xvd?. >> > = > This works for both HVM and PVHVM (also mentioned on the wiki page): > vif =3D [ 'mac=3D00:16:5e:02:07:45, bridge=3Dxenbr0, model=3De1000' ] > = > So there's no need for "type=3Dioemu" option with xm/xend. > = > You can switch between HVM and PVHVM with: > xen_platform_pci=3D0|1 > = > -- Pasi > = It seems that this works (without the model, too) for xm and xl. So even wi= thout explicitly saying type=3Dioemu, there is an emulated device created. And if= the platform device is enabled, the emulated devices are unplugged by default. So it sounds like "type=3Dioemu" is not only not needed but hurts in the on= e case of xm. Would it make sense to completely remove it from the example configs? -Stefan