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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 01.04.16 at 16:58, <Paul.Durrant@xxxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: 01 April 2016 15:40
>> >>> On 01.04.16 at 16:27, <Paul.Durrant@xxxxxxxxxx> wrote:
>> >> From: Paul Durrant
>> >> Sent: 01 April 2016 15:20
>> > I pulled staging and I still see (starting at line 300 in vmsi.c)
>> >
>> >     /* Exit to device model when unmasking and address/data got modified.
>> */
>> >     if ( !(val & PCI_MSIX_VECTOR_BITMASK) &&
>> >          test_and_clear_bit(nr_entry, &entry->table_flags) )
>> >     {
>> >         v->arch.hvm_vcpu.hvm_io.msix_unmask_address = address;
>> >         goto out;
>> >     }
>> >
>> >     msi_desc = msixtbl_addr_to_desc(entry, address);
>> >     if ( !msi_desc || msi_desc->irq < 0 )
>> >         goto out;
>> >
>> > I was wrong about the name. I meant 'entry->table_flags', and that's 
>> > clearly
>> > manipulated before calling msixtbl_addr_to_desc() so even if that returns
>> > NULL Xen still keeps in sync with QEMU AFAICT.
>> 
>> Staying in sync with qemu is not the problem. The problem is that
>> the re-invocation from msix_write_completion() then would get
>> past this, and find said NULL returned from msixtbl_addr_to_desc().
> 
> True, but perhaps if we know this is a completion cycle then we should 
> always set r to X86EMUL_OKAY? TBH I'm not sure what would happen if we 
> didn't... I suspect the emulation state machine would get upset.

The question isn't what to set r to (msix_write_completion() only
logs a debug message whan that's not the case), but how to make
sure guest_mask_msi_irq() gets called.

Jan


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