From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Luis R. Rodriguez" <mcgrof@suse.com>
Subject: Re: [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite
	guest
Date: Mon, 25 Jan 2016 22:12:03 +0100
Message-ID: <20160125211203.GF20964__5320.73631552539$1453756409$gmane$org@wotan.suse.de>
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>
	<56A6488F.5030909@oracle.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lurodriguez@suse.de>) id 1aNoQi-00014K-0x
	for xen-devel@lists.xenproject.org; Mon, 25 Jan 2016 21:12:08 +0000
Content-Disposition: inline
In-Reply-To: <56A6488F.5030909@oracle.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>, Jeremy Fitzhardinge <jeremy@goop.org>, Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org, Andy Lutomirski <luto@amacapital.net>, david.vrabel@citrix.com, hpa@zytor.com, xen-devel@lists.xenproject.org, Borislav Petkov <bp@suse.de>, roger.pau@citrix.com
List-Id: xen-devel@lists.xenproject.org

On Mon, Jan 25, 2016 at 11:08:47AM -0500, Boris Ostrovsky wrote:
> 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.

No, Xen would do it as well, essentially all of hvmlite_bootparams() could be
done in Xen.

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

Sure, but only what is required, that should be rather smaller.

  Luis