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

["Andreas Kinzler" <hfp@xxxxxxxxx>]

> >  - 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.
Hello Jan + Roger,

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?
Regards Andreas

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