Re: [Xen-devel] [PATCH v3 07/32] xen/x86: fix arch_set_info_guest for HVM guests

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.07.15 at 17:48, <roger.pau@xxxxxxxxxx> wrote:
> El 23/07/15 a les 17.32, Jan Beulich ha escrit:
>>>>> On 23.07.15 at 17:10, <roger.pau@xxxxxxxxxx> 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?

Just like for HVM (and even more so with the plan to allow PVH to
freely switch between 32- and 64-bit modes) the full 64-bit context
should be got and set in a single domctl imo. If the caller was to
first figure out what bitness a to be migrated guest was paused in
(and that may differ between vCPU-s), things would likely become
quite ugly. Not to speak of the need for a 64-bit tool stack to then
have a way to specify which format the structure is in for a "set"
operation.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel