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

["Wu, Feng" <feng.wu@xxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Wednesday, July 15, 2015 4:46 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 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).

Yes, it is. But I'd say, it is not a frequent operation. In my test, it only 
happens
in the initialization phase and some updates doesn't go the Xen since the
configuration is the same (QEMU filters it). And I agree I will change this,
my question is that can we put this a little late, and I can focus on some
other critical issue before 4.6 is release, which may make more chance for
this patch to catch up with 4.6. Is this okay for you?

Thanks,
Feng

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