Re: [PATCH] Don't track all memory when enabling log dirty to track vram

[George Dunlap <george.dunlap@eu.citrix.com>]

On 05/19/2014 02:50 PM, Jan Beulich wrote:
>>>> On 19.05.14 at 15:27, <George.Dunlap@eu.citrix.com> wrote:
>> On Mon, May 19, 2014 at 8:48 AM, Zhang, Yang Z <yang.z.zhang@intel.com> wrote:
>>> Because I just noticed that someone is asking when Intel will implement the
>> VT-d page table separately. Actually, I am totally unaware it. The original
>> issue that this patch tries to fix is the VRAM tracking which using the
>> global log dirty mode. And I thought the best solution to fix it is in VRAM
>> side not VT-d side. Because even use separate VT-d page table, we still
>> cannot track the memory update from DMA. Even worse, I think two page tables
>> introduce redundant code and maintain effort. So I wonder is it really
>> necessary to implement the separate VT-d large page?
>>
>> Yes, it does introduce redundant code.  But unfortunately, IOMMU
>> faults at the moment have to be considered rather risky; having on
>> happens risks (in order of decreasing probability / increasing
>> damage):
>> * Device stops working for that VM until an FLR (losing a lot of its state)
>> * The VM has to be killed
>> * The device stops working until a host reboot
>> * The host crashes
>>
>> Avoiding these by "hoping" that the guest OS doesn't DMA into a video
>> buffer isn't really robust enough.  I think that was Tim and Jan's
>> primary reason for wanting the ability to have separate tables for HAP
>> and IOMMU.
>>
>> Is that about right, Jan / Tim?
> Yes, and not just "about" (perhaps with the exception that I think/
> hope we don't have any lurking host crashes here).

I think the fear was that buggy hardware might cause a host crash / hang.

  -George