From xen-devel-bounces@lists.xen.org Mon May 19 15:19:29 2014 Received: (at maildrop) by bugs.xenproject.org; 19 May 2014 14:19:29 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WmOPY-0005he-W3 for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Mon, 19 May 2014 15:19:28 +0100 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WmOIn-0001PO-HD; Mon, 19 May 2014 14:12:29 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WmOIl-0001PE-AM for xen-devel@lists.xen.org; Mon, 19 May 2014 14:12:27 +0000 Received: from [193.109.254.147:59009] by server-10.bemta-14.messagelabs.com id 7C/1B-04546-A411A735; Mon, 19 May 2014 14:12:26 +0000 X-Env-Sender: George.Dunlap@citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1400508744!5750542!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19962 invoked from network); 19 May 2014 14:12:25 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 19 May 2014 14:12:25 -0000 X-IronPort-AV: E=Sophos;i="4.98,867,1392163200"; d="scan'208";a="132407611" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 19 May 2014 14:11:58 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id 14.3.181.6; Mon, 19 May 2014 10:11:58 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1WmO6Y-0008VZ-4f; Mon, 19 May 2014 14:59:50 +0100 Message-ID: <537A0E55.502@eu.citrix.com> Date: Mon, 19 May 2014 14:59:49 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jan Beulich , Yang Z Zhang 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> In-Reply-To: <537A284F0200007800013ADC@mail.emea.novell.com> X-DLP: MIA2 Cc: "andrew.cooper3@citrix.com" , Tim Deegan , "xen-devel@lists.xen.org" , "Keir Fraser \(keir.xen@gmail.com\)" , Jun Nakajima , Xiantao Zhang Subject: Re: [Xen-devel] [PATCH] Don't track all memory when enabling log dirty to track vram X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel