>>> On 21.04.16 at 11:38, <jbeul...@suse.com> 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 <jbeul...@suse.com> > --- > 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@lists.xen.org http://lists.xen.org/xen-devel
