Re: [Xen-devel] [v3 10/15] vt-d: Add API to update IRTE when VT-d PI is used

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.07.15 at 10:38, <feng.wu@xxxxxxxxx> wrote:

> 
>> -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Wednesday, July 15, 2015 4:25 PM
>> To: Wu, Feng
>> Cc: andrew.cooper3@xxxxxxxxxx; george.dunlap@xxxxxxxxxxxxx; Tian, Kevin;
>> Zhang, Yang Z; xen-devel@xxxxxxxxxxxxx; keir@xxxxxxx 
>> Subject: RE: [v3 10/15] vt-d: Add API to update IRTE when VT-d PI is used
>> 
>> >>> On 15.07.15 at 08:04, <feng.wu@xxxxxxxxx> wrote:
>> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> >> Sent: Friday, July 10, 2015 10:02 PM
>> >> I'm particularly worried by the call to acpi_find_matched_drhd_unit()
>> >> - is it maybe worth storing the iommu pointer in struct msi_desc?
>> >
>> > I think it worth, Like Andrew also mentioned this point before. I tend
>> > to make this a independent work and do it later, since the 4.6 release
>> > is coming, I am still try my best to target it. Could you please share
>> > your concern here, performance? Or other things? Thanks!
>> 
>> Interrupt latency in particular.
> 
> This update IRTE operation is not so frequently. It only happens in few 
> times,
> especially in the initialization phase of the guest. And even the guest set
> the affinity, in the MSI/MSIx configuration doesn't change, QEMU will not
> ask Xen to update it.

When the guest sets the affinity, the MSI{,-X} configuration is
rather likely to change (at least for Linux guests).

>> There are two possible scenarios:
>> 
>> 1) There are bits that can be updated behind the back of the code
>> here. In that case you need to loop, and each iteration of the loop
>> needs to re-fetch the current value (not doing so would make the
>> loop infinite).
> 
> Oh, yes, I think I made a mistake here, it is too hastily these days,
> Sorry for that! I think I need do it like this:
> 
>     do {
>         new_ire = *p;
> 
>         /* Setup/Update interrupt remapping table entry. */
>         setup_posted_irte(&new_ire, pi_desc, gvec);
> 
>         old_ire = *(uint128_t *)p;
>         ret = cmpxchg16b(p, &old_ire, &new_ire);
>     } while ( memcmp(&ret, &old_ire, sizeof(old_ire)) );

So since you put this in a loop again, would you mind pointing out
which bits can get modified behind our back?

Jan


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