Re: [Xen-devel] libxl: problem with devices in PV

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2011-07-20 at 12:37 +0100, Stefano Stabellini wrote:
> On Wed, 20 Jul 2011, Roger Pau Monnà wrote:
> > Hello,
> >
> > I'm trying to run PV machines using the new libxenlight toolstack on
> > 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 patch
> > 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.

> Otherwise if you use a physical partition and specify phy: in the config
> file you should get the kernel based blkback that is the fastest option
> 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.

[...]
> > >From what I see, the guest is unable to find the disk, which is
> > strange, because HVM guests work fine, and the disk is attached
> > correctly. Does this also happen when using file:/ backend (qdisk)
> > under Linux also? Is it a problem with Qemu or is it related to libxl?
> 
> It doesn't happen under Linux; it is probably a problem with Qemu.  Qemu
> uses the gntdev device (/dev/xen/gntdev) to open the grant table
> (necessary to implement xen backends in userspace).
> There doesn't seem anything equivalent on NetBSD, hence it fails...

That makes some sense. libxl should really detect that qdisk isn't an
option under NetBSD (like it does for blktap) and abort if that is the
case. This could be a case of a simple check in
tools/libxl/libxl_device.c:disk_try_backend. (could be as simple as an
#ifdef __NetBSD__ or we could e.g. add -DHAVE_QEMU_BACKENDS to the build
infrastructure where appropriate).

Presumably if libxl isn't trying to start a qdisk it won't try and use a
qemu based console either (which also won't work under NetBSD) and the
original patch from this thread becomes unnecessary.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel