From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?windows-1252?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
Subject: Re: [PATCH v3 07/32] xen/x86: fix arch_set_info_guest
 for HVM guests
Date: Thu, 23 Jul 2015 17:48:43 +0200
Message-ID: <55B10CDB.5010708@citrix.com>
References: <1435923310-9019-1-git-send-email-roger.pau@citrix.com>
	<1435923310-9019-8-git-send-email-roger.pau@citrix.com>
	<55A3E0F102000078000903B5@mail.emea.novell.com>
	<55B0C100.6000308@citrix.com>
	<55B0EC520200007800094842@prv-mh.provo.novell.com>
	<1437651718.19412.92.camel@citrix.com> <55B103DD.4030901@citrix.com>
	<55B125440200007800094BD2@prv-mh.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=639a7a0fa=roger.pau@citrix.com>)
	id 1ZIIk8-0000RE-Js
	for xen-devel@lists.xenproject.org; Thu, 23 Jul 2015 15:49:08 +0000
In-Reply-To: <55B125440200007800094BD2@prv-mh.provo.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xenproject.org
List-Id: xen-devel@lists.xenproject.org

El 23/07/15 a les 17.32, Jan Beulich ha escrit:
>>>> On 23.07.15 at 17:10, <roger.pau@citrix.com> wrote:
>> IMHO introducing a new structure that gets rid of all the PV-only 
>> fields seems like a good option:
>>
>> struct vcpu_hvm_context {
>> #define _VGCF_online                   5
>> #define VGCF_online                    (1<<_VGCF_online)
>>     uint32_t flags;                         /* VGCF_* flags                 
>> */
>>     struct cpu_hvm_user_regs user_regs;     /* User-level CPU registers     
>> */
>>     /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */
>>     uint32_t ctrlreg[8];                    /* CR0-CR7 (control registers)  
>> */
>>     uint32_t debugreg[8];                   /* DB0-DB7 (debug registers)    
>> */
>> };
>>
>> I'm also seriously considering getting rid of ctrlreg and debugreg.
>> Since HVM VCPUs will always be started in 32bit flat mode, it doesn't
>> make sense IMHO to have both the 32 and the 64 version of the 
>> registers, so cpu_hvm_user_regs is always going to be:
>>
>> struct cpu_hvm_user_regs {
>>     uint32_t ebx;
>>     uint32_t ecx;
>>     uint32_t edx;
>>     uint32_t esi;
>>     uint32_t edi;
>>     uint32_t ebp;
>>     uint32_t eax;
>>     uint32_t eip;
>>     uint32_t esp;
>>     uint32_t eflags;
>>     uint16_t cs;
>>     uint16_t ss;
>>     uint16_t es;
>>     uint16_t ds;
>>     uint16_t fs;
>>     uint16_t gs;
>> };
>>
>> We could however do something similar to what's done in ARM and have
>> a union of both the 32 and the 64bit registers in case we want to
>> start the vCPU in 64bit mode sometime in the future.
> 
> What you gave above is suitable only for VCPUOP_initialise afaict.
> Did you intend this to be the case?

Certainly not, this should also be used by XEN_DOMCTL_setvcpucontext.
I'm afraid I'm missing something obvious, but I don't see why this
couldn't be used by XEN_DOMCTL_setvcpucontext TBH, can you please clarify?

Roger.