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

[Ian Campbell <ian.campbell@citrix.com>]

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