[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


 


Rackspace

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