From patchwork Fri Apr 7 12:17:44 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yu Zhang X-Patchwork-Id: 9669391 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 84792602B3 for ; Fri, 7 Apr 2017 12:20:37 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7419F26E48 for ; Fri, 7 Apr 2017 12:20:37 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 689E0284F4; Fri, 7 Apr 2017 12:20:37 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 043E226E48 for ; Fri, 7 Apr 2017 12:20:37 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwSqW-0005Nn-B7; Fri, 07 Apr 2017 12:18:32 +0000 Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwSqV-0005Nc-5f for xen-devel@lists.xen.org; Fri, 07 Apr 2017 12:18:31 +0000 Received: from [85.158.143.35] by server-4.bemta-6.messagelabs.com id 34/86-03012-69387E85; Fri, 07 Apr 2017 12:18:30 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRWlGSWpSXmKPExsXS1tYhrzu1+Xm EwdcnJhZLPi5mcWD0OLr7N1MAYxRrZl5SfkUCa8bxQ19YCxZpVayZ3s/YwPhHuouRk0NIoELi y/Ur7CC2hACvxJFlM1ghbH+JvkmPGbsYuYBq5jNKvH/4B6xIWKBM4tDXeWC2iICyRO+v3ywQg 94ySRx7JwNiMwusYpLYtl0PxGYT0Jb4sfo3I4jNK6AncWzbHDCbRUBFon/eabA5ogLRErvPNT BD1AhKnJz5BGwmp4C9xJz1EHuZBcwk5m1+yAxhy0tsfzuHeQKjwCwkLbOQlM1CUraAkXkVo3p xalFZapGuoV5SUWZ6RkluYmaOrqGBmV5uanFxYnpqTmJSsV5yfu4mRmBwMgDBDsadz50OMUpy MCmJ8ir4PIkQ4kvKT6nMSCzOiC8qzUktPsQow8GhJMGr0/Q8QkiwKDU9tSItMwcYJzBpCQ4eJ RHe/kagNG9xQWJucWY6ROoUoy7Hu6Uf3jMJseTl56VKifPeBykSACnKKM2DGwGL2UuMslLCvI xARwnxFKQW5WaWoMq/YhTnYFQS5r0OMoUnM68EbtMroCOYgI7wufUU5IiSRISUVAOjvOmfhO8 HPE+Fbjyt8fL8IfeKzn7RNC6RLdtshU8Vb5ugv29Gx4ylFpe3vbXXYH9yWt3yujJ/7YnNj7Q3 GF69XcEi+XTi8zVfNk36fPXTVYe9m66InMvbeyYursPUmXPmdOfLJ1gizj87pRi6x6GsZ0PCy o67y3fkm0yxnie7cOGTM1Vph/QeOimxFGckGmoxFxUnAgAAX7Gg1AIAAA== X-Env-Sender: yu.c.zhang@linux.intel.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1491567507!59251926!1 X-Originating-IP: [134.134.136.31] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 9.4.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 45318 invoked from network); 7 Apr 2017 12:18:29 -0000 Received: from mga06.intel.com (HELO mga06.intel.com) (134.134.136.31) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 7 Apr 2017 12:18:29 -0000 Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga104.jf.intel.com with ESMTP; 07 Apr 2017 05:18:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,165,1488873600"; d="scan'208";a="953348140" Received: from zhangyu-win7x64.ccr.corp.intel.com (HELO [10.238.135.171]) ([10.238.135.171]) by orsmga003.jf.intel.com with ESMTP; 07 Apr 2017 05:18:24 -0700 To: Jan Beulich References: <1491494017-30743-1-git-send-email-yu.c.zhang@linux.intel.com> <1491494017-30743-6-git-send-email-yu.c.zhang@linux.intel.com> <58E77AAB020000780014E68E@prv-mh.provo.novell.com> <58E7669C.6060205@linux.intel.com> <7a0bfe1f-fc10-3c4e-8617-e2aa11ea79fe@citrix.com> <58E76F05.3000109@linux.intel.com> <58E79413020000780014E7FA@prv-mh.provo.novell.com> From: Yu Zhang Message-ID: <58E78368.9020904@linux.intel.com> Date: Fri, 7 Apr 2017 20:17:44 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <58E79413020000780014E7FA@prv-mh.provo.novell.com> Cc: Kevin Tian , George Dunlap , Andrew Cooper , George Dunlap , xen-devel@lists.xen.org, Paul Durrant , zhiyuan.lv@intel.com, Jun Nakajima Subject: Re: [Xen-devel] [PATCH v12 5/6] x86/ioreq server: Asynchronously reset outstanding p2m_ioreq_server entries. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP On 4/7/2017 7:28 PM, Jan Beulich wrote: >>>> On 07.04.17 at 12:50, wrote: >> On 4/7/2017 6:28 PM, George Dunlap wrote: >>> On 07/04/17 11:14, Yu Zhang wrote: >>>> On 4/7/2017 5:40 PM, Jan Beulich wrote: >>>>>>>> On 06.04.17 at 17:53, wrote: >>>>>> --- a/xen/arch/x86/mm/p2m-ept.c >>>>>> +++ b/xen/arch/x86/mm/p2m-ept.c >>>>>> @@ -544,6 +544,12 @@ static int resolve_misconfig(struct p2m_domain >>>>>> *p2m, unsigned long gfn) >>>>>> e.ipat = ipat; >>>>>> if ( e.recalc && p2m_is_changeable(e.sa_p2mt) ) >>>>>> { >>>>>> + if ( e.sa_p2mt == p2m_ioreq_server ) >>>>>> + { >>>>>> + ASSERT(p2m->ioreq.entry_count > 0); >>>>>> + p2m->ioreq.entry_count--; >>>>>> + } >>>>>> + >>>>>> e.sa_p2mt = p2m_is_logdirty_range(p2m, gfn >>>>>> + i, gfn + i) >>>>>> ? p2m_ram_logdirty : p2m_ram_rw; >>>>> I don't think this can be right: Why would it be valid to change the >>>>> type from p2m_ioreq_server to p2m_ram_rw (or p2m_ram_logdirty) >>>>> here, without taking into account further information? This code >>>>> can run at any time, not just when you want to reset things. So at >>>>> the very least there is a check missing whether a suitable ioreq >>>>> server still exists (and only if it doesn't you want to do the type >>>>> reset). >>>> Also I do not think we need to check if a suitable ioreq server still >>>> exists. We have guaranteed >>>> in our patch that no new ioreq server will be mapped as long as the p2m >>>> table is not clean. :) >>> Jan is saying that you should only change ioreq_server -> ram if there >>> is *not* an ioreq server; and that if this is called with an ioreq >>> server still active, then it must be some other change you're looking at. >>> >>> The problem, though, is that misconfiguration happens in many >>> circumstances. Grep for "memory_type_changed()" -- each of those >>> results in a recalculation of the entire p2m, which will (in the current >>> code) wipe out any ioreq_server entries. >> Well, I'm not aware that other actions besides the logdirty will cause the reset. >> But if that would happen, will below change solve this? >> >> @@ -546,12 +546,16 @@ static int resolve_misconfig(struct p2m_domain *p2m, unsigned long gfn) >> { >> if ( e.sa_p2mt == p2m_ioreq_server ) >> { >> - ASSERT(p2m->ioreq.entry_count > 0); >> - p2m->ioreq.entry_count--; >> + if ( p2m->ioreq.server == NULL ) >> + { >> + ASSERT(p2m->ioreq.entry_count > 0); >> + p2m->ioreq.entry_count--; >> + e.sa_p2mt = p2m_ram_rw; >> + } >> } >> - >> - e.sa_p2mt = p2m_is_logdirty_range(p2m, gfn + i, gfn + i) >> - ? p2m_ram_logdirty : p2m_ram_rw; >> + else >> + e.sa_p2mt = p2m_is_logdirty_range(p2m, gfn + i, gfn + i) >> + ? p2m_ram_logdirty : p2m_ram_rw; > Now you _never_ change away from ioreq-server, you only adjust > the counter. Oh right. Then sth. like: p2m_type_t p2mt = p2m_is_logdirty_range(p2m, gfn & mask, gfn | ~mask) But as you can see. I used p2m_check_changeable() here. Yu > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c index ecd5ceb..b960a1d 100644 --- a/xen/arch/x86/mm/p2m-ept.c +++ b/xen/arch/x86/mm/p2m-ept.c @@ -542,7 +542,10 @@ static int resolve_misconfig(struct p2m_domain *p2m, unsigned long gfn) _mfn(e.mfn), 0, &ipat, e.sa_p2mt == p2m_mmio_direct); e.ipat = ipat; - if ( e.recalc && p2m_is_changeable(e.sa_p2mt) ) + if ( e.recalc && + (p2m_check_changeable(e.sa_p2mt) || + (e.sa_p2mt == p2m_ioreq_server && + p2m->ioreq.server == NULL)) ) { if ( e.sa_p2mt == p2m_ioreq_server ) { diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c index 4b2ff9e..1c600b1 100644 --- a/xen/arch/x86/mm/p2m-pt.c +++ b/xen/arch/x86/mm/p2m-pt.c @@ -442,7 +442,8 @@ static int do_recalc(struct p2m_domain *p2m, unsigned long gfn) P2M_DEBUG("bogus recalc leaf at d%d:%lx:%u\n", p2m->domain->domain_id, gfn, level); p2mt_old = p2m_flags_to_type(l1e_get_flags(e)); - if ( p2m_is_changeable(p2mt_old) ) + if ( p2m_check_changeable(p2mt_old) || + (p2mt_old == p2m_ioreq_server && p2m->ioreq.server == NULL) ) { unsigned long mask = ~0UL << (level * PAGETABLE_ORDER);