From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [Draft C] Boot ABI for HVM guests without a device-model Date: Fri, 4 Sep 2015 16:26:33 +0100 Message-ID: <1441380393.25589.0.camel@citrix.com> References: <55E98A8F.3080305@citrix.com> <55E9C1E1020000780009FC72@prv-mh.provo.novell.com> <55E9AB40.8060402@citrix.com> <55E9D30C020000780009FD9F@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZXt8A-0005Oy-Q1 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2015 15:42:22 +0000 In-Reply-To: <55E9D30C020000780009FD9F@prv-mh.provo.novell.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: Jan Beulich , Roger Pau =?ISO-8859-1?Q?Monn=E9?= Cc: Elena Ufimtseva , Andrew Cooper , Boris Ostrovsky , Tim Deegan , xen-devel List-Id: xen-devel@lists.xenproject.org On Fri, 2015-09-04 at 09:21 -0600, Jan Beulich wrote: > > > > > > On 04.09.15 at 16:31, wrote: > > El 04/09/15 a les 16.08, Jan Beulich ha escrit: > > > > > > On 04.09.15 at 14:11, wrote: > > > > The format of the structure passed in the %ebx register is the > > > > following: > > > > > > Even if it may sound like splitting hair: Please use precise wording. > > > It's > > > not the structure that's contained in %ebx, but %ebx hold the address > > > of that structure. > > > > Would you be fine with replacing this sentence with: > > > > The format of the boot start info structure is the following: > > Yes (maybe insert "(pointed to be %ebx)"). > > > > > struct hvm_start_info { > > > > #define HVM_START_MAGIC_VALUE 0x336ec578 > > > > uint32_t magic; /* Contains the magic value > > > > 0x336ec578 */ > > > > /* ("xEn3" with the 0x80 bit of the > > > > "E" set).*/ > > > > uint32_t flags; /* SIF_xxx flags. > > > > */ > > > > > > Do really mean to re-use the SIF_* flags here? > > > > We can introduce a new set of flags, HVM_INIT_*, which ATM is only > > going > > to be: > > > > #define HVM_FLAGS_INITDOMAIN (1<<0) > > From an abstract pov I'd prefer that. Maybe I'm overlooking > something which would be simplified by using the same values... > > > > > AP startup > > > > ========== > > > > > > > > AP startup is performed using hypercalls. The following VCPU > > > > operations > > > > are used in order to bring up secondary vCPUs: > > > > > > > > * VCPUOP_initialise is used to set the initial state of the vCPU. > > > > The > > > > argument passed to the hypercall must be of the type > > > > vcpu_hvm_context. > > > > > > VCPUOP_initialise takes a struct vcpu_guest_context; I don't think > > > we can or should change that. > > > > Didn't we agree that vcpu_guest_context was not suitable for HVM/PVH > > guests? > > Yes we did. > > > Patch 24 of my HVM-without-dm series already introduces this new > > structure and the necessary helpers. > > I didn't look at most of the series yet (despite it already being at v6; > I'm sorry, I just didn't get around so far). But I think you agree that > we can't just change an existing hypercall. Iirc along with agreeing > on vcpu_guest_context not being suitable we also agreed that this > will need to be a new sub-op, and I wondered whether calling it > VCPUOP_initialize would be too subtle. You mean literally only s/s/z/? In which case, yes, far far to subtle. Even initialise2 would be better than that alternative... > > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel