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 S1755933AbcAWApd (ORCPT <rfc822;w@1wt.eu>);
	Fri, 22 Jan 2016 19:45:33 -0500
Received: from mail-yk0-f195.google.com ([209.85.160.195]:35588 "EHLO
	mail-yk0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1755406AbcAWAp2 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 22 Jan 2016 19:45:28 -0500
MIME-Version: 1.0
In-Reply-To: <56A2C99A.2050701@citrix.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> <56A2C99A.2050701@citrix.com>
From: "Luis R. Rodriguez" <mcgrof@suse.com>
Date: Fri, 22 Jan 2016 16:45:07 -0800
X-Google-Sender-Auth: p6zjRaptS2boWAE0f8bUYmkTxPU
Message-ID: <CAB=NE6Wt0zZsMWAMZ3iJkW8EuC6zKzO2hM6oTf4s5f=dBZPkKg@mail.gmail.com>
Subject: Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        Juergen Gross <jgross@suse.com>, Jeremy Fitzhardinge <jeremy@goop.org>,
        Rusty Russell <rusty@rustcorp.com.au>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Andy Lutomirski <luto@amacapital.net>,
        David Vrabel <david.vrabel@citrix.com>,
        "H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
        Borislav Petkov <bp@suse.de>,
        =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Jan 22, 2016 at 4:30 PM, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
> I would have though the correct way to do direct Linux support would be
> to have a very small init stub which constructs an appropriate zero
> page, and lets the native entry point get on with things.

As hpa noted recently in another thread [0] that is precisely what
hardware_subarch and hardware_subarch_data was meant to be used for,
and its what I'm alluding to.

The only thing though is that as far as we're concerned on x86 we had
expected use of hardware_subarch and hardware_subarch_data only for
PV, and not for HVM. This seems to be HVM related, but I think this is
just a rebranding of PVH to HVMLite, right, so I think the use case of
hardware_subarch and hardware_subarch_data are still welcomed as
expected in the original design.

[0] http://lkml.kernel.org/r/56A130B5.8060701@zytor.com

 Luis