Re: [Xen-devel] [V3 PATCH 9/9] pvh dom0: add opt_dom0pvh to setup.c

[Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>]

On Mon, 2 Dec 2013 16:09:50 +0100
Roger Pau Monnà <roger.pau@xxxxxxxxxx> wrote:

> On 27/11/13 03:27, Mukesh Rathor wrote:
> > Add opt_dom0pvh. Note, pvh dom0 is disabled until the fixme in
> > domain_build.c is resolved. The fixme is added by patch title:
> > "PVH dom0: construct_dom0 changes"
> > 
> > Signed-off-by: Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
> > ---
> >  xen/arch/x86/setup.c |   19 ++++++++++++++++---
> >  1 files changed, 16 insertions(+), 3 deletions(-)
> > 
> > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> > index e33c34b..de30ef6 100644
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -61,6 +61,10 @@ integer_param("maxcpus", max_cpus);
> >  static bool_t __initdata disable_smep;
> >  invbool_param("smep", disable_smep);
> >  
> > +/* Boot dom0 in pvh mode */
> > +bool_t __initdata opt_dom0pvh;
> > +boolean_param("dom0pvh", opt_dom0pvh);
> > +
> >  /* **** Linux config option: propagated to domain0. */
> >  /* "acpi=off":    Sisables both ACPI table parsing and
> > interpreter. */ /* "acpi=force":  Override the disable
> > blacklist.                   */ @@ -545,7 +549,7 @@ void __init
> > __start_xen(unsigned long mbi_p) {
> >      char *memmap_type = NULL;
> >      char *cmdline, *kextra, *loader;
> > -    unsigned int initrdidx;
> > +    unsigned int initrdidx, domcr_flags = 0;
> >      multiboot_info_t *mbi = __va(mbi_p);
> >      module_t *mod = (module_t *)__va(mbi->mods_addr);
> >      unsigned long nr_pages, raw_max_page, modules_headroom,
> > *module_map; @@ -1332,8 +1336,17 @@ void __init
> > __start_xen(unsigned long mbi_p) if ( !tboot_protect_mem_regions() )
> >          panic("Could not protect TXT memory regions\n");
> >  
> > -    /* Create initial domain 0. */
> > -    dom0 = domain_create(0, DOMCRF_s3_integrity, 0);
> > +    /*
> > +     * Following removed when "pvh fixme" in domain_build.c is
> > resolved.
> > +     * The fixme is added by patch "PVH dom0: construct_dom0
> > changes".
> > +     */
> > +    if ( opt_dom0pvh )
> > +        panic("You do not have the correct xen version for dom0
> > PVH\n");
> 
> I've removed this from my local copy and passed dom0pvh=1 on the 
> command line in order to try to boot with PVH Dom0. As Dom0 kernel
> I'm using the tmp2 branch from your repo at
> git://oss.oracle.com/git/mrathor /linux.git (which seems to work fine
> as a DomU), but as Dom0 the kernel panics with the following message:

Well, the guest failed VCPUOP_initialise for secondary vcpu. Do you
have all the xen patches, specifically the one's you had submitted for
it? I'm on latest xen with dom0 patches on 
e439e0b289e3590f84836e4f9bbdfa560c7af6ef. If yes, then wonder why
xen failed VCPUOP_initialise! May be you can figure where it's failing.


BTW, I also noticed:

(XEN)memory.c:132:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 of 1)

and 

Released 18446744073708661104 pages of unused memory <=====================
[    0.000000] Set 131701 page(s) to 1-1 mapping
[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: CPU: 0 PID: 0 at arch/x86/xen/setup.c:134 
xen_do_chunk+0x1a0/0x247()
[    0.000000] Failed to populate pfn 1770b9 err=0  <=====================


Wonder what the e820 to dom0 looks like.

Thanks for trying it out.

Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel