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: Fri, 02 Dec 2011 11:11:38 +0100 Message-ID: <4ED8A45A.3050403@canonical.com> References: <4ED798B2.1040309@canonical.com> <20111201180944.GH12984@reaktio.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20111201180944.GH12984@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 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 unplugging = and the >> domU kernel having net-/blkfront and pci platform built-in (or as module= ). >> >> The block device is defined as hda and the NIC type=3Dioemu (so theoreti= cally >> guests without pv support would work, too). >> >> Since both drivers are present, the kernel tries to unplug the emulated = devices >> and succeeds. The blkfront driver detects the xvda device available in p= arallel >> and is working ok. >> >> However the network interface does not work. There are entries present u= nder >> sysfs for the xenbus but trying to bring it up fails with errors. And al= so 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 soun= ds a bit >> like NICs should behave the same as block devices. So if there is an emu= lated >> device defined there will be an alternate paravirt interface for it and = 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 us= ing 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 dri= vers WILL NOT work! Don't specify "type" parameter for the vif. (with type= =3Dioemu the pvhvm nic in the VM will have mac address full of zeroes - and= thus won't work!)." > = > "type=3Dioemu" is not needed, at least with xm/xend toolstack both HVM an= d 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, t= he xm stack does not. And then, ok this is probably a quite naive approach, it seemed to make sen= se to go through the pain of always having potentially both interfaces available (emulated and pv) so in theory the same guest config can accommodate a gues= t os supporting one or the other (or easily switch from one to the other). Other= wise I would expect an emulated device only when I have hd? in the config and a = pv device when I write xvd?. -Stefan