[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.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. Quan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |