Re: [Patch][RFC]Split kvm_vcpu to support new archs.

Zhang, Xiantao
2007-10-12T08:51:01Z

Christian Ehrhardt wrote:
> Zhang, Xiantao wrote:
>> --- /dev/null
>> +++ b/drivers/kvm/kvm_arch.h
> [...]
>> +struct kvm_arch_vcpu{
>> +
>> + u64 host_tsc;
>> +
>> + unsigned long regs[NR_VCPU_REGS]; /* for rsp:
>> vcpu_load_rsp_rip() */
>> + unsigned long rip; /* needs vcpu_load_rsp_rip() */ +
>> + unsigned long cr0;
>> + unsigned long cr2;
>> + unsigned long cr3;
>> + unsigned long cr4;
>> + unsigned long cr8;
>> + u64 pdptrs[4]; /* pae */
>> + u64 shadow_efer;
>> + u64 apic_base;
>> + struct kvm_lapic *apic; /* kernel irqchip context */ +
>> + u64 ia32_misc_enable_msr;
>> +
>> +
>> + struct i387_fxsave_struct host_fx_image;
>> + struct i387_fxsave_struct guest_fx_image;
>> + int fpu_active;
>> + int guest_fpu_loaded;
>> +
>> + gva_t mmio_fault_cr2;
>> +
>> + struct {
>> + int active;
>> + u8 save_iopl;
>> + struct kvm_save_segment {
>> + u16 selector;
>> + unsigned long base;
>> + u32 limit;
>> + u32 ar;
>> + } tr, es, ds, fs, gs;
>> + } rmode;
> [...]
>
> As far as I can see without applying it, that split is ok for
> powerpc. I had a similar approach in my local patch queue too.
> Minor differences in which elements of the structs are arch dependent
> or not can be changed in small patches later ;-)

> But the file kvm_arch.h name confuses me a bit - I assume you had the
> coming asm split in mind where every architecture can define it's
> asm/kvm_arch.h. Since we don't have that asm structure for kvm yet,
> the changes you made to kvm_arch.h may be better located at the x86.h
> atm.
According to our previous discuss, we proposed a source layout, which
contains an "include" directory to hold header files for all archs
under drivers/kvm/, and kvm_arch.h will finally go into
drivers/kvm/include/kvm-x86/(linked as kvm when compile). So, every
architecture can defines its own kvm_arch.h for their arch, and compile
will choose it per ARCH when compile time. But for now, we can just put
it here before another real new arch in. Then, we can remove x86.h,
since it is not so common for all archs. :)
BTW, header files should be managed with a uniform method, because
possible archs, such as IA64, maybe need many ones.
Thanks
Xiatnao