From patchwork Thu Apr 6 08:27:54 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yu Zhang X-Patchwork-Id: 9666379 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 BFB1C6021C for ; Thu, 6 Apr 2017 08:37:36 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B4DEA2684F for ; Thu, 6 Apr 2017 08:37:36 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A9BDF28477; Thu, 6 Apr 2017 08:37:36 +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.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,T_DKIM_INVALID 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 3668D2684F for ; Thu, 6 Apr 2017 08:37:36 +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 1cw2tA-0002xg-66; Thu, 06 Apr 2017 08:35:32 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cw2t9-0002xS-AZ for xen-devel@lists.xen.org; Thu, 06 Apr 2017 08:35:31 +0000 Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id 86/EB-23854-2DDF5E85; Thu, 06 Apr 2017 08:35:30 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMIsWRWlGSWpSXmKPExsVywNwkQvfi36c RBk9mmlgs+biYxYHR4+ju30wBjFGsmXlJ+RUJrBnze3awFRxTrDjy7ypLA+NUqS5GLg4WgUZm ieUn2tlBHCGB6YwS5+feZeti5OSQEOCVOLJsBiuE7S9x9XQHM4gtJDCfUeJurwGILSxQJnGh7 z87iC0i4Cuxd+ccFohBe1gkutedYAZxmAVWMknsevMcbCqbgLbEj9W/GUFsXgE9iZMNv5hAbB YBFYk/q+aCxUUFoiV2n2tghqgRlDg58wnQVA4OTgF7iVsX/UDCzAK2Enfm7maGsOUltr+dwzy BUXAWko5ZSMpmISlbwMi8ilG9OLWoLLVI10gvqSgzPaMkNzEzR9fQwFgvN7W4ODE9NScxqVgv OT93EyMwcOsZGBh3MJ5qdj7EKMnBpCTKq+DzJEKILyk/pTIjsTgjvqg0J7X4EKMMB4eSBK/kn 6cRQoJFqempFWmZOcAYgklLcPAoifC2gqR5iwsSc4sz0yFSpxgVpcR5dUESAiCJjNI8uDZY3F 5ilJUS5mVkYGAQ4ilILcrNLEGVf8UozsGoJMwbCjKFJzOvBG76K6DFTECLfW6BLS5JREhJNTA ePHtIy41hbvD+9pcpyWueBcT/j02sucPAmNBVpCtd9XLB5QM387/kJz/McBYNZ0zInu76f96G b1+uTtQPXCe15I1RxI81Sdeutv6ZpbVEQvw689a7Xz5eC5vUrXI33tX46NIbMSleT3mzOConf 5J8mc9vp69oxzvRolG3qG7NjmvHtXI/LfytxFKckWioxVxUnAgA6tdShdYCAAA= X-Env-Sender: yu.c.zhang@linux.intel.com X-Msg-Ref: server-8.tower-31.messagelabs.com!1491467727!94577827!1 X-Originating-IP: [192.55.52.88] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n X-StarScan-Received: X-StarScan-Version: 9.2.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 56323 invoked from network); 6 Apr 2017 08:35:29 -0000 Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88) by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 6 Apr 2017 08:35:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1491467729; x=1523003729; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=C9EnkJlIIh/8aiomYv1gkvu3rqmluy4jAsEgGjMelgs=; b=ROipYD8vGV74bhd4hgYmVcOvxyLfyAOSU2TbWgdEjG0he39rcktpZAIK RPjuaEcJDwypg1wqVL93U2A9fSgJxw==; Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Apr 2017 01:35:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,283,1488873600"; d="scan'208";a="842566944" Received: from zhangyu-win7x64.ccr.corp.intel.com (HELO [10.238.135.171]) ([10.238.135.171]) by FMSMGA003.fm.intel.com with ESMTP; 06 Apr 2017 01:35:24 -0700 To: Jan Beulich , George Dunlap References: <1491135867-623-1-git-send-email-yu.c.zhang@linux.intel.com> <1491135867-623-6-git-send-email-yu.c.zhang@linux.intel.com> <58E519AB.7050004@linux.intel.com> <413a1f07-fa11-ab1c-af40-573ed0260e69@citrix.com> <58E51C2C.6050108@linux.intel.com> <546abc48-848a-e5c9-c9ec-e6757053ab5e@citrix.com> <58E526DD.4070309@linux.intel.com> <58E52922.1030500@linux.intel.com> <58E5311F.2080205@linux.intel.com> <58E531B9.2040600@linux.intel.com> <58E60ED0020000780014DB54@prv-mh.provo.novell.com> From: Yu Zhang Message-ID: <58E5FC0A.4010809@linux.intel.com> Date: Thu, 6 Apr 2017 16:27:54 +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: <58E60ED0020000780014DB54@prv-mh.provo.novell.com> Cc: Kevin Tian , George Dunlap , Andrew Cooper , "xen-devel@lists.xen.org" , Paul Durrant , Zhiyuan Lv , Jun Nakajima Subject: Re: [Xen-devel] [PATCH v10 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/6/2017 3:48 PM, Jan Beulich wrote: >>>> On 05.04.17 at 20:04, wrote: >> --- a/xen/common/memory.c >> +++ b/xen/common/memory.c >> @@ -288,6 +288,10 @@ int guest_remove_page(struct domain *d, unsigned long gmfn) >> put_gfn(d, gmfn); >> return 1; >> } >> + if ( unlikely(p2mt == p2m_ioreq_server) ) >> + p2m_change_type_one(d, gmfn, >> + p2m_ioreq_server, p2m_ram_rw); >> + >> #else >> mfn = gfn_to_mfn(d, _gfn(gmfn)); >> #endif > To be honest, this looks more like a quick hack than a proper solution > at the first glance. To me it would seem preferable if the count was Yeah, right. :) > adjusted at the point the P2M entry is being replaced (i.e. down the > call stack from guest_physmap_remove_page()). The closer to the > actual changing of the P2M entry, the less likely you miss any call > paths (as was already explained by George while suggesting to put > the accounting into the leaf most EPT/NPT functions). Well, I thought I have explained the reason why I have always been hesitating to do the count in atomic_write_ept_entry(). But seems I did not make it clear: 1> atomic_write_ept_entry() is used each time an p2m entry is written, but sweeping p2m_ioreq_server is only supposed to happen when an ioreq server unmaps. Checking the p2m here impacts the performance, and I do not think it is worthy - consider there may be very limited usage requirement for the p2m_ioreq_server; 2> atomic_write_ept_entry() does not have a p2m parameter, even some of its caller does not have either; 3> the lazy p2m type change is triggered at p2m level, by p2m_change_entry_type_global(). It can be used not only for intel ept. And supporting the count at the lowest level for non intel ept platform is more complex than changes in atomic_write_ept_entry(). 4> Fortunately, we have both resolve_misconfig() and do_recalc(), so I thought it would be enough to do the count in these two routines, together with the count in p2m_change_type_one(). But I had to admit I did not think of the extreme scenarios raised by George - I had always assumed an p2m_ioreq_server page will not be allocated to the balloon driver when it is in use. So here I have another proposal - we shall not allow a p2m_ioreq_server being ballooned out. I mean, if some bug in kernel really allocates a p2m_ioreq_server page to a balloon driver, or if the driver is a malicious one which does not tell the device model this gfn shall be no longer emulated, the hypervisor shall let the ballooning fail for this gfn. After all, if such situation happens, the guest or the device model already have bugs, and these last 2 patches are to make sure that even if there's bug in guest/device model, xen will help do the cleanup, instead of to tolerate guest bugs. If you think this is reasonable, I have drafted a patch, like this: #endif Changes made in p2m_pod_decrease_reservation() is to not let balloon driver to steal a p2m_ioreq_server page in PoD; Changes made in guest_remove_page() is to disallow a p2m_ioreq_server page being removed. Thanks Yu > Jan > > diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c index d5fea72..ff726ad 100644 --- a/xen/arch/x86/mm/p2m-pod.c +++ b/xen/arch/x86/mm/p2m-pod.c @@ -606,7 +606,8 @@ p2m_pod_decrease_reservation(struct domain *d, BUG_ON(p2m->pod.entry_count < 0); pod -= n; } - else if ( steal_for_cache && p2m_is_ram(t) ) + else if ( steal_for_cache && p2m_is_ram(t) && + (t != p2m_ioreq_server) ) { /* * If we need less than 1 << cur_order, we may end up stealing diff --git a/xen/common/memory.c b/xen/common/memory.c index 7dbddda..40d5545 100644 --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -288,6 +288,14 @@ int guest_remove_page(struct domain *d, unsigned long gmfn) put_gfn(d, gmfn); return 1; } + if ( unlikely(p2mt == p2m_ioreq_server) ) + { + put_gfn(d, gmfn); + gdprintk(XENLOG_INFO, "Domain %u page %lx cannot be removed.\n", + d->domain_id, gmfn); + return 0; + } + #else mfn = gfn_to_mfn(d, _gfn(gmfn));