aboutsummaryrefslogtreecommitdiff
path: root/hw/xen/xen-common.c
diff options
context:
space:
mode:
authorIan Jackson <ian.jackson@eu.citrix.com>2017-09-15 16:02:24 +0100
committerIan Jackson <Ian.Jackson@eu.citrix.com>2018-04-26 16:29:51 +0100
commit4564e63f80ace744093157782c3db45fc50a4836 (patch)
treeac1b5ff64592040aad6d7c8b93325d40289d94c4 /hw/xen/xen-common.c
parent0ef4d87da58dfe0e0e466414701c103b7a44df65 (diff)
xen: defer call to xen_restrict until just before os_setup_post
We need to restrict *all* the control fds that qemu opens. Looking in /proc/PID/fd shows there are many; their allocation seems scattered throughout Xen support code in qemu. We must postpone the restrict call until roughly the same time as qemu changes its uid, chroots (if applicable), and so on. There doesn't seem to be an appropriate hook already. The RunState change hook fires at different times depending on exactly what mode qemu is operating in. And it appears that no-one but the Xen code wants a hook at this phase of execution. So, introduce a bare call to a new function xen_setup_post, just before os_setup_post. Also provide the appropriate stub for when Xen compilation is disabled. We do the restriction before rather than after os_setup_post, because xen_restrict may need to open /dev/null, and os_setup_post might have called chroot. Currently this does not work with migration, because when running as the Xen device model qemu needs to signal to the toolstack that it is ready. It currently does this using xenstore, and for incoming migration (but not for ordinary startup) that happens after os_setup_post. It is correct that this happens late: we want the incoming migration stream to be processed by a restricted qemu. The fix for this will be to do the startup notification a different way, without using xenstore. (QMP is probably a reasonable choice.) So for now this restriction feature cannot be used in conjunction with migration. (Note that this is not a regression in this patch, because previously the -xen-restrict-domid call was, in fact, simply ineffective!) We will revisit this in the Xen 4.11 release cycle. Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> CC: Paolo Bonzini <pbonzini@redhat.com> (maintainer:X86) CC: Richard Henderson <rth@twiddle.net> (maintainer:X86) CC: Eduardo Habkost <ehabkost@redhat.com> (maintainer:X86) CC: Michael S. Tsirkin <mst@redhat.com> (supporter:PC) Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Diffstat (limited to 'hw/xen/xen-common.c')
-rw-r--r--hw/xen/xen-common.c14
1 files changed, 14 insertions, 0 deletions
diff --git a/hw/xen/xen-common.c b/hw/xen/xen-common.c
index 83099dd1b1..454777c587 100644
--- a/hw/xen/xen-common.c
+++ b/hw/xen/xen-common.c
@@ -117,6 +117,19 @@ static void xen_change_state_handler(void *opaque, int running,
}
}
+static void xen_setup_post(MachineState *ms, AccelState *accel)
+{
+ int rc;
+
+ if (xen_domid_restrict) {
+ rc = xen_restrict(xen_domid);
+ if (rc < 0) {
+ perror("xen: failed to restrict");
+ exit(1);
+ }
+ }
+}
+
static int xen_init(MachineState *ms)
{
xen_xc = xc_interface_open(0, 0, 0);
@@ -165,6 +178,7 @@ static void xen_accel_class_init(ObjectClass *oc, void *data)
AccelClass *ac = ACCEL_CLASS(oc);
ac->name = "Xen";
ac->init_machine = xen_init;
+ ac->setup_post = xen_setup_post;
ac->allowed = &xen_allowed;
ac->global_props = xen_compat_props;
}