Re: [Xen-devel] [PATCH v3 0/2] VT-d flush issue

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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:
>> > 2. If VT-d is bug, does the hardware_domain continue to work with PCIe
>> > Devices / DRAM well with DMA remapping error?
>> >    I think it is no. furthermore, i think VMM can NOT run a normal HVM
>> > domain without device-passthrough.
>> 
>> In addition to what Andrew said - VT-d is effectively not in use for domains
>> without PT device.
> 
> 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.
> I think it is also not secure to run PV domains.
> 
>> Impacting all such domains by crashing the hypervisor just
>> because (in the extreme case) a single domain with PT devices exhibited a 
>> flush
>> issue is a no-go imo.
>> 
> 
> 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.
> Back to our original goal, my patch set is for ATS flush issue. right?

You mean you don't like this entailing clean up of other code? I'm
sorry, but I'm afraid you won't get away without - perhaps the
VT-d maintainers could help here, but in the end you have to face
that it was mainly Intel people who introduced the code which now
needs fixing up, so I consider it not exactly unfair for you (as a
company) to do this work.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel