Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754772AbcDNJmb (ORCPT ); Thu, 14 Apr 2016 05:42:31 -0400 Received: from smtp.citrix.com ([66.165.176.89]:52145 "EHLO SMTP.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752691AbcDNJm0 (ORCPT ); Thu, 14 Apr 2016 05:42:26 -0400 X-IronPort-AV: E=Sophos;i="5.24,484,1454976000"; d="scan'208";a="347038678" Subject: Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry To: "Luis R. Rodriguez" 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> CC: Matt Fleming , , 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 , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= From: George Dunlap Message-ID: <570F65F7.5050108@citrix.com> Date: Thu, 14 Apr 2016 10:42:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160413185451.GY1990@wotan.suse.de> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-DLP: MIA2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2855 Lines: 63 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. [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". 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? >> 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; and your suggestions for further possibilities (like this one) keep getting more and more obviously unsuitable. 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. -George