From xen-devel-bounces@lists.xen.org Sat May 31 02:34:14 2014 Received: (at maildrop) by bugs.xenproject.org; 31 May 2014 01:34:15 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WqYBa-0004T7-Tq for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Sat, 31 May 2014 02:34:14 +0100 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WqY3y-0006H0-Nc; Sat, 31 May 2014 01:26:22 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WqY3x-0006Gv-5x for xen-devel@lists.xen.org; Sat, 31 May 2014 01:26:21 +0000 Received: from [193.109.254.147:49785] by server-7.bemta-14.messagelabs.com id 83/F2-17726-CBF29835; Sat, 31 May 2014 01:26:20 +0000 X-Env-Sender: jun.nakajima@intel.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1401499579!8142959!1 X-Originating-IP: [209.85.215.43] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21689 invoked from network); 31 May 2014 01:26:19 -0000 Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com) (209.85.215.43) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 31 May 2014 01:26:19 -0000 Received: by mail-la0-f43.google.com with SMTP id mc6so1447967lab.30 for ; Fri, 30 May 2014 18:26:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9Ie8SQJr5K+f1cSrqzpQ+tX1nr9L3Sx27rL+AyPjAFM=; b=mUH4kEZY+8GUcM0N70BAL45Zdc6ivdylXCzzWy5vhwzzB04GyC/QsRMNfIYwA/QuV3 YAHe3wnRmP+bWdlIwplPuBOofAhqtTiH643/rFWMtaNVodSDMKaJx9px4DIL6OzpbLMz XQNjXGFmECzFry8GzU439jrM9B1G6AB3rKztXY3fbWlrwqdEm2MUyiQGs6lYhD5zoofu RwjMeb9uJahNpXHOt1NDVcz+Z53LpOOZFnt+zlOkZ13bGLdw9Ev4LGsyE3PE0gvY+XIv ACZNthyn+TTB1SoKGK8ejyfCZljzzdqwUnP5IzT6opyUxxWAzIXfr6k1XgM9SU2aKeeh OS+A== X-Gm-Message-State: ALoCoQnT0etiKkC1p3BzY3kaWDGw/8K4qPFc2oNT8DZVVFlrS/oZOkvgHcY19Hunah0YxElzdocm MIME-Version: 1.0 X-Received: by 10.152.5.135 with SMTP id s7mr15573706las.55.1401499578761; Fri, 30 May 2014 18:26:18 -0700 (PDT) Received: by 10.152.132.198 with HTTP; Fri, 30 May 2014 18:26:18 -0700 (PDT) In-Reply-To: <53831FD902000078000159F9@mail.emea.novell.com> 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> <53831FD902000078000159F9@mail.emea.novell.com> Date: Fri, 30 May 2014 18:26:18 -0700 Message-ID: From: "Nakajima, Jun" To: Jan Beulich Cc: George Dunlap , "andrew.cooper3@citrix.com" , Tim Deegan , "xen-devel@lists.xen.org" , "KeirFraser\(keir.xen@gmail.com\)" , Yang Z Zhang , 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 Mon, May 26, 2014 at 2:04 AM, Jan Beulich wrote: >>>> 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). > The tool xen-access is located in tools/tests, and I think that this is used mostly by developers who know what they are doing. If we had separate VT-d page tables, they might observe confusing results; even if they write-protect pages, somebody (i.e. I/O devices) modifies those pages. To me, observing IOMMU faults seems consistent with the consequence of changes to guest memory permission. -- Jun Intel Open Source Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel