Re: [Xen-devel] Regression PCI passthrough from 4.5.5 to 4.6.0-rc1

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.08.17 at 11:46, <roger.pau@xxxxxxxxxx> wrote:
> Xen never detects the MSIX table entry unmask because it happens
> before the MSIX is bound to the guest, so the Xen msixtbl handlers are
> not aware of this memory region.
> 
> The two possible solutions I see to this are:
> 
>  - Make QEMU setup the vectors when the table entries are unmasked,
>    even if MSIX is not enabled.
>  - Provide an hypercall so QEMU can unmask MSIX vectors on behalf of
>    the guest. This would be used to unmask the entries if MSIX is
>    enabled with table entries already unmasked.

Neither sounds right. As long as MSI-X is disabled (or the maskall
bit set), the contents of the table entries is meaningless. It is not
correct to assign any meaning to them in that state. And qemu
should not be unmasking the entries on behalf of the guest either.
It ought to be possible for Xen to know the state of the mask bits
at the time of binding the interrupts. After all, with a new hypercall
added like you propose it, there would still be a window in time
where neither setting (masked or unmasked) would be correct in
Xen's internal recording of state. Quite possibly the only solution
is for qemu to communicate the intended state of the mask bit
while binding the interrupt.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel