| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] [PATCH 4/8] HVM save restore: vcpu context support
I know this is late, because the patch has alreyad gone in, and
appologies if I've misunderstood something here...
[snip
> +++ b/xen/include/public/arch-x86/xen.h Thu Jan 11
Xen.h is a generic file
> 16:51:03 2007 +0800
> @@ -107,6 +107,70 @@ DEFINE_XEN_GUEST_HANDLE(trap_info_t);
> DEFINE_XEN_GUEST_HANDLE(trap_info_t);
>
> typedef uint64_t tsc_timestamp_t; /* RDTSC timestamp */
> +
> +/*
> + * World vmcs state
> + */
> +struct vmcs_data {
The name vmcs data indicate that it's Intel architecture specific to me.
Even if we agree on a format that supports both AMD and Intel, shouldn't
this sort of info be in some HVM specific file? [I haven't yet looked at
the differences that may exisit between AMD and Intel].
> + uint64_t eip; /* execution pointer */
> + uint64_t esp; /* stack pointer */
> + uint64_t eflags; /* flags register */
> + uint64_t cr0;
> + uint64_t cr3; /* page table directory */
> + uint64_t cr4;
> + uint32_t idtr_limit; /* idt */
> + uint64_t idtr_base;
> + uint32_t gdtr_limit; /* gdt */
> + uint64_t gdtr_base;
> + uint32_t cs_sel; /* cs selector */
> + uint32_t cs_limit;
> + uint64_t cs_base;
> + uint32_t cs_arbytes;
Defining a struct for the segment info that is then used for all
segments would make this repeat a whole lot less...
> + uint32_t ds_sel; /* ds selector */
> + uint32_t ds_limit;
> + uint64_t ds_base;
> + uint32_t ds_arbytes;
> + uint32_t es_sel; /* es selector */
> + uint32_t es_limit;
> + uint64_t es_base;
> + uint32_t es_arbytes;
> + uint32_t ss_sel; /* ss selector */
> + uint32_t ss_limit;
> + uint64_t ss_base;
> + uint32_t ss_arbytes;
> + uint32_t fs_sel; /* fs selector */
> + uint32_t fs_limit;
> + uint64_t fs_base;
> + uint32_t fs_arbytes;
> + uint32_t gs_sel; /* gs selector */
> + uint32_t gs_limit;
> + uint64_t gs_base;
> + uint32_t gs_arbytes;
> + uint32_t tr_sel; /* task selector */
> + uint32_t tr_limit;
> + uint64_t tr_base;
> + uint32_t tr_arbytes;
> + uint32_t ldtr_sel; /* ldtr selector */
> + uint32_t ldtr_limit;
> + uint64_t ldtr_base;
> + uint32_t ldtr_arbytes;
> + uint32_t sysenter_cs;
> + uint64_t sysenter_esp;
> + uint64_t sysenter_eip;
> + /* msr for em64t */
> + uint64_t shadow_gs;
> + uint64_t flags;
> + /* same size as VMX_MSR_COUNT */
> + uint64_t msr_items[6];
> + uint64_t vmxassist_enabled;
> +};
> +typedef struct vmcs_data vmcs_data_t;
Is vmcs_data_t used anywhere?
> +
> +struct hvmcpu_context {
> + uint32_t valid;
> + struct vmcs_data data;
> + uint64_t gtime;
> +};
Surely this struct should also be in a HVM directory, as it's specific
to HVM domains?
--
Mats
>
> /*
> * The following is all CPU context. Note that the fpu_ctxt
> block is filled
> @@ -154,6 +218,7 @@ struct vcpu_guest_context {
> #endif
> #endif
> unsigned long vm_assist; /* VMASST_TYPE_*
> bitmap */
> + struct hvmcpu_context hvmcpu_ctxt; /* whole vmcs region */
> #ifdef __x86_64__
> /* Segment base addresses. */
> uint64_t fs_base;
> diff -r ee20d1905bde xen/include/xlat.lst
> --- a/xen/include/xlat.lst Thu Jan 11 16:40:55 2007 +0800
> +++ b/xen/include/xlat.lst Thu Jan 11 16:51:35 2007 +0800
> @@ -8,6 +8,8 @@
> ? vcpu_time_info xen.h
> ! cpu_user_regs arch-x86/xen-@arch@.h
> ! trap_info arch-x86/xen.h
> +! hvmcpu_context arch-x86/xen.h
> +! vmcs_data arch-x86/xen.h
> ! vcpu_guest_context arch-x86/xen.h
> ? acm_getdecision acm_ops.h
> ! ctl_cpumap domctl.h
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home