[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:53pm, <JBeulich@xxxxxxxx> wrote: > >>> 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, Never mind.. I understand that. But could you forward the result to me? when you are available. I am really not in the previous thread and I can't find in in my Xen maillist archive. Thanks. Quan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |