From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Subject: Re: [PATCH v6 24/29] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs Date: Tue, 29 Sep 2015 16:01:36 +0200 Message-ID: <560A99C0.5050202@citrix.com> References: <1441368548-43465-1-git-send-email-roger.pau@citrix.com> <1441368548-43465-25-git-send-email-roger.pau@citrix.com> <5600420C02000078000A4234@prv-mh.provo.novell.com> <5609664D.8060604@citrix.com> <560A555402000078000A6625@prv-mh.provo.novell.com> <560A6124.2090404@citrix.com> <560A7EFA02000078000A6846@prv-mh.provo.novell.com> <560A6714.7060303@citrix.com> <560A851202000078000A68AA@prv-mh.provo.novell.com> <560A69DB.9060505@citrix.com> <560A888D02000078000A68DD@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.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZgvTi-0006xu-SW for xen-devel@lists.xenproject.org; Tue, 29 Sep 2015 14:01:58 +0000 In-Reply-To: <560A888D02000078000A68DD@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 , Andrew Cooper Cc: George Dunlap , xen-devel@lists.xenproject.org, Stefano Stabellini , Ian Campbell , Tim Deegan List-Id: xen-devel@lists.xenproject.org El 29/09/15 a les 12.48, Jan Beulich ha escrit: >>>> On 29.09.15 at 12:37, wrote: >> On 29/09/15 11:33, Jan Beulich wrote: >>>>>> On 29.09.15 at 12:25, wrote: >>>> On 29/09/15 11:07, Jan Beulich wrote: >>>>>>>> On 29.09.15 at 12:00, wrote: >>>>>> Therefore, we are back to the question of whether to provide all segment >>>>>> registers, or specify a flat layout without specific selector values. I >>>>>> would prefer the former to the latter. >>>>> If we don't go the CS+SS only route, then yes, I'd too prefer >>>>> completing the set (I would probably agree with not adding FS >>>>> and GS, and even recommend against it in the 64-bit variant, >>>>> but I do insist on ES in that case). >>>> I would still err on the CS/SS/DS/ES side given a straight choice. It >>>> offers more flexibility for rarer usecases. >>> Okay, all four of them then for 32-bit, and just CS and SS for 64-bit? >> >> Is SS needed for 64bit? It is expected to be NUL just like DS and ES. > > Indeed, we should be able to get away without it. And for CS all > we'd need would be a selector. Ok thanks, so we seem to have a consensus. Before posting a new revision, does the following vcpu_hvm_context look fine to both of you: struct vcpu_hvm_x86_32 { uint32_t eax; uint32_t ecx; uint32_t edx; uint32_t ebx; uint32_t esp; uint32_t ebp; uint32_t esi; uint32_t edi; uint32_t eip; uint32_t eflags; uint32_t cr0; uint32_t cr3; uint32_t cr4; /* * EFER should only be used to set the NXE bit (if required) * when starting a vCPU in 32bit mode with paging enabled. */ uint64_t efer; uint32_t cs_base; uint32_t ds_base; uint32_t ss_base; uint32_t es_base; uint32_t tr_base; uint32_t cs_limit; uint32_t ds_limit; uint32_t ss_limit; uint32_t es_limit; uint32_t tr_limit; uint16_t cs_ar; uint16_t ds_ar; uint16_t ss_ar; uint16_t es_ar; uint16_t tr_ar; }; struct vcpu_hvm_x86_64 { uint64_t rax; uint64_t rcx; uint64_t rdx; uint64_t rbx; uint64_t rsp; uint64_t rbp; uint64_t rsi; uint64_t rdi; uint64_t rip; uint64_t rflags; uint64_t cr0; uint64_t cr3; uint64_t cr4; uint64_t efer; /* * Setting the CS attributes field is allowed in order to * start in compatibility mode. */ uint16_t cs_ar; }; struct vcpu_hvm_context { #define VCPU_HVM_MODE_32B 0 /* 32bit fields of the structure will be used. */ #define VCPU_HVM_MODE_64B 1 /* 64bit fields of the structure will be used. */ uint32_t mode; /* CPU registers. */ union { struct vcpu_hvm_x86_32 x86_32; struct vcpu_hvm_x86_64 x86_64; } cpu_regs; }; Thanks, Roger.