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

[Roger Pau Monnà <roger.pau@xxxxxxxxxx>]

On 02/12/13 20:30, Mukesh Rathor wrote:
> 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.

Thanks for the input, I haven't been able to do much debugging, but
AFAICT the problem comes from alloc_vcpu_guest_context returning NULL,
because alloc_domheap_page(NULL, 0) inside of that function also
returned NULL (not able to allocate a page).

I'm currently using your tree for both Linux (branch tmp2) and Xen
(branch dom0pvh-v3), no added or removed patches (only the line
mentioned above in order to boot Dom0 in PVH mode).

Can you confirm you are able to boot a PVH Dom0 from you Xen and Linux
trees?


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