[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


 


Rackspace

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