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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 19.05.14 at 15:59, <george.dunlap@xxxxxxxxxxxxx> wrote:
> On 05/19/2014 02:50 PM, Jan Beulich wrote:
>>>>> On 19.05.14 at 15:27, <George.Dunlap@xxxxxxxxxxxxx> wrote:
>>> On Mon, May 19, 2014 at 8:48 AM, Zhang, Yang Z <yang.z.zhang@xxxxxxxxx> 
>>> 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.

That's a valid concern indeed.

Jan


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