WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] libxl: problem with devices in PV
From: Roger Pau Monné <roger.pau@xxxxxxxxxxxxx>
Date: Wed, 20 Jul 2011 15:10:13 +0200
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Delivery-date: Wed, 20 Jul 2011 06:11:20 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EzJk/z1n+avFAzs2Epmn2BTaI7BbrzzqzytbI8hXfYI=; b=rIh9CpDfCgZISfRYPivrWuxJ/xQ/JNGLQerknxW2+5M+2+o1+TNTRFY9CIsEiu0nyE 0EpJ4WpUtB7c+hllVo7D98c93527f/Yp1+P7VR5vW6lBoVHylrcHSjmoafVCzuiwt9Qv v00V1c56rDCyhyjp0rTD53kyZKgQ7WHglBZos=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1311166476.20648.194.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <CAPLaKK7gAGfazKmyywfdwjFGBS+xog4C5M8bEzvhM3NyM=5mYA@xxxxxxxxxxxxxx> <alpine.DEB.2.00.1107201230260.12963@kaball-desktop> <1311166476.20648.194.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
2011/7/20 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.

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. It is not the
fancy blktap2, altough something similar to blktap2 *could* be
implemented *easily* using the RUMP Anykernel I think:

http://www.netbsd.org/docs/rump/index.html

Don't know for sure, but I think it should be possible to port the
blktap2 driver or something very similar using this.

>
>> 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.

Haven't tried phy:/ with unstable, but I supose it works, since it
worked in previous versions.

>
> [...]
>> > >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.

What I don't get is why qdisk work with HVM machines but not with PV
machines, shouldn't it be the same?

>
> Ian.
>
>

Also, I saw that on Linux the loop device was used to mount images in
the past, but with libxl the loop device isn't used anymore right? I
think that using the vnd device is the only way to get file images to
work under NetBSD.

Thanks, Roger.

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