From xen-devel-bounces@lists.xen.org Thu Feb 13 16:31:25 2014 Received: (at maildrop) by bugs.xenproject.org; 13 Feb 2014 16:31:25 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WDzC9-0002cq-QV for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Thu, 13 Feb 2014 16:31:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WDz73-0005DL-OD; Thu, 13 Feb 2014 16:26:09 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WDz73-0005DG-1j for xen-devel@lists.xen.org; Thu, 13 Feb 2014 16:26:09 +0000 Received: from [85.158.139.211:8583] by server-3.bemta-5.messagelabs.com id F3/83-13671-022FCF25; Thu, 13 Feb 2014 16:26:08 +0000 X-Env-Sender: George.Dunlap@citrix.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1392308765!3721666!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23354 invoked from network); 13 Feb 2014 16:26:06 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 13 Feb 2014 16:26:06 -0000 X-IronPort-AV: E=Sophos;i="4.95,839,1384300800"; d="scan'208";a="102288168" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP; 13 Feb 2014 16:26:04 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.2.342.4; Thu, 13 Feb 2014 11:26:04 -0500 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1WDz6x-000319-Ts; Thu, 13 Feb 2014 16:26:03 +0000 Message-ID: <52FCF210.7090702@eu.citrix.com> Date: Thu, 13 Feb 2014 16:25:52 +0000 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Tim Deegan , Jan Beulich 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: <20140213162022.GE82703@deinos.phlegethon.org> X-DLP: MIA2 Cc: Yang Z Zhang , "andrew.cooper3@citrix.com" , xenbugs , Xiantao Zhang , "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-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 title 38 Implement VT-d large pages so we can avoid sharing between EPT and IOMMU owner it Yang Z Zhang thanks On 02/13/2014 04:20 PM, Tim Deegan wrote: > 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. OK -- I've retitled the bug and am going to leave it open. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel