-----Original Message-----
From: Xen-devel [mailto:address@hidden On Behalf Of
Ross Lagerwall
Sent: 06 October 2017 13:58
To: Ian Jackson <address@hidden>; address@hidden
Cc: Anthony Perard <address@hidden>; xen-
address@hidden; Stefano Stabellini <address@hidden>;
Juergen Gross <address@hidden>
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.