Re: [Xen-devel] [PATCH v3 0/2] VT-d flush issue

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.12.15 at 15:31, <quan.xu@xxxxxxxxx> wrote:
>>  On 21.12.2015 at 10:16pm, <JBeulich@xxxxxxxx> wrote:
>> >>> On 21.12.15 at 15:08, <quan.xu@xxxxxxxxx> wrote:
>> >>  On 21.12.2015 at 9:23pm, <JBeulich@xxxxxxxx> wrote:
>> >> >>> On 21.12.15 at 14:08, <quan.xu@xxxxxxxxx> wrote:
>> >> >>  On 21.12.2015 at 8:50pm, <JBeulich@xxxxxxxx> wrote:
>> >> >> >>> On 21.12.15 at 13:28, <quan.xu@xxxxxxxxx> wrote:
>> >> >> > On 21.12.2015 at 7:47pm, <JBeulich@xxxxxxxx> wrote:
>> >> >> >> >>> On 20.12.15 at 14:57, <quan.xu@xxxxxxxxx> wrote:
>> >
>> > 1.
>> >> >> > IMO, When VT-d is enabled, but is not working correct. These
>> >> >> > PCI-e devices
>> >> >> > (Disks/NICs..) DMA/Interrupt behaviors are not predictable.
>> >> >> > Assumed that, VT-d is effectively not in use for domains without
>> >> >> > PT device, while at least the virtualization infrastructure is not 
> trusted.
>> >
>> > 2.
>> >> >> > IMO, a VT-d (IEC/Context/Iotlb) flush issue is not a single
>> >> >> > domain behavior, it is a Hypervisor and infrastructure issue.
>> >> >> > ATS device's Device-TLB flush is a single domain issue.
>> >
>> > One quick question,
>> > Jan, do you agreed the above 2 descriptions?
>> 
>> I agree, but (see also Andrew's earlier reply) don't take them as an excuse 
>> to
>> crash Xen upon flush failures. Please accept that the general policy has to 
>> be to
>> handle errors with as narrow an impact as possible.
>>
> 
> That maybe the gap between us. It is really an issue that require to crash 
> Xen.
> 
> I think we are on the same page for Device-TLB flush issue.
> Could you share your idea how to deal with VT-d (IEC/Context/Iotlb) flush 
> issue?  Thanks.

I think this was sufficiently outlined before, by both Andrew and me.
I'm sorry, but I'm not willing to start over with the discussion.

Jan


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