Re: [Xen-devel] [PATCH] x86/vMSI-X: avoid missing first unmask of vectors

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.04.16 at 11:38, <JBeulich@xxxxxxxx> wrote:
> Recent changes to Linux result in there just being a single unmask
> operation prior to expecting the first interrupts to arrive. However,
> we've had a chicken-and-egg problem here: Qemu invokes
> xc_domain_update_msi_irq(), ultimately leading to
> msixtbl_pt_register(), upon seeing that first unmask operation. Yet
> for msixtbl_range() to return true (in order to msixtbl_write() to get
> invoked at all) msixtbl_pt_register() must have completed.
> 
> Deal with this by snooping suitable writes in msixtbl_range() and
> triggering the invocation of msix_write_completion() from
> msixtbl_pt_register() when that happens in the context of a still in
> progress vector control field write.
> 
> Note that the seemingly unrelated deletion of the redundant
> irq_desc->msi_desc checks in msixtbl_pt_register() is to make clear to
> any compiler version used that the "msi_desc" local variable isn't
> being used uninitialized. (Doing the same in msixtbl_pt_unregister() is
> just for consistency reasons.)
> 
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> TODO: How to deal with REP MOVS to the MSI-X table (in msixtbl_range())?

One option I just now thought of might be to also look at batches
of up to 4 dword or 2 qword writes there, tracking the address of
the one that writes to the vector control field. One might even
limit this to taking into consideration only the last iteration on such
batches, on the assumption that if at all it should be that last one
which writes the field of interest. (The fundamental assumption
then would be that no OS uses REP MOVS to fill data for more than
one table entry at a time.) This would then also cover various
Windows versions.

Jan


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