>>> On 21.12.15 at 15:08, <quan...@intel.com> wrote: >> On 21.12.2015 at 9:23pm, <jbeul...@suse.com> wrote: >> >>> On 21.12.15 at 14:08, <quan...@intel.com> wrote: >> >> On 21.12.2015 at 8:50pm, <jbeul...@suse.com> wrote: >> >> >>> On 21.12.15 at 13:28, <quan...@intel.com> wrote: >> >> > On 21.12.2015 at 7:47pm, <jbeul...@suse.com> wrote: >> >> >> >>> On 20.12.15 at 14:57, <quan...@intel.com> 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@lists.xen.org http://lists.xen.org/xen-devel
