>>> On 26.06.15 at 17:04, <jbeul...@suse.com> wrote:
>>>> On 26.06.15 at 15:38, <li...@eikelenboom.it> wrote:
>> On 2015-06-26 14:41, Jan Beulich wrote:
>>>>>> On 26.06.15 at 13:02, <li...@eikelenboom.it> 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 the
>>> device? I.e. it might be worth comparing the guest's /proc/interrupts
>>> from 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-edge
> timer
>>[...]
>> 83: 8 0 0 0 xen-dyn-event
>> eth0-q3-rx
>> 84: 2101 0 0 0 xen-pirq-msi-x xhci_hcd
>
> I 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
