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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 24/07/15 10:59, Roger Pau Monné wrote:
> El 24/07/15 a les 10.22, Jan Beulich ha escrit:
> > > > > On 23.07.15 at 19:12, <andrew.cooper3@xxxxxxxxxx> wrote:
> > > I would go with Jan's suggestion and make
> > > XEN_DOMCTL_{get/set}vcpucontext ineligible for use on HVM guests.
> > Plus, as you said earlier, a new VCPUOP_initialize.
> (Adding the Linux maintainers to get their opinion on the interface)
>
> Just to recap and to make sure I got all the points:
>
>   - vCPU initialization from the toolstack (BSP initialization) is going
> to be done using XEN_DOMCTL_sethvmcontext.
>   - XEN_DOMCTL_{get/set}vcpucontext is going to return EOPNOTSUPP for
> HVM guests.
>   - A new vcpu_guest_contatext (vcpu_hvm_context?) is going to be
> introduced together with a a new VCPUOP_initialize hypercall
> (VCPUOP_hvm_initialize?).
>
> The following is a layout proposal for the new vcpu_context:
>
> 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.

> #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.
~Andrew

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