Re: [PATCH v3 3/6] [WIP] libxl: xsrestrict QEMU

[Stefano Stabellini <stefano.stabellini@eu.citrix.com>]

On Tue, 30 Jun 2015, Ian Campbell wrote:
> On Mon, 2015-06-29 at 19:07 +0100, Stefano Stabellini wrote:
> > On Thu, 25 Jun 2015, Ian Campbell wrote:
> > > On Wed, 2015-06-10 at 11:09 +0100, Stefano Stabellini wrote:
> > > > Check whether QEMU supports the xsrestrict option, by parsing its --help
> > > > output. Store the result on xenstore for future reference on a per QEMU
> > > > binary basis, so that device_model_override still works fine with it.
> > > 
> > > Is there some way we could avoid needing to do this, e.g. by doing the
> > > restrict later on via a qmp request, before the guest is unpaused of
> > > course.
> > 
> > It would be tricky because it needs to be done very early at boot time
> > in QEMU. Also we would still need to know whether a specific device
> > model supports this option before actually spawning it. So we would
> > still have to resort to spawning a "temporary" QEMU beforehand.
> 
> I think via qmp we can query the qemu after it starts to ask it if it
> has the "xs-restrict" property and then set it to a domid if so. I had
> some code to do this for the PCI permissive property we added recently,
> it wasn't hard.
> 
> If we can move all the restriction stuff in libxl until after we are in
> a position to ask qemu this then we don't need any temporary qemu or
> --help parsing.

The problem is not adding a new QMP command. The issue is that on the
QEMU side, we need to know whether to "xsrestrict" before starting the
PV backends, that is done before QMP is up.

Even if we work around that, on the libxl side, we certainly need to
know the correct device-model path on xenstore
(libxl__device_model_xs_path) in many many different places, and that
depends on "xsrestrict". I don't think is possible to move all the
restriction stuff after QEMU can reply to QMP requests.