On 15.02.2023 14:25, Andrew Cooper wrote: > On 15/02/2023 1:12 pm, Juergen Gross wrote: >> On 15.02.23 13:42, Jan Beulich wrote: >>> On 15.02.2023 13:05, Juergen Gross wrote: >>>> On 15.02.23 12:33, Jan Beulich wrote: >>>>> -#endif >>>>> #ifdef CONFIG_XEN_PV >>>>> ELFNOTE(Xen, XEN_ELFNOTE_ENTRY, _ASM_PTR startup_xen) >>>>> + ELFNOTE(Xen, XEN_ELFNOTE_FEATURES, .ascii >>>>> "!writable_page_tables") >>>>> + ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE, .asciz "yes") >>>>> + ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID, >>>>> + .quad _PAGE_PRESENT; .quad _PAGE_PRESENT) >>>>> +# define FEATURES_PV (1 << XENFEAT_writable_page_tables) >>>>> +#else >>>>> +# define FEATURES_PV 0 >>>>> +#endif >>>>> +#ifdef CONFIG_XEN_PVH >>>>> +# define FEATURES_PVH (1 << XENFEAT_linux_rsdp_unrestricted) >>>>> +#else >>>>> +# define FEATURES_PVH 0 >>>>> +#endif >>>>> +#ifdef CONFIG_XEN_DOM0 >>>>> +# define FEATURES_DOM0 (1 << XENFEAT_dom0) >>>>> +#else >>>>> +# define FEATURES_DOM0 0 >>>>> #endif >>>>> ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, _ASM_PTR >>>>> hypercall_page) >>>>> - ELFNOTE(Xen, XEN_ELFNOTE_FEATURES, >>>>> - .ascii "!writable_page_tables|pae_pgdir_above_4gb") >>>>> ELFNOTE(Xen, XEN_ELFNOTE_SUPPORTED_FEATURES, >>>>> - .long (1 << XENFEAT_writable_page_tables) | \ >>>>> - (1 << XENFEAT_dom0) | \ >>>>> - (1 << XENFEAT_linux_rsdp_unrestricted)) >>>>> - ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE, .asciz "yes") >>>>> + .long FEATURES_PV | FEATURES_PVH | FEATURES_DOM0) >>>>> ELFNOTE(Xen, XEN_ELFNOTE_LOADER, .asciz "generic") >>>>> - ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID, >>>>> - .quad _PAGE_PRESENT; .quad _PAGE_PRESENT) >>>>> ELFNOTE(Xen, XEN_ELFNOTE_SUSPEND_CANCEL, .long 1) >>>>> ELFNOTE(Xen, XEN_ELFNOTE_MOD_START_PFN, .long 1) >>>>> ELFNOTE(Xen, XEN_ELFNOTE_HV_START_LOW, _ASM_PTR >>>>> __HYPERVISOR_VIRT_START) >>>> >>>> Are XEN_ELFNOTE_MOD_START_PFN and XEN_ELFNOTE_HV_START_LOW really >>>> relevant >>>> for the non-PV case? I don't think so (in theory >>>> XEN_ELFNOTE_MOD_START_PFN >>>> could be used, but the main reason for its introduction was PV >>>> guests IIRC). >>> >>> I wasn't sufficiently certain for MOD_START_PFN, so I'd prefer to >>> leave it >>> untouched for now. HV_START_LOW might be 32-bit PV only really; I'll >>> check >>> and then maybe drop (or move). >> >> Fine with me. > > HV_START_LOW is PV32 only. It's the negotiation for the virtual address > split with Xen, and was never implemented properly for PV64.
Not the least because there it would be the upper bound that could be moved down, not the lower one that's movable upwards for PV32. I suppose we'll get there once we have 5-level paging support and can shrink the hole needed for 4-level PV guests. > MOD_START_PFN is PV only. It's not applicable for HVM/PVH. It isn't right now, yes. I continue to be uncertain and would prefer to leave it as is. Jan
