From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH] Don't track all memory when enabling log dirty to track vram Date: Mon, 19 May 2014 14:59:49 +0100 Message-ID: <537A0E55.502@eu.citrix.com> References: <20140210080314.GA758@deinos.phlegethon.org> <20140211090202.GC92054@deinos.phlegethon.org> <20140211115553.GB97288@deinos.phlegethon.org> <52FA2C63020000780011B201@nat28.tlf.novell.com> <52FA480D.9040707@eu.citrix.com> <52FCE8BE.8050105@eu.citrix.com> <52FCF90F020000780011C29A@nat28.tlf.novell.com> <20140213162022.GE82703@deinos.phlegethon.org> <537A284F0200007800013ADC@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <537A284F0200007800013ADC@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Yang Z Zhang Cc: "andrew.cooper3@citrix.com" , Tim Deegan , "xen-devel@lists.xen.org" , "Keir Fraser (keir.xen@gmail.com)" , Jun Nakajima , Xiantao Zhang List-Id: xen-devel@lists.xenproject.org On 05/19/2014 02:50 PM, Jan Beulich wrote: >>>> On 19.05.14 at 15:27, wrote: >> On Mon, May 19, 2014 at 8:48 AM, Zhang, Yang Z 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