[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen-unstable: pci-passthrough of device using MSI-X interrupts not working after commit x86/MSI: track host and guest masking separately
On 2015-06-26 17:22, Jan Beulich wrote: On 26.06.15 at 17:04, <JBeulich@xxxxxxxx> wrote:On 26.06.15 at 15:38, <linux@xxxxxxxxxxxxxx> wrote:On 2015-06-26 14:41, Jan Beulich wrote:On 26.06.15 at 13:02, <linux@xxxxxxxxxxxxxx> wrote:Strange, i don't see *any* of your printk's being hit ... (xl dmesg attached).So does the guest (in the working case) use MSI-X at all for thedevice? I.e. it might be worth comparing the guest's /proc/interruptsfrom both cases, as the lack of any of the debug messages clearly suggests that such interrupts aren#t being set up.In the good case it uses one of them. (probably one per port and it has only one usb device connected at present) -- Sander CPU0 CPU1 CPU2 CPU3 0: 42 0 0 0 IO-APIC 2-edgetimer[...]83: 8 0 0 0 xen-dyn-event eth0-q3-rx 84: 2101 0 0 0 xen-pirq-msi-x xhci_hcdI think this explains it - you're running in PVHVM mode, which I never tried with those patches. I'd even have to go dig to see how they drive MSI-X in the first place in that case.I have an idea: In static unsigned int startup_msi_irq(struct irq_desc *desc) { bool_t guest_masked = (desc->status & IRQ_GUEST) && is_hvm_domain(desc->msi_desc->dev->domain); if ( unlikely(!msi_set_mask_bit(desc, 0, guest_masked)) ) WARN(); return 0; } I think we need to also exclude the emuirq case (which is what I understand backs the pvhvm interrupt in the guest - Stefano, please confirm). For testing purposes, could you try simply passing zero instead of guest_masked here? Jan I can confirm, with 0 it works ! -- Sander _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |