Re: [PATCH v2 0/3] Add support for NetBSD gntdev

[Toby Karyadi <toby.karyadi@gmail.com>]

On 11/30/12 5:50 AM, Manuel Bouyer wrote:
> On Fri, Nov 30, 2012 at 10:43:21AM +0000, Ian Campbell wrote:
>> On Fri, 2012-11-30 at 10:38 +0000, Manuel Bouyer wrote:
>>> On Fri, Nov 30, 2012 at 10:32:32AM +0000, Ian Campbell wrote:
>>>> libxl only selects the backend itself if the caller doesn't provide one.
>>>> If the caller sets the backend field !=  UNKNOWN then libxl will (try)
>>>> and use it. This field is exposed by xl via the backendtype= key in the
>>>> disk configuration
>>>> http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt
>>> thanks for pointing this out.
>>> I guess qdisk is the qemu backend, and tap would be the in-kernel backend ?
>> qdisk == qemu, tap == blktap, phy == in kernel.
> OK; but then, how does the script called by xenbackendd know what setup
> is should do ? With xm, it would get a string in the form
> phy:/dev/wd0e
> or
> file:/domains/foo.img
>
> but from what I've understant, this syntax is deprecated now ?

Hi Manuel, thanks for all of your work on xen.

So, the short answer is that the /usr/pkg/etc/xen/scripts/block 
executable (which is just a shell script) needs to fish the type of the 
backend and other extra info out of xenstore. In the case of netbsd's 
block script, it uses the xenstore-read utility. When the block script 
is called, $1 ($xpath) will be an entry like so 
/local/domain/0/backend/vbd/2/768; so this is vbd for domU instance #2 
with disk instance id 768. $2 ($xstatus) is the reason the block script 
is called, 2 for startup, and 6 for tear down.

If you look at the block script you can also see that the block script 
needs to fish out the type of the backend that is located at $xpath/type 
in xenstore. The block script utilizes the xenstore-read and 
xenstore-write to read/modify xenstore, if you notice.

So, under $xpath here are the pertinent entries:
- $xpath/type
- $xpath/params
- $xpath/physical-disk

With xm+xend, for disk config file:/var/xen/domu/server001/disk.img, 
prior to the block script getting called:
$xpath/type = 'file'
$xpath/params = '/var/xen/domu/server001/disk.img'
$xpath/physical-disk = <unspecified>

Then when the block script is called, it detects that the type is 'file' 
and so it would call vnconfig using the value $xpath/params as the 
actual file using an unused vnd device, say vnd2. Then it would modify 
$xpath/physical-disk using the xenstore-write utility and set the value 
of $xpath/physical-disk to /dev/vnd2. After that, the handling, 
everything else is handled as if the backend is an actual physical 
device, which is true.

If the value of $xpath/type is 'phy', nothing needs to be done, since 
$xpath/physical-disk has been setup properly.

Now, the above behavior is how xm+xend+xenbackendd works. There was a 
bug in libxl/xl that I fixed as described here 
http://mail-index.netbsd.org/port-xen/2012/05/29/msg007252.html so that 
libxl/xl would behave the same way. You might also notice, I made small 
changes to allow custom backend type. I don't mean to keep tooting my 
own horn, but I just don't want the fix to get lost, although I just 
learned that I probably should do a bug report with the patch, but I 
don't have much time right now.

Hopefully I don't bore you to death if you read this far, but the way 
the libxl/xl is going seems somewhat ridiculous, where they are trying 
to insert more and more policy vs functionality, as evidenced by Roger's 
effort to outrightly to just decide (hence a policy) that 'well, vnd 
can't work with file on NFS, so be damn with it and just route 
everything via qemu-dm'. Additionally, they are planning to retire 
xenbackendd and again this is a trend that I don't like where they clump 
everything into one giant ball called the libxl/xl, as opposed to a 
bunch of little executables doing specific things. Another illustration: 
you might ask who's managing the domU in the absence of xend; well what 
happens is that when you do 'xl create ...' xl would then daemonize 
itself to watch xenstore for that specific domU that it just created. I 
guess that's cool, but to me it's got the feel to put everything into 
one giant, monolithic, unflexible entity (shudder).

So, I'm just writing to give you some more information about this whole 
libxl/xl stuff, and hopefully it'll give you some arsenal so that some 
of the xen folks don't try to force policies that is claimed to protect 
'end-user' or very linux specific.

Cheers,
Toby