[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.