[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
>>> 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? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |