[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] flask: Allow device model to raise PCI interrupts (pcilevel capability)
On Mon, Dec 14, 2015 at 11:55:45AM +0000, Ian Campbell wrote: > 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 > Nice work fixing this. :-) I did notice this when I first started, I would have sworn I produced a similar patch but it didn't quite work for me so in the end I only sent out an email to ask Daniel about it. > 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. > > This has been through a test run on merlot1 and resolved the migration > issues with the test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm > osstest test case. > What is still perplexing is that why significant delay only manifested on merlot*. Unfortunately we don't have other large machines to collect enough data points. I guess we can live with the status quo for now and fix other issues should they surface. Wei. > 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |