From xen-devel-bounces@lists.xen.org Mon May 26 09:23:50 2014 Received: (at maildrop) by bugs.xenproject.org; 26 May 2014 08:23:50 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WoqCE-0003Dr-QQ for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Mon, 26 May 2014 09:23:50 +0100 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Woq5V-0005Ze-Qk; Mon, 26 May 2014 08:16:53 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Woq5U-0005ZZ-0u for xen-devel@lists.xen.org; Mon, 26 May 2014 08:16:52 +0000 Received: from [193.109.254.147:3317] by server-2.bemta-14.messagelabs.com id 83/4B-21684-378F2835; Mon, 26 May 2014 08:16:51 +0000 X-Env-Sender: yang.z.zhang@intel.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1401092209!7066618!1 X-Originating-IP: [143.182.124.21] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjYzMTcz\n X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30290 invoked from network); 26 May 2014 08:16:50 -0000 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by server-6.tower-27.messagelabs.com with SMTP; 26 May 2014 08:16:50 -0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 26 May 2014 01:16:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.98,911,1392192000"; d="scan'208";a="436849876" Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228]) by azsmga001.ch.intel.com with ESMTP; 26 May 2014 01:16:48 -0700 Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 26 May 2014 01:16:48 -0700 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, 26 May 2014 01:16:48 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.192]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.23]) with mapi id 14.03.0123.003; Mon, 26 May 2014 16:16:44 +0800 From: "Zhang, Yang Z" To: Jan Beulich Thread-Topic: [Xen-devel] [PATCH] Don't track all memory when enabling log dirty to track vram Thread-Index: AQHPJjaWGU8BoIe0JUmrwANmd1LxUZtIw0CAgAFyMyCAAIpWgIAAhr6QgAKLOQCABVKhMA== Date: Mon, 26 May 2014 08:16:43 +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> <537B1E520200007800013EB7@mail.emea.novell.com> <537B4EA70200007800014085@mail.emea.novell.com> <537C769B02000078000145C2@mail.emea.novell.com> <537F09EC020000780001530D@mail.emea.novell.com> In-Reply-To: <537F09EC020000780001530D@mail.emea.novell.com> 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: George Dunlap , "andrew.cooper3@citrix.com" , Tim Deegan , "xen-devel@lists.xen.org" , "KeirFraser\(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 Jan Beulich wrote on 2014-05-23: >>>> On 21.05.14 at 10:37, wrote: >> Jan Beulich wrote on 2014-05-21: >>> You didn't in any way negate the condition of superpage support to >>> be added post-4.4 in order for your other change to go in: Neither >>> http://lists.xenproject.org/archives/html/xen-devel/2014-02/msg01230. >>> html >>> nor >>> http://lists.xenproject.org/archives/html/xen-devel/2014-02/msg01236. >>> html have been responded to by you. By not doing so, to me at >>> least you implicitly accepted the condition. And by now refusing to >>> meet it, you basically tell us that we shouldn't be doing >>> compromises like this with you in the future. >> >> I have said before I am totally unware of it. And I know it only two >> days ago after someone told me. So please do not confuse this with >> the thing what we are discussing now. If you think I gave a promise >> implicitly at that time, I am sorry to let you think so. >> >> As I said in previous thread, if we can prove that add hugepage for >> the separate VT-d page table is the only choice to solve problem, >> then now I am promising that I will do it ASAP. But till now, I >> didn't see any point that we must to have it. To me, it is still a nice to have feature. > > Btw., I think I just spotted a second thing not working without split page tables: > mem-access (which doesn't and imo shouldn't depend on !need_iommu(), > other than mem-sharing and mem-paging) likewise has the potential of > creating entries resulting in IOMMU faults. > I don't know what mem-access is? Do you mean Xenaccess? If not, can you elaborate it or provide a link to help me to understand how it works? > Jan Best regards, Yang _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel