From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S933500AbcAYQJN (ORCPT <rfc822;w@1wt.eu>);
	Mon, 25 Jan 2016 11:09:13 -0500
Received: from aserp1040.oracle.com ([141.146.126.69]:41292 "EHLO
	aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S933198AbcAYQJE (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Jan 2016 11:09:04 -0500
Subject: Re: [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest
To: "Luis R. Rodriguez" <mcgrof@suse.com>
References: <1453498558-6028-1-git-send-email-boris.ostrovsky@oracle.com>
 <1453498558-6028-5-git-send-email-boris.ostrovsky@oracle.com>
 <20160122233218.GA20964@wotan.suse.de>
Cc: david.vrabel@citrix.com, konrad.wilk@oracle.com,
        xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
        roger.pau@citrix.com, hpa@zytor.com, Juergen Gross <jgross@suse.com>,
        Rusty Russell <rusty@rustcorp.com.au>,
        Andy Lutomirski <luto@amacapital.net>, Borislav Petkov <bp@suse.de>,
        Jeremy Fitzhardinge <jeremy@goop.org>
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <56A6488F.5030909@oracle.com>
Date: Mon, 25 Jan 2016 11:08:47 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <20160122233218.GA20964@wotan.suse.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 01/22/2016 06:32 PM, Luis R. Rodriguez wrote:
> On Fri, Jan 22, 2016 at 04:35:50PM -0500, Boris Ostrovsky wrote:
>
>> +/*
>> + * 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_hvmlite(void)
>> +{
>> +	u32 eax, ecx, edx, msr;
>> +	u64 pfn;
>> +
>> +	cpuid(xen_cpuid_base() + 2, &eax, &msr, &ecx, &edx);
>> +	pfn = __pa(hypercall_page);
>> +	wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
>> +
>> +	pv_info.name = "Xen HVMlite";
>> +	xen_domain_type = XEN_HVM_DOMAIN;
>> +	xen_hvmlite = 1;
>> +
>> +	x86_init.oem.arch_setup = xen_init_kernel;
>> +	x86_init.oem.banner = xen_banner;
>> +
>> +	hvmlite_bootparams();
>> +}
>> +#endif
> If the boot_params.hdr.hardware_subarch_data pointed to a custom
> struct then the first C entry point for Xen could shuffle this and
> set this too, by still using less asm entry helpers. We'd still
> need this run but with the linker table I think we could have
> a stub small stub for hvm run, it would not be a call from asm.

Perhaps, but someone would still have to set hardware_subarch. And it's 
hvmlite_bootparams() that does it.

And that's not sufficient, I think. There are still some things that 
trampoline code sets up (e.g. page tables for 64-bit).

-boris