From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752506AbcAZVv7 (ORCPT ); Tue, 26 Jan 2016 16:51:59 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:40112 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751494AbcAZVv6 (ORCPT ); Tue, 26 Jan 2016 16:51:58 -0500 Subject: Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest To: "Luis R. Rodriguez" 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> <56A39300.8050802@citrix.com> <20160125221920.GG20964@wotan.suse.de> <56A6A7C6.8060906@oracle.com> <20160126203023.GI20964@wotan.suse.de> Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Juergen Gross , Jeremy Fitzhardinge , Rusty Russell , "linux-kernel@vger.kernel.org" , Andy Lutomirski , David Vrabel , "H. Peter Anvin" , xen-devel@lists.xenproject.org, Borislav Petkov , X86 ML From: Boris Ostrovsky Message-ID: <56A7EA6A.2030502@oracle.com> Date: Tue, 26 Jan 2016 16:51:38 -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: <20160126203023.GI20964@wotan.suse.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/26/2016 03:30 PM, Luis R. Rodriguez wrote: > > What I'm proposing? > > 1) Lets see if we can put a proactive stop-gap to issues such as the cr4 shadow > bug and Kasan bugs from creeping in. This should not only help PV but perhaps > HVMLite. If you'd like to help with that refer to this thread: > > http://lkml.kernel.org/r/CAB=NE6VTCRCazcNpCdJ7pN1eD3=x_fcGOdH37MzVpxkKEN5esw@mail.gmail.com > > 2) asm code sharing prospects - rebranding of PVH to HVMlite > > It sounds like HVMlite is really just a clean PVH implementation so we'll > be doing this it seems according to this approach: > > a) Since PVH brand is taken add new new Xen clean solution as "HVMLite implementation" > b) Drop PVH > c) Re-brand HVMLite as PVH > > Is there really no asm code to share between PV and HVMlite ? Not the early boot code. > How about between > PV and other Linux asm ? Specifically I'm talking about a huge new entry point > called hvmlite_start_xen() of asm code. How much sharing or duplication > is being avoided here? I don't see that we can share much here. Especially given that hvmlite_start() is a 32-bit entry point so we can't start a 64-bit PV guest. I suppose we can find some common (C) code that sets boot_params but on the first sight they are quite different too. (And whether it's huge is a matter of opinion ;-). It is more than a couple of instructions, I'll give you that) > > 3) C code sharing prospects: rebranding of PVH to HVMlite > > This code seems to share a lot from PV guest. Can we combine? HVMlite closely follows HVM (and baremetal) code path. There is some common setup code with PV (which is what the second patch in this series is trying to factor out) > > 4) hardware_subarch, hardware_subarch_data and future prospects > > Your patch relies on a *new* Linux entry point. Sure, we had one > for EFI, and sure there is another for Xen PV, but since you're just > rebranding PVH to HVMlite and given historic issues with any new > Linux entry points I'd like for us to take a breather and evaluate > the extent our lofty unification goals, and how the x86 boot protocol > could help with this already. I am not sure I see how you can avoid having new entry point. For example, all HVMlite guests start in 32-bit mode. Who will switch to long mode? > > Now, perhaps today it may seem as difficult to unify asm entry points > today all over, but if we can take baby steps towards that I think that > should be seriously evaluated. > > For instance, we should consider on relying on hardware_subarch and > hardware_subarch_data to fetch the hvmlite_start_info by taking advantage of > the x86 boot protocol. The hvmlite_start_info is what Xen uses to send us info > about the guest as your patch proposes (this matches the Xen PV style entry), > we stash it into a standard Linux boot_params variable called > xen_hvmlite_boot_params for the Xen guest in hvmlite_bootparam(). This > data structure and code seems to match very much the PV guest structure, No, the two don't match at all. > why not just use a union and differentiate on PV subtype ? If you want to avoid > a lot of PV calls for HVMlite it seems you could just take advantage of > subarch Xen type, and differentiate on the subarch_data within Xen code > to make that code just PV sepecific. > > I only see gains by using the Xen subarch, so would like to know why PC is > being pushed. It's not that subarch 0 is being pushed here. It's that I don't see how it can be useful for this particular guest type. Maybe as we add new features (or discover something that we've missed up till now) we can switch to using it. If you think we should delay initializing boot_params until then --- I will disagree: boot_params are used before we look at subarch and I don't believe it makes sense to pick and choose what to initialize before and what can wait. (And I am not sure it can be useful on PV neither, at least the way it is used now. You will not reach the point in the (32-bit) code where it is tested. You will die way earlier (I think on startup_32()'s fourth instruction).) -boris