From xen-devel-bounces@lists.xen.org Mon May 26 10:11:53 2014 Received: (at maildrop) by bugs.xenproject.org; 26 May 2014 09:11:53 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1Woqwi-0003hn-Uf for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Mon, 26 May 2014 10:11:53 +0100 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Woqq7-00063d-4D; Mon, 26 May 2014 09:05:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Woqq5-00063X-6a for xen-devel@lists.xen.org; Mon, 26 May 2014 09:05:01 +0000 Received: from [85.158.143.35:5336] by server-2.bemta-4.messagelabs.com id A6/0B-06539-CB303835; Mon, 26 May 2014 09:05:00 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1401095099!7201695!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 26528 invoked from network); 26 May 2014 09:04:59 -0000 Received: from mail.emea.novell.com (HELO mail.emea.novell.com) (130.57.118.101) by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 May 2014 09:04:59 -0000 Received: from EMEA1-MTA by mail.emea.novell.com with Novell_GroupWise; Mon, 26 May 2014 10:04:59 +0100 Message-Id: <53831FD902000078000159F9@mail.emea.novell.com> X-Mailer: Novell GroupWise Internet Agent 14.0.0 Date: Mon, 26 May 2014 10:04:57 +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> <537B1E520200007800013EB7@mail.emea.novell.com> <537B4EA70200007800014085@mail.emea.novell.com> <537C769B02000078000145C2@mail.emea.novell.com> <537F09EC020000780001530D@mail.emea.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: George Dunlap , "andrew.cooper3@citrix.com" , Tim Deegan , "xen-devel@lists.xen.org" , "KeirFraser\(keir.xen@gmail.com\)" , 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 26.05.14 at 10:16, wrote: > 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? The (example) tool indeed is named xen-access. See XENMEM_access_op (used to be HVMOP_{get,set}_mem_access). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel