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 18:01:10 +0200 Message-ID: <560AB5C6.6080404@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> <560A99C0.5050202@citrix.com> <560ACA7302000078000A6C93@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 1ZgxLv-0001mC-0d for xen-devel@lists.xenproject.org; Tue, 29 Sep 2015 16:02:03 +0000 In-Reply-To: <560ACA7302000078000A6C93@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 Cc: Ian Campbell , George Dunlap , Andrew Cooper , Tim Deegan , Stefano Stabellini , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org El 29/09/15 a les 17.29, Jan Beulich ha escrit: >>>> On 29.09.15 at 16:01, wrote: >> 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. >> */ > > Hmm, as said before it would seem to me that this would better > (or also) be allowed to work by specifying a suitable 32-bit register > state. Remember that in compatibility mode base and limit matter > again, and I think you also can't start with a nul SS. Yes, I should add back all the registers here, so it looks like: uint32_t cs_base; uint32_t ds_base; uint32_t ss_base; uint32_t es_base; uint32_t cs_limit; uint32_t ds_limit; uint32_t ss_limit; uint32_t es_limit; uint16_t cs_ar; uint16_t ds_ar; uint16_t ss_ar; uint16_t es_ar; >> uint16_t cs_ar; >> }; > > No tr_* here? Is it necessary? for long or compatibility mode tr is always going to be: tr_base = 0; tr_limit = 0x67; tr_ar = 0x8b; The attributes field is always going to be 0x8b for compat or long mode, the base and the limit might be different, but the guest should change that by itself. > Also, what are the selector values going to be? Do you intend to > pass zero there? Do you mean the visible part of the selectors? With the current implementation the value of the "sel" field in the segment_register struct is left uninitialized, so it's undefined. I could set them to 0, but what's the point in doing it? Roger.