Re: [Xen-devel] [PATCH v7 03/12] tools/libxenforeignmemory: add support for resource mapping

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Ian Jackson [mailto:ian.jackson@xxxxxxxxxxxxx]
> Sent: 18 September 2017 17:16
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [PATCH v7 03/12] tools/libxenforeignmemory: add support for
> resource mapping
> 
> Paul Durrant writes ("[PATCH v7 03/12] tools/libxenforeignmemory: add
> support for resource mapping"):
> > A previous patch introduced a new HYPERVISOR_memory_op to acquire
> guest
> > resources for direct priv-mapping.
> >
> > This patch adds new functionality into libxenforeignmemory to make use
> > of a new privcmd ioctl [1] that uses the new memory op to make such
> > resources available via mmap(2).
> >
> > [1]
> http://xenbits.xen.org/gitweb/?p=people/pauldu/linux.git;a=commit;h=ce5
> 9a05e6712
> 
> This looks plausible to me.
> 
> I wonder whether this, particularly for the ioreq server page, will
> make it possible to deprivilege earlier than I did in my own series on
> Friday.
> 

It should, eventually. The necessary changes to privcmd would also need to make 
it into dom0, as well as the changes to QEMU (both of which I have on branches 
ready to go).

> (With my series, I do the depriv on entering the `running' state,
> which is quite late.  It's after reading the migration stream, which
> is not ideal.  But it did mean that qemu had already aquired the ioreq
> page by then so it worked.  Unless that's just because my Xen was a
> bit old?)

The acquisition of the ioreq pages is towards the end of the hvm init routine, 
so depriv any time after that (under the old scheme) should be doable.

> 
> Anyway,
> 
> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>

Great. Thanks,

  Paul

> 
> Ian.

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