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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.08.17 at 14:32, <hfp@xxxxxxxxx> wrote:
>> >  - 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.
> 
> as someone who is not familiar with MSI-X stuff, I still have one obvious  
> question: Why was all of this not a problem before the commit I bisected  
> down? Everything did work before and to be honest there is a "business"  
> side to my question: Since that patch it has actually been broken for at  
> least 3 major Xen releaes (4.6-4.8). Does that make any sense? For the  
> reputation of Xen?

For the reputation of Xen this is not nice, I agree. But this being an
open source project, you would have been free to contribute a fix
in all of this time. In no case is it, imo, appropriate to demand an
immediate solution here - if there's a business aspect for you and
you don't feel capable of analyzing and fixing the issue yourself,
you always have the option of paying someone who is.

The fact that things had worked before that change does _not_
mean the change was bad. It's is far more likely for things to have
worked out of pure luck.

Jan


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