From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Subject: Re: [Draft A] Boot ABI for HVM guests without a device-model Date: Thu, 11 Jun 2015 10:23:28 +0200 Message-ID: <55794580.3020208@citrix.com> References: <55782EB8.1060708@citrix.com> <5578390E.1090700@citrix.com> <55785A0C.5020706@citrix.com> <55785E50.8090200@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Z2xlw-0002gB-HP for xen-devel@lists.xenproject.org; Thu, 11 Jun 2015 08:23:36 +0000 In-Reply-To: <55785E50.8090200@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper , xen-devel Cc: Elena Ufimtseva , Ian Campbell , Stefano Stabellini , Tim Deegan , Jan Beulich , Boris Ostrovsky List-Id: xen-devel@lists.xenproject.org El 10/06/15 a les 17.57, Andrew Cooper ha escrit: >>>> Do we want to keep using the start_info page? Most of the fields there >>>> are not relevant for auto-translated guests, but without it we have to >>>> figure out how to pass the following information to the guest: >>>> >>>> - Flags: SIF_xxx flags, this could probably be done with cpuid instead. >>>> - cmd_line: ? >>>> - console mfn: ? >>>> - console evtchn: ? >>>> - console_info address: ? >>> All console information should be available from the HVMPARAMS. I see >>> no reason to prevent a PVH guest getting at these. >>> >>> This just leaves the command line being awkward. >> I've forgot to add the kernel payload (initramfs), which could also be >> fetched using a HVMPARAM, so that just leaves the cmd_line, which could >> be passed as a physical memory address in one of the gp registers. I >> don't have a strong opinion on whether we should create a new >> hvm_start_info struct that contains those, or whether we should just add >> new HVMPARAMS. > > I should have remembered as well, as I have a curiously-pvh-like usecase > which wants similar bits. > > The reason I suggested multiboot was for modules and command line > support. If we are not going for exactly multiboot, but something > similar, we might want to make a pvh_start_info with a module list and > cmdline pointer in it. I don't think we can go for multiboot as-is. It implicitly requires an ELF32 binary unless you want to setup the address header of multiboot, and even in that case it lacks a proper way to load a symtab/strtab for example, which the generic Xen ELF loader has. Roger.