[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH v2 06/15] x86/p2m: guard altp2m code with CONFIG_ALTP2M option


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Sergiy Kibrik <sergiy_kibrik@xxxxxxxx>
  • Date: Thu, 23 May 2024 13:44:48 +0300
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=kpx9T7B2+zG/EYxXkneyTPeQ0oLcp7fIPBnmPbxjrsc=; b=GnwhHQDfi8EgF1D+B/DFR4VbUlbjEk9TI8R6xDsv+0EhvZnTnj7IJB9s4cn6Na/+OUQLvVlkyiI8p7hkW0w3c0Lyqezk1iD8NyuO28LK5Yjzp/S17Hp95Zo3B+umr34Wo+e6La6aXON9WL2Mjjevu/Lz7GUBMiqwUffdDY5rLtv2hJQafibmT1XIoUfzBnBgqO+DEV97KWXxqkykVxDPnbVkyJLluc11XqDxbeFVPwJk8x3q2H2mGxaaFgyEF5AJho4XVnzhCT74D2jUeivGHC07NVCS6OD783R3079JjtbKOEJ9rGOc/rWIBvk0FSv4h7KHMlrdJzAIssxK4YZFtw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CiZUOwIoGOYrn6LrOXYgSf14BnG3YEdMFGVqWZmJdPDxQNYsf+H4t1LGq45cwcn73zxh+A7sAcCiqbEmj2NIs5iB+P6nvVsuucn6SRVeE6MKkb0x9TIRPCxPdhJFrKb6vXNnKzxO9TBT1SL7EypqtOonRI19Ys0n05a7FObPcIiJcp/BnFZqBCAVb69ys4gs/Co8vQKQ5J09Kbrmny4IQ3SvxmdUyUq9AFjngLgbeZe/ZgAQVtk17qxM1JKZdOV6fStVdRbhdfljjW46qOM78gD9rCIqr9X65lhu1A5THlDgepZirY+Wn4obg4iMKbr4QAqO1TaPZVFd2mZVksRW5w==
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Xenia Ragiadakou <xenia.ragiadakou@xxxxxxx>, Tamas K Lengyel <tamas@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 23 May 2024 10:45:29 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

16.05.24 14:01, Jan Beulich:
On 15.05.2024 11:10, Sergiy Kibrik wrote:
@@ -38,7 +38,10 @@ static inline bool altp2m_active(const struct domain *d)
  }
/* Only declaration is needed. DCE will optimise it out when linking. */
+void altp2m_vcpu_initialise(struct vcpu *v);
+void altp2m_vcpu_destroy(struct vcpu *v);
  uint16_t altp2m_vcpu_idx(const struct vcpu *v);
+int altp2m_vcpu_enable_ve(struct vcpu *v, gfn_t gfn);
  void altp2m_vcpu_disable_ve(struct vcpu *v);

These additions look unrelated, as long as the description says nothing in
this regard.

agree, I'll update description on why these declarations are added


--- a/xen/arch/x86/include/asm/hvm/hvm.h
+++ b/xen/arch/x86/include/asm/hvm/hvm.h
@@ -670,7 +670,7 @@ static inline bool hvm_hap_supported(void)
  /* returns true if hardware supports alternate p2m's */
  static inline bool hvm_altp2m_supported(void)
  {
-    return hvm_funcs.caps.altp2m;
+    return IS_ENABLED(CONFIG_ALTP2M) && hvm_funcs.caps.altp2m;

Which in turn raises the question whether the altp2m struct field shouldn't
become conditional upon CONFIG_ALTP2M too (or rather: instead, as the change
here then would need to be done differently). Yet maybe that would entail
further changes elsewhere, so may well better be left for later.


but hvm_funcs.caps.altp2m is only a capability bit -- is it worth to become conditional?

--- a/xen/arch/x86/mm/Makefile
+++ b/xen/arch/x86/mm/Makefile
@@ -1,7 +1,7 @@
  obj-y += shadow/
  obj-$(CONFIG_HVM) += hap/
-obj-$(CONFIG_HVM) += altp2m.o
+obj-$(CONFIG_ALTP2M) += altp2m.o

This change I think wants to move to patch 5.


If this moves to patch 5 then HVM=y && ALTP2M=n configuration combination will break the build in between patch 5 and 6, so I've decided to put it together with fixes of these build failures in patch 6.
Maybe I can merge patch 5 & 6 together then ?

  -Sergiy



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.