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:55, <feng.wu@xxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Wednesday, July 15, 2015 4:46 PM
>> >>> On 15.07.15 at 10:38, <feng.wu@xxxxxxxxx> wrote:
>> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> >> Sent: Wednesday, July 15, 2015 4:25 PM
>> >> >>> 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).

Can I please ask you to move away from this way of thinking? What
you see in experiments is useful from a functionality pov, but pretty
meaningless from a security perspective. For that, you'd rather start
thinking about what a _malicious_ guest might be doing.

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

As long as the feature (due to the other issue) remains experimental,
is off by default, and the code has a prominent comment outlining the
intended improvement, I'd be fine, yes.

Jan


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