From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7972FC433B4 for ; Sat, 17 Apr 2021 19:25:25 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 223AC61241 for ; Sat, 17 Apr 2021 19:25:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 223AC61241 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xen.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.112247.214355 (Exim 4.92) (envelope-from ) id 1lXqYs-0001fG-TH; Sat, 17 Apr 2021 19:24:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 112247.214355; Sat, 17 Apr 2021 19:24:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lXqYs-0001f9-Q9; Sat, 17 Apr 2021 19:24:58 +0000 Received: by outflank-mailman (input) for mailman id 112247; Sat, 17 Apr 2021 19:24:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lXqYq-0001f4-ND for xen-devel@lists.xenproject.org; Sat, 17 Apr 2021 19:24:56 +0000 Received: from deinos.phlegethon.org (unknown [2001:41d0:8:b1d7::1]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a744a3c5-97c7-4303-8738-523ba71ecffa; Sat, 17 Apr 2021 19:24:55 +0000 (UTC) Received: from tjd by deinos.phlegethon.org with local (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1lXqYi-000LTl-T2; Sat, 17 Apr 2021 19:24:48 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a744a3c5-97c7-4303-8738-523ba71ecffa Date: Sat, 17 Apr 2021 20:24:48 +0100 From: Tim Deegan To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Wei Liu , Roger Pau =?iso-8859-1?Q?Monn=E9?= , George Dunlap , Kevin Tian , Jun Nakajima Subject: Re: [PATCH v4] VMX: use a single, global APIC access page Message-ID: References: <4731a3a3-906a-98ac-11ba-6a0723903391@suse.com> <1c489e77-6e65-6121-6c28-3c4bd377223c@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <1c489e77-6e65-6121-6c28-3c4bd377223c@suse.com> X-SA-Known-Good: Yes X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tim@xen.org X-SA-Exim-Scanned: No (on deinos.phlegethon.org); SAEximRunCond expanded to false Hi, Apologies for not sending comments before, and thanks for the ping. At 12:40 +0200 on 12 Apr (1618231248), Jan Beulich wrote: > The address of this page is used by the CPU only to recognize when to > access the virtual APIC page instead. No accesses would ever go to this > page. It only needs to be present in the (CPU) page tables so that > address translation will produce its address as result for respective > accesses. > > By making this page global, we also eliminate the need to refcount it, > or to assign it to any domain in the first place. What is the aim here? To save 4k per domain? It seems to come out about even for adding and removing code. > --- a/xen/arch/x86/mm/shadow/set.c > +++ b/xen/arch/x86/mm/shadow/set.c > @@ -94,6 +94,22 @@ shadow_get_page_from_l1e(shadow_l1e_t sl > ASSERT(!sh_l1e_is_magic(sl1e)); > ASSERT(shadow_mode_refcounts(d)); > > + /* > + * VMX'es APIC access MFN is just a surrogate page. It doesn't actually > + * get accessed, and hence there's no need to refcount it (and refcounting > + * would fail, due to the page having no owner). > + */ > + if ( mfn_valid(mfn = shadow_l1e_get_mfn(sl1e)) ) Would it be better to check specifically for mfn == apic_access_mfn (and apic_access_mfn != 0, I guess)? If we want this behaviour for for all un-owned PGC_extra MFNs it would be good to explain that in the comments. Cheers, Tim.