From xen-devel-bounces@lists.xen.org Thu Feb 13 16:25:58 2014 Received: (at maildrop) by bugs.xenproject.org; 13 Feb 2014 16:25:58 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WDz6s-0002Yl-MN for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Thu, 13 Feb 2014 16:25:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WDz1d-0004wE-RJ; Thu, 13 Feb 2014 16:20:33 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WDz1b-0004w9-UQ for xen-devel@lists.xen.org; Thu, 13 Feb 2014 16:20:32 +0000 Received: from [85.158.139.211:55630] by server-14.bemta-5.messagelabs.com id E8/04-27598-FC0FCF25; Thu, 13 Feb 2014 16:20:31 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-16.tower-206.messagelabs.com!1392308430!3744729!1 X-Originating-IP: [5.39.92.215] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13284 invoked from network); 13 Feb 2014 16:20:30 -0000 Received: from deinos.phlegethon.org (HELO mail.phlegethon.org) (5.39.92.215) by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Feb 2014 16:20:30 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WDz1S-0002gg-BO; Thu, 13 Feb 2014 16:20:22 +0000 Date: Thu, 13 Feb 2014 17:20:22 +0100 From: Tim Deegan To: Jan Beulich Message-ID: <20140213162022.GE82703@deinos.phlegethon.org> 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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <52FCF90F020000780011C29A@nat28.tlf.novell.com> User-Agent: Mutt/1.5.22 (2013-10-16) X-SA-Known-Good: Yes X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tim@xen.org X-SA-Exim-Scanned: No (on mail.phlegethon.org); SAEximRunCond expanded to false Cc: George Dunlap , Yang Z Zhang , "xen-devel@lists.xen.org" , Xiantao Zhang , "andrew.cooper3@citrix.com" 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 At 15:55 +0000 on 13 Feb (1392303343), Jan Beulich wrote: > >>> On 13.02.14 at 16:46, George Dunlap wrote: > > On 02/12/2014 12:53 AM, Zhang, Yang Z wrote: > >> George Dunlap wrote on 2014-02-11: > >>> I think I got a bit distracted with the "A isn't really so bad" thing. > >>> Actually, if the overhead of not sharing tables isn't very high, then > >>> B isn't such a bad option. In fact, B is what I expected Yang to > >>> submit when he originally described the problem. > >> 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). > >> > >>> I was going to say, from a release perspective, B is probably the > >>> safest option for now. But on the other hand, if we've been testing > >>> sharing all this time, maybe switching back over to non-sharing whole-hog has > > the higher risk? > >> Another problem with B is that current VT-d large paging supporting relies on > > the sharing EPT and VT-d page table. This means if we choose B, then we need > > to re-enable VT-d large page. This would be a huge performance impaction for > > Xen 4.4 on using VT-d solution. > > > > OK -- if that's the case, then it definitely tips the balance back to > > A. Unless Tim or Jan disagrees, can one of you two check it in? > > > > Don't rush your judgement; but it would be nice to have this in before > > RC4, which would mean checking it in today preferrably, or early > > tomorrow at the latest. > > That would be Tim then, as he would have to approve of it anyway. Done. > I should also say that while I certainly understand the argumentation > above, I would still want to go this route only with the promise that > B is going to be worked on reasonably soon after the release, ideally > with the goal of backporting the changes for 4.4.1. Agreed. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel