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

[Juergen Gross <jgross@xxxxxxxx>]

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.

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.

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


Juergen

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