From xen-devel-bounces@lists.xen.org Mon Feb 10 08:20:59 2014 Received: (at maildrop) by bugs.xenproject.org; 10 Feb 2014 08:20:59 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WCm6t-0003N4-0d for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Mon, 10 Feb 2014 08:20:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WCm1r-0002rN-OQ; Mon, 10 Feb 2014 08:15:47 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WCm1p-0002rG-IU for xen-devel@lists.xen.org; Mon, 10 Feb 2014 08:15:45 +0000 Received: from [85.158.137.68:25873] by server-12.bemta-3.messagelabs.com id 2E/84-01674-0BA88F25; Mon, 10 Feb 2014 08:15:44 +0000 X-Env-Sender: yang.z.zhang@intel.com X-Msg-Ref: server-16.tower-31.messagelabs.com!1392020142!753112!1 X-Originating-IP: [134.134.136.20] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzU1MzU4\n X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4420 invoked from network); 10 Feb 2014 08:15:44 -0000 Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by server-16.tower-31.messagelabs.com with SMTP; 10 Feb 2014 08:15:44 -0000 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 10 Feb 2014 00:15:42 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.95,816,1384329600"; d="scan'208";a="480773311" Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36]) by orsmga002.jf.intel.com with ESMTP; 10 Feb 2014 00:15:22 -0800 Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 10 Feb 2014 00:15:18 -0800 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 10 Feb 2014 00:15:18 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.195]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.185]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 16:15:16 +0800 From: "Zhang, Yang Z" To: Tim Deegan Thread-Topic: [PATCH] Don't track all memory when enabling log dirty to track vram Thread-Index: AQHPJjaWGU8BoIe0JUmrwANmd1LxUZquITGw Date: Mon, 10 Feb 2014 08:15:16 +0000 Message-ID: References: <1392012840-22555-1-git-send-email-yang.z.zhang@intel.com> <20140210080314.GA758@deinos.phlegethon.org> In-Reply-To: <20140210080314.GA758@deinos.phlegethon.org> 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: "andrew.cooper3@citrix.com" , "Zhang, Xiantao" , "JBeulich@suse.com" , "xen-devel@lists.xen.org" 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 Tim Deegan wrote on 2014-02-10: > At 14:14 +0800 on 10 Feb (1392038040), Yang Zhang wrote: >> From: Yang Zhang >> >> When enabling log dirty mode, it sets all guest's memory to readonly. >> And in HAP enabled domain, it modifies all EPT entries to clear >> write bit to make sure it is readonly. This will cause problem if >> VT-d shares page table with EPT: the device may issue a DMA write >> request, then VT-d engine tells it the target memory is readonly and >> result in VT-d > fault. > > So that's a problem even if only the VGA framebuffer is being tracked > -- DMA from a passthrough device will either cause a spurious error or > fail to update the dirt bitmap. Do you mean the VGA frambuffer will be used as DMA buffer in guest? If yes, I think it's guest's responsibility to ensure it never happens. > > I think it would be better not to allow VT-d and EPT to share > pagetables in cases where devices are passed through (i.e. all cases where VT-d is in use). Without VT-d and EPT share page, we still cannot track the memory updating from DMA. I think the point is that we cannot track the memory updating via DMA. So the user should use the log dirty mode carefully. Also, I am not sure whether the memory updating from dom0 and QEMU is tracked currently. > > Tim. Best regards, Yang _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel