From xen-devel-bounces@lists.xen.org Tue May 20 08:24:49 2014 Received: (at maildrop) by bugs.xenproject.org; 20 May 2014 07:24:49 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WmePp-0007dS-JI for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Tue, 20 May 2014 08:24:49 +0100 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WmeIt-0001pc-3P; Tue, 20 May 2014 07:17:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WmeIr-0001pW-Pa for xen-devel@lists.xen.org; Tue, 20 May 2014 07:17:38 +0000 Received: from [85.158.139.211:43601] by server-7.bemta-5.messagelabs.com id 6E/8B-20531-0910B735; Tue, 20 May 2014 07:17:36 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-206.messagelabs.com!1400570256!5231133!1 X-Originating-IP: [130.57.118.101] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5306 invoked from network); 20 May 2014 07:17:36 -0000 Received: from mail.emea.novell.com (HELO mail.emea.novell.com) (130.57.118.101) by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 May 2014 07:17:36 -0000 Received: from EMEA1-MTA by mail.emea.novell.com with Novell_GroupWise; Tue, 20 May 2014 08:17:35 +0100 Message-Id: <537B1DAF0200007800013EAB@mail.emea.novell.com> X-Mailer: Novell GroupWise Internet Agent 14.0.0 Date: Tue, 20 May 2014 08:17:35 +0100 From: "Jan Beulich" To: "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> <5379E50702000078000136F6@mail.emea.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: Keir Fraser , George Dunlap , "andrew.cooper3@citrix.com" , Tim Deegan , "xen-devel@lists.xen.org" , 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-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 >>> On 20.05.14 at 05:09, wrote: > Jan Beulich wrote on 2014-05-19: >>>>> On 19.05.14 at 09:48, 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. >> >> This was a request sent directly to you, so it shouldn't be a surprise. > > Yes, but I am not buying in it since I think it not the right direction to > fix this issue: > > This is my original point: > Actually, the first solution came to my mind is B. Then I realized that even > chose B, we still cannot track the memory updating from DMA(even with A/D > bit, it still a problem). Also, considering the current usage case of log > dirty in Xen(only vram tracking has problem), I though A is better.: > Hypervisor only need to track the vram change. If a malicious guest try to > DMA to vram range, it only crashed himself (This should be reasonable). Except that the guest in no way needs to be malicious. I think you forget that the ultimate goal of virtualization ought to be to make guests behave the same (in terms of correctness, not generally in terms of performance) as if run on real hardware, not matter what they do. And DMA to VRAM wouldn't crash on real hardware (and I can see legitimate uses of such). >>> 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. >> >> Correct. But at least we can avoid IOMMU faults by not marking read- >> only the VRAM region. Unless the guest stores data in the VRAM region > > It is easy to trigger an IOMMU faults by guest, like set an invalid DMA > address. We cannot prevent it. Correct (and this btw also contradicts above spelled out goal: On real hardware this would in the majority of cases also just cause certain operations to become ineffectual rather than bring down the system - we just have to be more rigid here to deal with potential malicious guests). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel