The type is valid even in HVM=y plus PV32=y builds. Hence either the
respective sh_type_to_size[] entry needs to be non-zero [1], or an
override is needed. With the table sitting in a HVM-only file, it was
requested that the table be left alone. Leverage the need for an
override to make the size actually dependent on a runtime property,
not just a build time one.

Fixes: 1894049fa283 ("x86/shadow: L2H shadow type is PV32-only")
Signed-off-by: Jan Beulich <jbeulich@suse.com>

[1] https://lists.xen.org/archives/html/xen-devel/2023-01/msg01586.html
---
This is an alternative to "x86/shadow: sh_type_to_size[] needs L2H entry
when HVM+PV32". I continue to think that's the better solution, but the
main goal is to get the regression sorted, so I'm (hesitantly) willing
to go this less optimal route. While there's a benefit to making the
size runtime instead of just build time dynamic (in principle we could
go further and make it depend on domain type), the downsides are extra
code and a scalability concern: Things will get unwieldy when a few more
types want special casing for (more or less) similar reasons.

Leaving the table alone is questionable in the first place: It's still
used for both HVM and PV domains. With the change here all we avoid is
the use of that one table entry. Its HVM-only-ness is a build property,
not (like in many other cases) a runtime one.

--- a/xen/arch/x86/mm/shadow/private.h
+++ b/xen/arch/x86/mm/shadow/private.h
@@ -29,6 +29,7 @@
 #include <xen/domain_page.h>
 #include <asm/x86_emulate.h>
 #include <asm/hvm/support.h>
+#include <asm/pv/domain.h>
 #include <asm/atomic.h>
 
 #include "../mm-locks.h"
@@ -366,6 +367,10 @@ extern const u8 sh_type_to_size[SH_type_
 static inline unsigned int
 shadow_size(unsigned int shadow_type)
 {
+#ifdef SH_type_l2h_64_shadow
+    if ( shadow_type == SH_type_l2h_64_shadow )
+        return opt_pv32;
+#endif
 #ifdef CONFIG_HVM
     ASSERT(shadow_type < ARRAY_SIZE(sh_type_to_size));
     return sh_type_to_size[shadow_type];