| Message ID | 1519842483-8887-5-git-send-email-maran.wilson@oracle.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Feb 28, 2018 at 10:28:00AM -0800, Maran Wilson wrote: > We need to refactor PVH entry code so that support for other hypervisors > like Qemu/KVM can be added more easily. > > This patch moves the small block of code used for initializing Xen PVH > virtual machines into the Xen specific file. This initialization is not > going to be needed for Qemu/KVM guests. Moving it out of the common file > is going to allow us to compile kernels in the future without CONFIG_XEN > that are still capable of being booted as a Qemu/KVM guest via the PVH > entry point. > > Signed-off-by: Maran Wilson <maran.wilson@oracle.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Thank you!
On 28/02/18 19:28, Maran Wilson wrote: > We need to refactor PVH entry code so that support for other hypervisors > like Qemu/KVM can be added more easily. > > This patch moves the small block of code used for initializing Xen PVH > virtual machines into the Xen specific file. This initialization is not > going to be needed for Qemu/KVM guests. Moving it out of the common file > is going to allow us to compile kernels in the future without CONFIG_XEN > that are still capable of being booted as a Qemu/KVM guest via the PVH > entry point. > > Signed-off-by: Maran Wilson <maran.wilson@oracle.com> Reviewed-by: Juergen Gross <jgross@suse.com> Juergen
On 02/28/2018 01:28 PM, Maran Wilson wrote: > We need to refactor PVH entry code so that support for other hypervisors > like Qemu/KVM can be added more easily. > > This patch moves the small block of code used for initializing Xen PVH > virtual machines into the Xen specific file. This initialization is not > going to be needed for Qemu/KVM guests. Moving it out of the common file > is going to allow us to compile kernels in the future without CONFIG_XEN > that are still capable of being booted as a Qemu/KVM guest via the PVH > entry point. > > Signed-off-by: Maran Wilson <maran.wilson@oracle.com> > --- > arch/x86/pvh.c | 28 ++++++++++++++++++++-------- > arch/x86/xen/enlighten_pvh.c | 18 +++++++++++++++++- > 2 files changed, 37 insertions(+), 9 deletions(-) > > diff --git a/arch/x86/pvh.c b/arch/x86/pvh.c > index b56cb5e7d6ac..2d7a7f4958cb 100644 > --- a/arch/x86/pvh.c > +++ b/arch/x86/pvh.c > @@ -72,26 +72,38 @@ static void __init init_pvh_bootparams(void) > pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */ > } > > +/* > + * If we are trying to boot a Xen PVH guest, it is expected that the kernel > + * will have been configured to provide the required override for this routine. > + */ > +void __init __weak xen_pvh_init(void) > +{ > + xen_raw_printk("Error: Missing xen PVH initialization\n"); I think this should be printk (or, more precisely, this should not be xen_raw_printk()): we are here because we are *not* a Xen guest and so Xen-specific printk will not work. (and the same is true for the next patch where weak mem_map_via_hcall() is added). -boris > + BUG(); > +} >
On 3/1/2018 8:05 AM, Boris Ostrovsky wrote: > On 02/28/2018 01:28 PM, Maran Wilson wrote: >> We need to refactor PVH entry code so that support for other hypervisors >> like Qemu/KVM can be added more easily. >> >> This patch moves the small block of code used for initializing Xen PVH >> virtual machines into the Xen specific file. This initialization is not >> going to be needed for Qemu/KVM guests. Moving it out of the common file >> is going to allow us to compile kernels in the future without CONFIG_XEN >> that are still capable of being booted as a Qemu/KVM guest via the PVH >> entry point. >> >> Signed-off-by: Maran Wilson <maran.wilson@oracle.com> >> --- >> arch/x86/pvh.c | 28 ++++++++++++++++++++-------- >> arch/x86/xen/enlighten_pvh.c | 18 +++++++++++++++++- >> 2 files changed, 37 insertions(+), 9 deletions(-) >> >> diff --git a/arch/x86/pvh.c b/arch/x86/pvh.c >> index b56cb5e7d6ac..2d7a7f4958cb 100644 >> --- a/arch/x86/pvh.c >> +++ b/arch/x86/pvh.c >> @@ -72,26 +72,38 @@ static void __init init_pvh_bootparams(void) >> pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */ >> } >> >> +/* >> + * If we are trying to boot a Xen PVH guest, it is expected that the kernel >> + * will have been configured to provide the required override for this routine. >> + */ >> +void __init __weak xen_pvh_init(void) >> +{ >> + xen_raw_printk("Error: Missing xen PVH initialization\n"); > I think this should be printk (or, more precisely, this should not be > xen_raw_printk()): we are here because we are *not* a Xen guest and so > Xen-specific printk will not work. (and the same is true for the next > patch where weak mem_map_via_hcall() is added). Actually I left that xen_raw_printk() statement in on purpose. It's also possible that some future developer accidentally drops or hides the strong version of the routine even when CONFIG_XEN (and CONFIG_HVC_XEN) is enabled. In that situation, this error message might prove helpful in quickly identifying the problem when he or she attempts to boot a Xen guest. And in situations where CONFIG_XEN is disabled or someone is booting a non xen guest, the statement simply becomes a nop, so no harm is done. And also, I believe this code is far too early for normal printk() statements to work so switching to that won't buy us anything. Thanks, -Maran > -boris > > >> + BUG(); >> +} >>
diff --git a/arch/x86/pvh.c b/arch/x86/pvh.c index b56cb5e7d6ac..2d7a7f4958cb 100644 --- a/arch/x86/pvh.c +++ b/arch/x86/pvh.c @@ -72,26 +72,38 @@ static void __init init_pvh_bootparams(void) pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */ } +/* + * If we are trying to boot a Xen PVH guest, it is expected that the kernel + * will have been configured to provide the required override for this routine. + */ +void __init __weak xen_pvh_init(void) +{ + xen_raw_printk("Error: Missing xen PVH initialization\n"); + BUG(); +} + +/* + * When we add support for other hypervisors like Qemu/KVM, this routine can + * selectively invoke the appropriate initialization based on guest type. + */ +static void hypervisor_specific_init(void) +{ + xen_pvh_init(); +} + /* * This routine (and those that it might call) should not use * anything that lives in .bss since that segment will be cleared later. */ void __init xen_prepare_pvh(void) { - u32 msr; - u64 pfn; - if (pvh_start_info.magic != XEN_HVM_START_MAGIC_VALUE) { xen_raw_printk("Error: Unexpected magic value (0x%08x)\n", pvh_start_info.magic); BUG(); } - xen_pvh = 1; - - msr = cpuid_ebx(xen_cpuid_base() + 2); - pfn = __pa(hypercall_page); - wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32)); + hypervisor_specific_init(); init_pvh_bootparams(); } diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c index 4b4e9cc78b8a..833c441a20df 100644 --- a/arch/x86/xen/enlighten_pvh.c +++ b/arch/x86/xen/enlighten_pvh.c @@ -1,4 +1,9 @@ -#include <linux/types.h> +#include <linux/acpi.h> + +#include <asm/io_apic.h> + +#include <asm/xen/interface.h> +#include <asm/xen/hypercall.h> /* * PVH variables. @@ -9,3 +14,14 @@ */ bool xen_pvh __attribute__((section(".data"))) = 0; +void __init xen_pvh_init(void) +{ + u32 msr; + u64 pfn; + + xen_pvh = 1; + + msr = cpuid_ebx(xen_cpuid_base() + 2); + pfn = __pa(hypercall_page); + wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32)); +}
We need to refactor PVH entry code so that support for other hypervisors like Qemu/KVM can be added more easily. This patch moves the small block of code used for initializing Xen PVH virtual machines into the Xen specific file. This initialization is not going to be needed for Qemu/KVM guests. Moving it out of the common file is going to allow us to compile kernels in the future without CONFIG_XEN that are still capable of being booted as a Qemu/KVM guest via the PVH entry point. Signed-off-by: Maran Wilson <maran.wilson@oracle.com> --- arch/x86/pvh.c | 28 ++++++++++++++++++++-------- arch/x86/xen/enlighten_pvh.c | 18 +++++++++++++++++- 2 files changed, 37 insertions(+), 9 deletions(-)