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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Mon, Aug 21, 2017 at 06:22:05AM -0600, Jan Beulich wrote:
> >>> 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.

Right, they only become relevant when MSI-X is enabled, the maskall
bit is unset and the entry control register mask bit is also unset.

> 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.

AFAICT QEMU will only bound the interrupts when they are unmasked, so
the semantics of XEN_DOMCTL_bind_pt_irq could be changed so that MSI
interrupts are unmasked when bound, but that will change the current
behavior.

Another option is to (ab)use the msi.gflags field to add another flag
in order to signal Xen whether the interrupt should be unmasked. This
is in line with what you suggest below.

Roger.

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