From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758378AbcATVm0 (ORCPT ); Wed, 20 Jan 2016 16:42:26 -0500 Received: from terminus.zytor.com ([198.137.202.10]:40995 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752790AbcATVmW (ORCPT ); Wed, 20 Jan 2016 16:42:22 -0500 Subject: Re: [RFC v1 4/8] x86/init: add linker table support To: "Luis R. Rodriguez" , Konrad Rzeszutek Wilk , Boris Ostrovsky , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Stefano Stabellini References: <1450217797-19295-1-git-send-email-mcgrof@do-not-panic.com> <1450217797-19295-5-git-send-email-mcgrof@do-not-panic.com> <20160120210014.GF4769@char.us.oracle.com> Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Rusty Russell , Andy Lutomirski , mcb30@ipxe.org, Juergen Gross , Jan Beulich , joro@8bytes.org, Andrey Ryabinin , andreyknvl@google.com, long.wanglong@huawei.com, qiuxishi@huawei.com, aryabinin@virtuozzo.com, Mauro Carvalho Chehab , Valentin Rothberg , Peter Senna Tschudin , X86 ML , "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" From: "H. Peter Anvin" Message-ID: <569FFEEE.5090600@zytor.com> Date: Wed, 20 Jan 2016 13:41:02 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/20/16 13:33, Luis R. Rodriguez wrote: > > That's correct for PV and PVH, likewise when qemu is required for HVM > qemu could set it. I have the qemu change done but that should only > cover HVM. A common place to set this as well could be the hypervisor, > but currently the hypervisor doesn't set any boot_params, instead a > generic struct is passed and the kernel code (for any OS) is expected > to interpret this and then set the required values for the OS in the > init path. Long term though if we wanted to merge init further one way > could be to have the hypervisor just set the zero page cleanly for the > different modes. If we needed more data other than the > hardware_subarch we also have the hardware_subarch_data, that's a u64 > , and how that is used would be up to the subarch. In Xen's case it > could do what it wants with it. That would still mean perhaps defining > as part of a Xen boot protocol a place where xen specific code can > count on finding more Xen data passed by the hypervisor, the > xen_start_info. That is, if we wanted to merge init paths this is > something to consider. > > One thing I considered on the question of who should set the zero page > for Xen with the prospect of merging inits, or at least this subarch > for both short term and long term are the obvious implications in > terms of hypervisor / kernel / qemu combination requirements if the > subarch is needed. Having it set in the kernel is an obvious immediate > choice for PV / PVH but it means we can't merge init paths completely > (down to asm inits), we'd still be able to merge some C init paths > though, the first entry would still be different. Having the zero page > set on the hypervisor would go long ways but it would mean a > hypervisor change required. > > These prospects are worth discussing, specially in light of Boris's > hvmlite work. > The above doesn't make sense to me. hardware_subarch is really used when the boot sequence is somehow nonstandard. HVM probably doesn't need that. -hpa