From xen-devel-bounces@lists.xen.org Tue May 20 04:20:20 2014 Received: (at maildrop) by bugs.xenproject.org; 20 May 2014 03:20:20 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WmabE-00058x-Fy for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Tue, 20 May 2014 04:20:20 +0100 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WmaUb-0006LR-3n; Tue, 20 May 2014 03:13:29 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WmaUZ-0006LK-Q4 for xen-devel@lists.xen.org; Tue, 20 May 2014 03:13:28 +0000 Received: from [85.158.139.211:62539] by server-11.bemta-5.messagelabs.com id 40/98-30804-758CA735; Tue, 20 May 2014 03:13:27 +0000 X-Env-Sender: yang.z.zhang@intel.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1400555605!1833360!1 X-Originating-IP: [192.55.52.88] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15067 invoked from network); 20 May 2014 03:13:26 -0000 Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88) by server-15.tower-206.messagelabs.com with SMTP; 20 May 2014 03:13:26 -0000 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 19 May 2014 20:13:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.98,870,1392192000"; d="scan'208";a="534573629" Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35]) by fmsmga001.fm.intel.com with ESMTP; 19 May 2014 20:13:24 -0700 Received: from fmsmsx113.amr.corp.intel.com (10.18.116.7) by FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 19 May 2014 20:13:24 -0700 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by FMSMSX113.amr.corp.intel.com (10.18.116.7) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 19 May 2014 20:13:24 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.192]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.34]) with mapi id 14.03.0123.003; Tue, 20 May 2014 11:13:21 +0800 From: "Zhang, Yang Z" To: George Dunlap Thread-Topic: [Xen-devel] [PATCH] Don't track all memory when enabling log dirty to track vram Thread-Index: AQHPJjaWGU8BoIe0JUmrwANmd1LxUZquITGwgAIV/CWAAJImEIACCY0AgAACsICAAAbjAICVQRIQ///cPoCAAWvb4A== Date: Tue, 20 May 2014 03:13:20 +0000 Message-ID: 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> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: Jan Beulich , "andrew.cooper3@citrix.com" , Tim Deegan , "xen-devel@lists.xen.org" , "Keir Fraser \(keir.xen@gmail.com\)" , "Nakajima, Jun" , "Zhang, Xiantao" 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org George Dunlap wrote on 2014-05-19: >> >> Hi all >> >> Sorry to turn out this old thread. >> 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 You cannot prevent guest to trigger the IOMMU faults. It is easy to trigger an IOMMU fault by setting a invalid DMA address. > 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 Video buffer is only one case. How we can prevent the DMA to other reserved region? > primary reason for wanting the ability to have separate tables for HAP and IOMMU. > > Is that about right, Jan / Tim? > > -George Best regards, Yang _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel