RE: [Xen-devel] [PATCH 4/8] HVM save restore: vcpu context support

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

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