Hello Yang,
attached you'll find the kernel dmesg, xen dmesg, lspci and output
of /proc/interrupts. If you want to see further logfiles, please
let me know.
The processor is a Core i5-4670. The board is an Intel DH87MC
Mainboard. I am really not sure if it supports APICv, but VT-d is
supported enabled enabled.
4.
The status of IRQ 29 is 10 which means the
guest already issues the EOI because the bit
IRQ_GUEST_EOI_PENDING is cleared, so there should be no
pending EOI in the EOI stack. If possible, can you add
some debug message in the guest EOI code path(like
_irq_guest_eoi())) to track the EOI?
I don't see the IRQ29 in /proc/interrupts, what I see is:
cat xen-dmesg.txt |grep "29": (XEN) allocated vector 29 for irq 20
cat dmesg.txt | grep "eth0": [ 23.152355] e1000e 0000:00:19.0:
PCI INT A -> GSI 20 (level, low) -> IRQ 20
[ 23.330408]
e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
So is the ethernet irq the bad one ? That is an Onboard Intel
network adapter.
6.
I guess the interrupt remapping is enabled in
your machine. Can you try to disable IR to see whether it
still reproduceable?
Just to be sure, your proposal is to try the parameter
"no-intremap" ?
Best regards
Thimo
Am 12.08.2013 10:49, schrieb Zhang, Yang Z:
Hi Thimo,
From your previous experience and log, it
shows:
1.
The interrupt that triggers the issue is a MSI.
2.
MSI are treated as edge-triggered interrupts
nomally, except when there is no way to mask the device. In
this case, your previous log indicates the device is
unmaskable(What special device are you using?Modern PCI
devcie should be maskable).
3.
The IRQ 29 is belong to dom0, it seems it is
not a HVM related issue.
