Re: [Xen-devel] [PATCH v2 0/*] xen: xen-domid-restrict improvements

[Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>]

On 10/06/2017 02:19 PM, Paul Durrant wrote:
> > -----Original Message-----
> > From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of
> > Ross Lagerwall
> > Sent: 06 October 2017 13:58
> > To: Ian Jackson <Ian.Jackson@xxxxxxxxxx>; qemu-devel@xxxxxxxxxx
> > Cc: Anthony Perard <anthony.perard@xxxxxxxxxx>; xen-
> > devel@xxxxxxxxxxxxxxxxxxxx; Stefano Stabellini <sstabellini@xxxxxxxxxx>;
> > Juergen Gross <jgross@xxxxxxxx>
> > Subject: Re: [Xen-devel] [PATCH v2 0/*] xen: xen-domid-restrict
> > improvements
> >
> > On 10/04/2017 05:18 PM, Ian Jackson wrote:
> > > (Resending this because 1. I got the CC for xen-devel wrong; 2. I got
> > > the subject wrong: there are actually 8 patches; 3. I mangled
> > > Anthony's name in theheaders.  Sorry for the noise.)
> > >
> > > I have been working on trying to get qemu, when running as a Xen
> > > device model, to _actually_ not have power equivalent to root.
> > >
> > > I think I have achieved this, with some limitations (which will be
> > > discussed in my series against xen.git.
> > >
> > > However, there are changes to qemu needed.  In particular
> > >
> > >    * The -xen-domid-restrict option does not work properly right now.
> > >      It only restricts a small subset of the descriptors qemu has open.
> > >      I am introducing a new library call in the Xen libraries for this,
> > >      xentoolcore_restrict_all.
> > Hi Ian,
> >
> > I'm testing your QEMU and Xen patch series and found that after being
> > restricted, QEMU fails to setup up the VGA memory properly which causes
> > a complete stall with stdvga. With cirrus it mostly works although it
> > seems to have reduced performance.
> >
> > I think it happens when the VM sets up the BAR some time after
> > xen_restrict() has been called. The failure comes from QEMU calling
> > xc_domain_add_to_physmap() which calls do_memory_op() and finally
> > xencall2(). But the underlying xencall fd has been replaced with /dev/null.
> Oh, that's a PITA. This is because of the slightly hacky way that the VRAM is 
> dealt with (it needing to be moved into the BAR of the PCI VGA device at the 
> point where guest firmware programs it). Maybe we need a new dm_op for this?
If no one objects, I propose adding the following calls to 
libxendevicemodel (with underlying Xen implementations, of course) that 
would be usable after the xendevicemodel handle has been restricted.
xendevicemodel_add_to_physmap(xendevicemodel_handle *dmod,
                              domid_t domid,
                              unsigned long idx,
                              xen_pfn_t gpfn);

This is equivalent to xc_domain_add_to_physmap() with
space==XENMAPSPACE_gmfn.

xendevicemodel_pin_memory_cacheattr(xendevicemodel_handle *dmod,
                                    domid_t domid,
                                    uint64_t start,
                                    uint64_t end,
                                    uint32_t type);

This is equivalent to xc_domain_pin_memory_cacheattr().

--
Ross Lagerwall

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