[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] stubdom migration failure on merlot* XSM related (Was: [adhoc test] 65682: tolerable FAIL])



On Fri, 2015-12-11 at 15:16 +0000, Ian Campbell wrote:
> 
> I have a new flight going on (65755) with flask=permissive instead of
> flask=enforcing (assuming I didn't botch the osstest modifications to
> support that setting via a runvar).

I did botch the mods, but luckily permissive is the default, so I got what
I wanted ;-)

> If that test passes, prints the AVC message but not the missing IRQ message
> then I think that would be our smoking gun.

http://logs.test-lab.xenproject.org/osstest/logs/65758/

From serial-merlot1.log:

Dec 11 18:01:57.001037 (XEN) Flask: 64 avtab hash slots, 236 rules.
Dec 11 18:01:57.009023 (XEN) Flask: 64 avtab hash slots, 236 rules.
Dec 11 18:01:57.017004 (XEN) Flask:ÂÂ3 users, 3 roles, 36 types, 2 bools
Dec 11 18:01:57.017038 (XEN) Flask:ÂÂ12 classes, 236 rules
Dec 11 18:01:57.025015 (XEN) Flask:ÂÂStarting in permissive mode.
[...]
Dec 11 18:06:01.229194 (XEN) avc:ÂÂdeniedÂÂ{ pcilevel } for domid=2 target=1 
scontext=system_u:system_r:dm_dom_t tcontext=system_u:system_r:domU_t_target 
tclass=hvm

http://logs.test-lab.xenproject.org/osstest/logs/65758/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm/merlot1---var-log-xen-qemu-dm-debianhvm.guest.osstest--incoming.log.10

i.e. no "uhci_hcd 0000:00:01.2: Unlink after no-IRQ?ÂÂController is
probably using the wrong IRQ." and the test case has passed.

I've running a test with the following patch. I'm reasonably hopeful.

Ian.

From 3f14c5afedc0df360952364b93c2f04de00f00c4 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@xxxxxxxxxx>
Date: Mon, 14 Dec 2015 08:22:41 +0000
Subject: [PATCH] flask: Allow device model to raise PCI interrupts (pcilevel
Âcapability)

Allows:

(XEN) avc:ÂÂdeniedÂÂ{ pcilevel } for domid=2 target=1 
scontext=system_u:system_r:dm_dom_t tcontext=system_u:system_r:domU_t_target 
tclass=hvm

Which otherwise leads to the following on resume after migrate (comparing
non-XSM to XSM):

Âata2.00: configured for MWDMA2
Âusb 1-2: reset full-speed USB device number 2 using uhci_hcd
+PM: restore of devices complete after 3779.268 msecs
Âusb 1-2: USB disconnect, device number 2
-PM: restore of devices complete after 2342.528 msecs
Âusb 1-2: new full-speed USB device number 3 using uhci_hcd
Âusb 1-2: New USB device found, idVendor=0627, idProduct=0001
Âusb 1-2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Âusb 1-2: Product: QEMU USB Tablet
Âusb 1-2: Manufacturer: QEMU 0.10.2
Âusb 1-2: SerialNumber: 1
Âinput: QEMU 0.10.2 QEMU USB Tablet as 
/devices/pci0000:00/0000:00:01.2/usb1/1-2/1-2:1.0/input/input8
Âgeneric-usb 0003:0627:0001.0002: input,hidraw0: USB HID v0.01 Pointer [QEMU 
0.10.2 QEMU USB Tablet] on usb-0000:00:01.2-2/input0
ÂRestarting tasks ... done.
ÂSetting capacity to 20480000
ÂSetting capacity to 20480000
+uhci_hcd 0000:00:01.2: Unlink after no-IRQ?ÂÂController is probably using the 
wrong IRQ.

And a glitch in the domU which is sufficient to disrupt the post migration
checks done by osstest.

Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
Cc: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
---
Âtools/flask/policy/policy/modules/xen/xen.if | 2 +-
Â1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.if 
b/tools/flask/policy/policy/modules/xen/xen.if
index 32dd7b3..00d1bbb 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -150,7 +150,7 @@ define(`device_model', `
Â
       allow $1 $2_target:domain shutdown;
       allow $1 $2_target:mmu { map_read map_write adjust physmap target_hack 
};
-       allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl 
irqlevel pciroute cacheattr send_irq };
+       allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl 
irqlevel pciroute pcilevel cacheattr send_irq };
Â')
Â
Â# make_device_model(priv, dm_dom, hvm_dom)
-- 
2.6.1


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.