[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC 04/12] xen/x86: split Dom0 build into PV and PVHv2
On 01/08/16 12:36, Roger Pau Monne wrote: > On Fri, Jul 29, 2016 at 06:57:08PM +0100, Andrew Cooper wrote: >> On 29/07/16 17:28, Roger Pau Monne wrote: >>> Split the Dom0 builder into two different functions, one for PV (and classic >>> PVH), and another one for PVHv2. Introduce a new command line parameter, >>> dom0hvm in order to request the creation of a PVHv2 Dom0. >>> >>> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> >>> --- >>> Cc: Jan Beulich <jbeulich@xxxxxxxx> >>> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> >>> --- >>> xen/arch/x86/domain_build.c | 27 ++++++++++++++++++++++++++- >>> xen/arch/x86/setup.c | 9 +++++++++ >> A patch to docs/misc/xen-command-line.markdown please. > OK, I wasn't really sure if we want to introduce a new command line option, > or just use dom0pvh. In any case I will add it, we can always alias dom0pvh > to dom0pvh (or the other way around) when classic PVH support is > removed. I am not terribly fussed, so long as the docs match the hypervisor behaviour :) > >>> 2 files changed, 35 insertions(+), 1 deletion(-) >>> >>> diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c >>> index 09d79be..c0ef40f 100644 >>> --- a/xen/arch/x86/domain_build.c >>> +++ b/xen/arch/x86/domain_build.c >>> @@ -952,7 +952,7 @@ static int __init setup_permissions(struct domain *d) >>> return rc; >>> } >>> >>> -int __init construct_dom0( >>> +static int __init construct_dom0_pv( >>> struct domain *d, >>> const module_t *image, unsigned long image_headroom, >>> module_t *initrd, >>> @@ -1647,6 +1647,31 @@ out: >>> return rc; >>> } >>> >>> +static int __init construct_dom0_hvm(struct domain *d, const module_t >>> *image, >>> + unsigned long image_headroom, >>> + module_t *initrd, >>> + void *(*bootstrap_map)(const module_t >>> *), >>> + char *cmdline) >>> +{ >>> + >>> + printk("** Building a PVH Dom0 **\n"); >> Some naming curiosities here, especially given the parameter name. > Hm, AFAIK we agreed on keeping the 'PVH' naming, but since internally Xen > has no concept of 'PVH' I think the constructor is better named as HVM (and > in fact if PVH wasn't there before I would just consider this a HVM Dom0). > > If people prefer HVM I can certainly change it, but I think it's going to > get messy. Fair enough. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |