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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On 03/12/12 20:47, Toby Karyadi wrote:
> 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 

I don't understand this whole argument about "policy vs functionality",
from my point of view what we have now is also a policy, every raw disk
file is attached using the vnd device.

And getting a gntdev isn't certainly a policy, on the other hand this is
going to get us much more functionality (like the ability to run
backends in userspace, for example support for blktap3 when it is released).

> can't work with file on NFS, so be damn with it and just route 
> everything via qemu-dm'. 

Again, as discused with Manuel, a better solution has to be found for
this issue, and I'm sure we can reach a consensus.

> 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 

The retirement of xenbackendd is done for a good reason, calling hotplug
scripts from libxl allows for better control of when hotplug scripts are
called, and also allows for better error handling if these scripts fail.
Same scripts are called, so functionality stays the same.

This was done for both NetBSD and Linux, in the past Linux used to call
hotplug scripts from udev, and now they are called from libxl too. I'm
not able to see how having a more unified hotplug script interface can
be a bad thing.

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

Again, I'm not able to see how this is a problem, in the past you had
xend, which was a gigantic piece of python code acting as a central
arbiter, now you have a small C daemon for each running domain. libxl is
generally considered a better piece of code, and is much more easier to
maintain than xend.

Do you have any concrete technical reason to belive that xend was better
than libxl?

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

libxl has even split OS specific routines in separate files, both for
Linux and NetBSD and frankly, I'm not able to see how that is worse that
the amount of patches we had in pkgsrc to have xend working. Now libxl
works out-of-the-box on NetBSD, and many efforts have been put into that.

We should focus our efforts on getting Xen to work on NetBSD without a
ton of NetBSD specific out of the tree patches, and right now my biggest
concern is getting Qemu upstream working.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel