On Fri, 2015-12-11 at 15:12 +0000, Ian Campbell wrote:
> Dec 10 20:13:39.584976 (XEN) avc: denied { pcilevel } for domid=8
> target=7 scontext=system_u:system_r:dm_dom_t
> tcontext=system_u:system_r:domU_t_target tclass=hvm
I wonder if this is an intx associated with the USB?
In the XSM case the guest serial log on restore has:
http://osstest.test-lab.xenproject.org/~osstest/pub/logs/65682/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm/merlot1---var-log-xen-qemu-dm-debianhvm.guest.osstest--incoming.log
[ 373.747112] ata2.00: configured for MWDMA2
+00 [ 373.920163] usb 1-2: reset full-speed USB device number 2 using uhci_hcd
+04 [ 377.360563] PM: restore of devices complete after 3779.268 msecs
+04 [ 377.365351] usb 1-2: USB disconnect, device number 2
+04 [ 377.720174] usb 1-2: new full-speed USB device number 3 using uhci_hcd
+11 [ 384.829312] usb 1-2: New USB device found, idVendor=0627, idProduct=0001
+11 [ 384.834014] usb 1-2: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
+11 [ 384.839012] usb 1-2: Product: QEMU USB Tablet
+11 [ 384.842105] usb 1-2: Manufacturer: QEMU 0.10.2
+11 [ 384.845230] usb 1-2: SerialNumber: 1
+18 [ 391.078740] 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
+18 [ 391.086474] 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
+18 [ 391.095614] Restarting tasks ... done.
+18 [ 391.107562] Setting capacity to 20480000
+18 [ 391.124154] Setting capacity to 20480000
+18 [ 391.140135] uhci_hcd 0000:00:01.2: Unlink after no-IRQ? Controller is
probably using the wrong IRQ.
(I've annotated with the time since the first line).
The corresponding log in the non-XSM case is
http://logs.test-lab.xenproject.org/osstest/logs/65738/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64/merlot1---var-log-xen-qemu-dm-debianhvm.guest.osstest--incoming.log.10
[ 338.127757] ata2.00: configured for MWDMA2
+00 [ 338.296159] usb 1-2: reset full-speed USB device number 2 using uhci_hcd
+02 [ 340.301541] usb 1-2: USB disconnect, device number 2
+02 [ 340.301655] PM: restore of devices complete after 2342.528 msecs
+02 [ 340.520096] usb 1-2: new full-speed USB device number 3 using uhci_hcd
+03 [ 341.373756] usb 1-2: New USB device found, idVendor=0627, idProduct=0001
+03 [ 341.378788] usb 1-2: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
+03 [ 341.384183] usb 1-2: Product: QEMU USB Tablet
+03 [ 341.387406] usb 1-2: Manufacturer: QEMU 0.10.2
+03 [ 341.390738] usb 1-2: SerialNumber: 1
+03 [ 341.809652] 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
+03 [ 341.817873] 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
+03 [ 341.827641] Restarting tasks ... done.
+03 [ 341.839784] Setting capacity to 20480000
+03 [ 341.846421] Setting capacity to 20480000
Which is over much quicker, and the uhci_hcd is not complaining about a
missing IRQ...
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).
If that test passes, prints the AVC message but not the missing IRQ message
then I think that would be our smoking gun.
The new flight has dropped debianhvm_general_timeoutfactor, which has
proven its point.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
