|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 07/32] xen/x86: fix arch_set_info_guest for HVM guests
El 24/07/15 a les 13.11, Andrew Cooper ha escrit:
> On 24/07/15 10:59, Roger Pau Monné wrote:
>> struct vcpu_hvm_context {
>> /* 32bit fields of the structure will be used. */
>> #define _VCPUHVM_MODE_32B 0
>> #define VCPUHVM_MODE_32B (1<<_VCPUHVM_MODE_32B)
>> /* 64bit fields of the structure will be used. */
>> #define _VCPUHVM_MODE_64B 1
>> #define VCPUHVM_MODE_64B (1<<_VCPUHVM_MODE_64B)
>> #define _VCPUHVM_online 2
>> #define VCPUHVM_online (1<<_VCPUHVM_online )
>> uint32_t flags; /* VCPUHVM_* flags. */
>> struct cpu_hvm_regs user_regs; /* CPU registers. */
>> };
>
> To avoid making the 32bit (and optionally 16bit) massive as a side
> effect of 64bit, can I suggest
>
> uint32_t flags;
> union {
> cpu_hvm32_regs;
> cpu_hvm64_regs;
> };
>
> Which allows hvm32_regs to be a far smaller structure.
But what's the benefit of this? vcpu_hvm_context is going to be equally
large, and that's what we pass as the hypercall argument. This is
mimicking the format of the structure that's already used on ARM, so I
would rather keep it as is.
>>
>> #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
>> /* Anonymous union includes both 32- and 64-bit names (e.g., ebp/rbp). */
>> # define __DECL_REG(n64, n32) union { \
>> uint64_t n64; \
>> uint32_t n32; \
>> }
>> #else
>> /* Non-gcc sources must always use the proper 64-bit name (e.g., rbp). */
>> #define __DECL_REG(n64, n32) uint64_t n64
>> #endif
>>
>> #define __DECL_GP_REG(n) __DECL_REG(r##n, e##n)
>>
>> struct cpu_hvm_regs {
>> /* General purpose registers. */
>> __DECL_GP_REG(bx);
>> __DECL_GP_REG(cx);
>> __DECL_GP_REG(dx);
>> __DECL_GP_REG(si);
>> __DECL_GP_REG(di);
>> __DECL_GP_REG(bp);
>> __DECL_GP_REG(ax);
>> __DECL_GP_REG(ip);
>> __DECL_GP_REG(sp);
>> __DECL_GP_REG(flags);
>>
>> /* Control registers. */
>> uint64_t cr[8];
>> /* Valid on amd64 only. */
>> uint64_t efer;
>>
>> /* Debug registers. */
>> uint64_t db[8];
>> };
>>
>> #undef __DECL_GP_REG
>> #undef __DECL_REG
>>
>> Of course the APs will be allowed to start in any mode they wish,
>> regardless of the mode the guest is currently running on.
>
> To start straight in 64bit, you need gdtr and cs as a minimum
>
> With that in mind, room for each of the task registers, and segment
> selectors.
I was planning to say that on both 32 and 64 bits we start with a flat
GDT (like we do for the BSP). But we can also arrange for this to be set
by the user. So we would need to add the following fields:
uint{16/32/64}_t gdtr;
uint16_t ss, es, ds, fs, gs;
uint16_t tr;
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |