From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751693AbcDNT7I (ORCPT ); Thu, 14 Apr 2016 15:59:08 -0400 Received: from mx2.suse.de ([195.135.220.15]:42251 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750738AbcDNT7G (ORCPT ); Thu, 14 Apr 2016 15:59:06 -0400 Date: Thu, 14 Apr 2016 21:59:03 +0200 From: "Luis R. Rodriguez" To: George Dunlap Cc: "Luis R. Rodriguez" , Matt Fleming , jeffm@suse.com, Michael Chang , Linux Kernel Mailing List , Jim Fehlig , Jan Beulich , "H. Peter Anvin" , Daniel Kiper , the arch/x86 maintainers , Takashi Iwai , =?utf-8?Q?Vojt=C4=9Bch_Pavl=C3=ADk?= , Gary Lin , xen-devel , Jeffrey Cheung , Juergen Gross , Stefano Stabellini , Julien Grall , joeyli , Borislav Petkov , Boris Ostrovsky , Charles Arndol , Andrew Cooper , Julien Grall , Andy Lutomirski , David Vrabel , Linus Torvalds , Roger Pau =?iso-8859-1?Q?Monn=E9?= Subject: Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry Message-ID: <20160414195903.GQ1990@wotan.suse.de> References: <20160406024027.GX1990@wotan.suse.de> <20160407185148.GL1990@wotan.suse.de> <5707BD2E.20204@citrix.com> <20160408215854.GU1990@wotan.suse.de> <20160412221225.GN1990@wotan.suse.de> <20160413185451.GY1990@wotan.suse.de> <570F65F7.5050108@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <570F65F7.5050108@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 14, 2016 at 10:42:15AM +0100, George Dunlap wrote: > On 13/04/16 19:54, Luis R. Rodriguez wrote: > > On Wed, Apr 13, 2016 at 11:05:00AM +0100, George Dunlap wrote: > >> On Tue, Apr 12, 2016 at 11:12 PM, Luis R. Rodriguez wrote: > >>> Also, x86 does have a history of short DT use. Just pointing that its there as > >>> an option as well. I'll Cc you on some thread about that. > >> > >> I'm not sure how this is relevant to anything. > > > > You brought DT as a reason why ARM was able to use the native point. > > I'm clarifying DT has nothing to do as a restriction on x86. > > No, DT isn't the reason Xen is able to use the native entry point on > ARM. The reason is, to quote myself: "there are no assumptions made > about what hardware is or is not present on the system -- everything > that needs to be communicated about what is or is not present can be > passed in DT." > > So that's three things: > 1. DT is available to be used > 2. DT is expected as the main thing that entry point accepts > 3. There are no assumptions about what hardware is or is not present in > the system > 4. Everything that needs to be communicated about what is or is not > present can be passed in DT. > > Are #2, #3, and #4 true on x86? If not then #1 is irrelevant. 2) Obviously not, but it can be used. 3) We're getting close to that, see the platform legacy work [0], that should help us mesh things into a generic form that we didn't have before. There may be others, as is being discussed. If you have other ideas now would be great to hear of them. 4) we have ACPI to fill in the gaps these days for not only x86 but also ARM, as such I think it makes sense to only use DT when it makes sense and to standardize on ACPI when possible [0] http://lkml.kernel.org/r/1460592286-300-1-git-send-email-mcgrof@kernel.org > [snip from another thread] > > > One. CE4100. > > > > arch/x86/platform/ce4100/falconfalls.dt > > You CC'd me on some patches related to that. I don't know anything > about the code, but it looked like CE4100 is a subarch, and in response > to that thread Ingo specifically asked you to add a comment saying > basically "Don't add any more subarches". Yeap! > And not only that, but the ugly, nasty legacy PV boot path we're trying > to get rid of IS ALSO A SUBARCH. So instead of a quick stub with an > extra EFI flag, you're proposing we consider add yet another Xen PV subarch? A little while ago I brought that up as a possibility, given that the semantics of use of the subarch were also loose... hence the discussion over that, and now a patch that helps clarify the use as you were Cc'd on. What's been decided is that we should not extend the subarch, however if we need a hypervisor type that's a separate topic and we would need to address that separately. Its possible. I find it sensible specially if the goal is to avoid more sporadic entries on Linux and to help with early boot semantics / addressing dead code prospects. EFI is another option which already has code and an entry and its why I've asked us to consider it. So we should probably not really try to look at adding a hypervisor type until we've really decided that EFI is a no go at all and makes no sense. IMHO we should add new entries to x86 linux only as a last resort measure. > >> What we're talking about is how to get from Xen to a point in the > >> Linux kernel where everything can Just Work. The proposed feature is > >> a mini trampoline that (as I understand it): > >> 1. Tells Xen where to jump to (via ELF note) > >> 2. Sets up some basic modes and pagetables and then jumps to the zero > >> page so Linux can just carry on. > > > > Right, and the my goal is to see to it we do enough homework to > > ensure we reviewed all possibilities to share as much code as possible > > already and looked at all options before saying we certainly need yet > > another entry point. I am not convinced yet this has been done. > > I think we have different ideas about what an appropriate amount of > homework is. :-) Everything you've put forward has been given > consideration and judged unlikely to be promising; That's fine I'm not afraid of suggestions to be discarded, my goal is to evaluate all possibilities from an engineering point of view, and then make decisions. > and your suggestions for further possibilities (like this one) keep getting > more and more obviously unsuitable. Really ? If it wasn't for me looking into the paravirt crap you'd end up likely with some other semantic mess. If you'd really like me to stop chiming in let me know and I'll look away form Xen for good like others have. > We shouldn't be required to actually post code > for every single other option just to prove how ugly they are, > particularly when there's nothing particularly wrong with the code we have. I'm not asking that. I'm asking for an engineering evaluation. That's very different. I am going to the Xen Hackathon after all as well, not sure what else to tell you to show you I'm only after the best engineering solution and it seems we could do much better here. Luis