Re: [Xen-devel] non-dom0 disk backend still not working after recent patches

[Eric Shelton <eshelton@xxxxxxxxx>]

On Wed, May 1, 2013 at 11:27 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Wed, 2013-05-01 at 14:27 +0100, Eric Shelton wrote:
>> On May 1, 2013, at 4:13 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>>
>> > On Tue, 2013-04-30 at 18:04 +0100, Eric Shelton wrote:
>> >> Will/should xl block-attach make the domU backend disk available to dom0?
>> >
>> > I think so, it might depend a bit on your dom0 kernel. Although whether
>> > you would then be allowed to use it as a guest disk (which I guess is
>> > why you are asking) I'm not sure.
>> >
>> >> Would you expect this to work directly for a PV guest,
>> >
>> > Yes.
>> >
>> >> or am I going
>> >> to have to turn to pygrub (assuming it similarly facilitates storage
>> >> access) or some other mechanism?
>> >
>> > Actually, pygrub is one thing I would expect not to work (precisely
>> > because it needs access to the domain disks in dom0). I'd expect either
>> > explicitly providing the kernel or using pvgrub would work.
>> >
>> > Ian.
>>
>> Thanks again.  I got a chance to look into pvgrub a bit more, and I
>> see it essentially has the same issue as non-stubdom hvm.
>
> Do you mean pvgrub or pygrub? They are very different beasts.
> http://wiki.xen.org/wiki/PvGrub vs http://wiki.xen.org/wiki/PyGrub

In the end, pvgrub is what I would use.  However, my understanding as
to how pbgrub obtains blkback access was incorrect.

>> Problems remain in the stubdom code path.  Now it dies in
>> xenstore_get_backend_path() in qemu-xen-traditional because bpath
>> corresponds to the correct domU path, but the expected path is under
>> the dom0 path.  This is because domid_backend is initialized to 0, and
>> is never changed.  There is a comment where it is initialized that
>> essentially identifies this as a todo.
>
> It's also a bug that this is global since the backend is per device.

That is a very good point.  The variable should go, although the
reliance of get_device_variable_path() complicates its removal a
little.

>> My guess is that the backend domain number should be indicated
>> somewhere in the command line for qemu-dm (likely the -disk
>> parameters), and then stored in domid-backend.  Does anyone have any
>> comments on the appropriate implementation?
>
> For better or worse I think frontends typically parse the backend path
> to extract the b.e. domid from it.

Now that you mention it, it would seem that xenstore is where that
information should be found.  The change should be easy, as the
current code takes care of most of it already.

>> I also will note that this will require a change to
>> qemu-xen-traditional.  On the other hand, I expect the change to be
>> small, and probably reasonable to roll into 4.3.  However, as
>> qemu-cen-traditional appears to be quasi-depricated, I would like to
>> know if such a change would be accepted.  A similar change, if not
>> already implemented, would also be needed in qemu-xen for
>> linux-stubdoms.
>
> I can't say to be honest, as a prerequisite we would normally like to
> see the fix posted for qemu-upstream before considering something for
> qemu-xen-trad.

qemu-upstream has different code for interacting with this aspect of
xenstore.  I haven't tried using it, so it may even already be
correct.  Either way, that prereq may not be of much use for this
issue.

- Eric

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