On 2/1/2023 2:20 AM, Michael Kelley (LINUX) wrote:
+struct memory_map_entry { + u64 starting_gpn; + u64 numpages; + u16 type; + u16 flags; + u32 reserved; +};Am I correct that this structure is defined by Hyper-V? If so, it seems like it should go in hyperv-tlfs.h, along with the definition of EN_SEV_SNP_PROCESSOR_INFO_ADDR (which is also defined by Hyper-V?)
Yes, it's Hyper-V data structure and will move to hyperv-tlfs.h.
+ if (e820_end < ram_end) { + pr_info("Hyper-V: add e820 entry [mem %#018Lx-%#018Lx]\n", e820_end, ram_end - 1); + e820__range_add(e820_end, ram_end - e820_end, + E820_TYPE_RAM); + for (page = e820_end; page < ram_end; page += PAGE_SIZE) + pvalidate((unsigned long)__va(page), RMP_PG_SIZE_4K, true); + } + } + } +For SNP vTOM mode, most of the supporting code is placed in arch/x86/hyperv/ivm.c, which is built only if CONFIG_HYPERV is defined. arch/x86/kernel/cpu/mshyperv.c is built for*any* flavor of guest (i.e., CONFIG_HYPERVISOR_GUEST). I'm thinking all this code should go as a supporting function in ivm.c, to avoid overloading mshyperv.c. Take a look at how hv_vtom_init() is handled in my patch set. Breaking it out as a separate supporting function might also help reduce the deep indentation problem a bit. 😄
Good idea. Will update in the next version. Thanks for your suggestion.
