Re: [Xen-devel] [PATCH] docs: add misc/qemu-backends.txt

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Mon, Apr 11, 2016 at 12:57:27PM +0200, Juergen Gross wrote:
> On 11/04/16 12:33, Wei Liu wrote:
> > On Sun, Apr 10, 2016 at 01:00:46PM -0700, Stefano Stabellini wrote:
> >> On Thu, 7 Apr 2016, Juergen Gross wrote:
> >>> Document the interface between qemu and libxl regarding backends
> >>> supported by qemu.
> >>>
> >>> Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
> >>> ---
> >>>  docs/misc/qemu-backends.txt | 19 +++++++++++++++++++
> >>>  1 file changed, 19 insertions(+)
> >>>  create mode 100644 docs/misc/qemu-backends.txt
> >>>
> >>> diff --git a/docs/misc/qemu-backends.txt b/docs/misc/qemu-backends.txt
> >>> new file mode 100644
> >>> index 0000000..f28755e
> >>> --- /dev/null
> >>> +++ b/docs/misc/qemu-backends.txt
> >>> @@ -0,0 +1,19 @@
> >>> +In order to know whether qemu supports a specific backend type libxl
> >>> +needs a way to obtain this information.
> >>> +
> >>> +As each qemu instance owns a path (named "<qemu>" from now on) in
> >>> +Xenstore the backend information is presented there. <qemu> is built
> >>> +from the domain id where the qemu instance is running <backend-dom>
> >>> +and the domain id of the target domain of the qemu process <domid>:
> >>> +
> >>> +<qemu> = /local/domain/<backend-dom>/device-model/<domid>
> >>> +
> >>> +Before signalling qemu is running by writing "running" to <qemu>/state
> >>> +qemu will create a Xenstore node for each supported backend under
> >>> +<qemu>/backends with the backend type as name (e.g.
> >>> +<qemu>/backends/qdisk for the qdisk backend).
> >>> +
> >>> +libxl can assume a backend of a specific type <type> is supported if:
> >>> +- <qemu>/backends/<type> is existing in Xenstore
> >>> +- or <qemu>/backends is not existing and <type> is one of:
> >>> +  "console", "vkbd", "vfb", "qdisk", "qnic"
> >>
> >> The thing to be careful about is that the plan just a few months ago was
> >> to have QEMU restrict its own xenstore connection to the privilege level
> >> of the guest VM it was servicing. Libxl would relax the xenstore access
> >> rights to allow QEMU (and the gueest VM) access to
> >> /local/domain/<backend-dom>/device-model/<domid>/physmap, but nothing
> >> else. See:
> >>
> >> [1] http://marc.info/?l=qemu-devel&m=143317363104584&w=2
> >> [2] http://marc.info/?l=xen-devel&m=145081000327541
> >>
> >> what that means is that QEMU wouldn't be able to write to
> >> /local/domain/<backend-dom>/device-model/<domid>/backends, unless the
> >> writing was done before calling xsrestrict, which should be
> >> doable, but not what was done in [1].
> >>
> >> Maybe we could add a note saying that these paths need to be written by
> >> QEMU before dropping xenstore privileges?
> >>
> > 
> > Or allow that "backends" node be written by QEMU as well?
> 
> Just to get it right:
> 
> In my understanding of above patches the pv backends (including QUSB)
> won't be initialized in case of restricted Xenstore access. This means
> that the restricted Xenstore use case just doesn't apply to my QUSB
> patches. Both features can't be active at the same time.
> 

That's my understanding as well.

> In case qemu learns how to support pv backends with restricted Xenstore
> access Stefano's note about the time of writing the "backends" node
> applies: it has to happen before qemu deprivileges itself.
> 

This works for me too. I care more about having an established protocol
that is clearly  documented. Whichever way works most convenient for
QEMU is the best.

> > A somewhat related note is that this node would only be used when QEMU
> > is running as PV backend, while the original node "physmap" is only used
> > when QEMU runs as device model. Not sure if this would affect QEMU
> > depriv design though.
> > 
> > I think this needs to be sorted out as soon as possible, otherwise we
> > can't consider QUSB a supported feature for 4.7.
> 
> I hope you are fine with my reasoning above. I'll send an updated patch
> for the documentation soon.
> 

Sure. I'm fine with it. But I think QEMU maintainers have more say in
this matter.

Wei.

> 
> Juergen

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