From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Egger Subject: Re: libxl: problem with devices in PV Date: Wed, 20 Jul 2011 16:27:07 +0200 Message-ID: <4E26E5BB.1020902@amd.com> References: <1311166476.20648.194.camel@zakaz.uk.xensource.com> <1311168600.20648.217.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1311168600.20648.217.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , "xen-devel@lists.xensource.com" , Stabellini Stefano List-Id: xen-devel@lists.xenproject.org On 07/20/11 15:30, Ian Campbell wrote: > On Wed, 2011-07-20 at 14:10 +0100, Roger Pau Monn=C3=A9 wrote: >> 2011/7/20 Ian Campbell: >>> On Wed, 2011-07-20 at 12:37 +0100, Stefano Stabellini wrote: >>>> On Wed, 20 Jul 2011, Roger Pau Monn=C3=A9 wrote: >>>>> Hello, >>>>> >>>>> I'm trying to run PV machines using the new libxenlight toolstack o= n >>>>> NetBSD. So far, I've been able to connect to the domu using the >>>>> console (I was unable to do so before). I'm attaching a little patc= h >>>>> that removes setting the consback to IOEMU when detecting a qdisk >>>>> (that was preventing the domu from even booting). With the >>>>> introduction of libxenlight, Xen doesn't use vbd for disk backend >>>>> anymore, it uses qdisk, which I assume Qemu automatically attaches = to >>>>> running guests. It works fine with HVM guests, but it seems to fail >>>>> with PV guests. The config file I'm using is: >>>>> >>>> >>>> Xen uses qdisk only when blktap is not available. >>>> I suggest you install blktap if you can because it is significantly >>>> faster than qdisk at the moment. >>> >>> This is a NetBSD host so I don't think blktap is an option. >> >> NetBSD has the vnd driver, which provides a disk interface to a file >> (it's basically a loop device): >> >> http://netbsd.gw.com/cgi-bin/man-cgi?vnd+4+NetBSD-current >> >> It is used with xend and xenbackendd to mount raw disks. > > If I understand correctly (which is remotish possibility): > > xenbackendd watches the backend/vbd directory and creates disks based o= n > it. A "vbd" directory roughly corresponds to a "phy:" type device > configuration in libxl. Correct. > xend, at least on Linux, internally handles "file:" by setting up a loo= p > device and translating the config into a "phy:"=3D=3Dvbd refering to > the /dev/loopN device. I suspect that on NetBSD xend used to just creat= e > the vbd referring to the file directly and let xenbackendd take care of > any necessary loop back stuff. More precisely, xenbackendd invokes the hotplug scripts and those take care of choosing a spare vnd device. > libxl on the other hand does not do this loop device magic but instead > palms "file:" off onto either qdisk or blktap and furthermore libxl > requires that a "phy:" disk configuration refers to a block device and > not a file. > > The upshot is that the backend selection logic in libxl is apparently > not correct for NetBSD which _can_ handle files passed as "phy:" due to > xenbackendd doing the right thing via the vnd driver. Right. > Fortunately Ian Jackson recently cleaned up the backend selection logic > in libxl and it should be much cleaner and easier to express these sort= s > of system specific things, presumably by patching disk_try_backend to > allow files as well as block devices for LIBXL_DISK_BACKEND_PHY on > NetBSD. Roger: In libxl/libxl_device.c:disk_try_backend() can you try disabling the second check in the LIBXL_DISK_BACKEND_PHY case, please? Or surrounding it with #ifdef __Linux__ ... #endif should do it. Christoph >>>> Otherwise if you use a physical partition and specify phy: in the co= nfig >>>> file you should get the kernel based blkback that is the fastest opt= ion >>>> available. >>> >>> phy: would be worth a go since it should tie into NetBSD's equivalent= of >>> blkback, whereas file: presumably goes to qdisk in the absence of >>> blktap. >> >> Haven't tried phy:/ with unstable, but I supose it works, since it >> worked in previous versions. > > Since you are passing a file name a block device it is possible that > libxl today might reject it when used with phy:/... > > [...] >> What I don't get is why qdisk work with HVM machines but not with PV >> machines, shouldn't it be the same? > > I suspect that in the HVM case you aren't really getting a qdisk (a PV > backend) but actually an emulated disk device. Or rather you are > probably getting both but the guest only tries to use the emulated one > and hence the PV backend never tries to initialise and so never falls > over due to lack of gntdev. > > Can you confirm if your HVM guest uses emulated or PV frontends? > > Ian. --=20 ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632