search for: init_mem_map

...e per boot) */ - void (*init_platform)(void); + /* init time callbacks */ + struct x86_hyper_init init; - /* X2APIC detection (run once per boot) */ - bool (*x2apic_available)(void); - - /* pin current vcpu to specified physical cpu (run rarely) */ - void (*pin_vcpu)(int); - - /* called during init_mem_mapping() to setup early mappings. */ - void (*init_mem_mapping)(void); + /* runtime callbacks */ + struct x86_hyper_runtime runtime; }; extern const struct hypervisor_x86 *x86_hyper; @@ -58,17 +53,7 @@ extern const struct hypervisor_x86 x86_h extern const struct hypervisor_x86 x86_hyper_kvm;...

Booting a Xen PVH guest requires a special boot entry as it is mandatory to setup some Xen-specific interfaces rather early. When grub or OVMF are used as boot loaders, however, those will fill the boot parameters in zeropage and there is no longer a need to do something PVH specific in the early boot path. This patch series adds support for that scenario by identifying PVH environment and doing

Booting a Xen PVH guest requires a special boot entry as it is mandatory to setup some Xen-specific interfaces rather early. When grub or OVMF are used as boot loaders, however, those will fill the boot parameters in zeropage and there is no longer a need to do something PVH specific in the early boot path. This patch series adds support for that scenario by identifying PVH environment and doing

...rvisor_x86 x86_hyper_xen_hvm = { > .name = "Xen HVM", > .detect = xen_platform_hvm, > + .type = X86_HYPER_XEN_HVM, > .init.init_platform = xen_hvm_guest_init, > .init.x2apic_available = xen_x2apic_para_available, > .init.init_mem_mapping = xen_hvm_init_mem_mapping, > .runtime.pin_vcpu = xen_pin_vcpu, > }; > -EXPORT_SYMBOL(x86_hyper_xen_hvm); > diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c > index 69d1a7054ddb..168efb2534c0 100644 > --- a/arch/x86/xen/enlighten_pv.c > +++ b/...

...rvisor_x86 x86_hyper_xen_hvm = { > .name = "Xen HVM", > .detect = xen_platform_hvm, > + .type = X86_HYPER_XEN_HVM, > .init.init_platform = xen_hvm_guest_init, > .init.x2apic_available = xen_x2apic_para_available, > .init.init_mem_mapping = xen_hvm_init_mem_mapping, > .runtime.pin_vcpu = xen_pin_vcpu, > }; > -EXPORT_SYMBOL(x86_hyper_xen_hvm); > diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c > index 69d1a7054ddb..168efb2534c0 100644 > --- a/arch/x86/xen/enlighten_pv.c > +++ b/...

...+const __initconst struct hypervisor_x86 x86_hyper_xen_hvm = { .name = "Xen HVM", .detect = xen_platform_hvm, + .type = X86_HYPER_XEN_HVM, .init.init_platform = xen_hvm_guest_init, .init.x2apic_available = xen_x2apic_para_available, .init.init_mem_mapping = xen_hvm_init_mem_mapping, .runtime.pin_vcpu = xen_pin_vcpu, }; -EXPORT_SYMBOL(x86_hyper_xen_hvm); --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -1459,9 +1459,9 @@ static uint32_t __init xen_platform_pv(v return 0; } -const struct hypervisor_x86 x86_hyper...

...+const __initconst struct hypervisor_x86 x86_hyper_xen_hvm = { .name = "Xen HVM", .detect = xen_platform_hvm, + .type = X86_HYPER_XEN_HVM, .init.init_platform = xen_hvm_guest_init, .init.x2apic_available = xen_x2apic_para_available, .init.init_mem_mapping = xen_hvm_init_mem_mapping, .runtime.pin_vcpu = xen_pin_vcpu, }; -EXPORT_SYMBOL(x86_hyper_xen_hvm); diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c index 69d1a7054ddb..168efb2534c0 100644 --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -146...

Hi Linus, This is a huge set of several partly interrelated (and concurrently developed) changes, which is why the branch history is messier than one would like. The *really* big items are two humonguous patchsets mostly developed by Yinghai Lu at my request, which completely revamps the way we create initial page tables. In particular, rather than estimating how much memory we will need for

Hi Linus, This is a huge set of several partly interrelated (and concurrently developed) changes, which is why the branch history is messier than one would like. The *really* big items are two humonguous patchsets mostly developed by Yinghai Lu at my request, which completely revamps the way we create initial page tables. In particular, rather than estimating how much memory we will need for

Hi Linus, This is a huge set of several partly interrelated (and concurrently developed) changes, which is why the branch history is messier than one would like. The *really* big items are two humonguous patchsets mostly developed by Yinghai Lu at my request, which completely revamps the way we create initial page tables. In particular, rather than estimating how much memory we will need for