Wahlig, Elsie wrote:
>>> I dislike the name HVAL though -- it's not very informative.
>>> Something like hwassist, vmassist, hw_vm, or many others would all
>>> be preferable imo.
>>>
>>> -- Keir
>>
>> I don't like the name HVAL, either, because of the same
>> reason. What we are doing is to have _additional_ or
>> dedicated interfaces exposed in Xen to provide full
>> virtualization in support of H/W assist virtualization.
>>
>
> HWASSIST was our original name for it, but was deemed to be too long.
> The names with the vm letters hit many false positives when grepping
> code,
> so we avoided all names with 'vm'. Since this was defining an
> interface,
> HVAL was one we went with. Now if the name matters, we can make it
> HWASSIST.
I agree that it's too long, especially when used in the code. I prefer a
3 or 4-letter acronyum. I don't think that real programmers depend on
"grep" when looking at the code. I think using 'vm' is okay in the sence
that it's the common one used by 'vmx' and 'svm' ;-) hw_vm - we want to
avoid '_' because we frequently use '_' in the code. How about hw_vm ->
xvm, i.e. (Xen) Extended Virtual Machine Layer? The idea is that we
extend Xen to support full virtualization. It's a bit confusing with
vmx, but I think we are okay with that. I tentatively use 'xvm' below to
see how it looks like.
>
>> BTW, I don't think the following is the right abstaraction
>> because the original arch_vmx_struct was intended to maintain
>> the architectural state, and it can be different on other H/W
>> assist virtualization. In fact, we need to add more things to
>> support 64-bit guests. The struct virtual_platform_def (and
>> flags) should moved out of the architectual state, and
>> probably arch_svm_struct needs to defined sperately.
>>
>> struct arch_hval_struct {
>> union {
>> struct vmcs_struct *vmcs; //vmx
>> struct vmcb_struct *vmcb; //svm
>> }
>> unsigned long flags; /* VMCS/VMCB flags */
>> unsigned long cpu_cr2;
>> unsigned long cpu_cr3;
>> unsigned long cpu_state;
>> struct virtual_platform_def hval_platform;
>> }
>
> I don't see why we would need both a arch_vmx_struct and an
> arch_svm_struct at one time.
They are exclusive at runtime, and I'm suggesting like
struct arch_vcpu
{
...
struct arch_vmx_struct arch_vmx; =>(replace with below)
=>
union { /* architecture state */
struct_vmx_struct arch_vmx;
struct_svm_struct arch_svm;
}
struct xvm_struct *xvm; /* xen extened virtual machine */
struct xvm_struct {
struct virutal_platform_def xvm_platform;
struct xvm_ops *ops;
};
This way we can cleanly sperate the (vendor-specific) CPU architecture
state, virtual platform state, and the xvm operatons.
struct xvm_ops {
void (*alloc)(struct exec_domain *d);
void (*free)(struct exec_domain *d);
void (*load_cpu_user_regs)(struct cpu_user_regs *regs);
void (*store_cpu_user_regs)(struct cpu_user_regs *regs);
void (*check_guest_faults)(struct cpu_user_regs *regs, long cs,
long eip, long type);
void (*inject_exception)(struct cpu_user_regs *regs, long
exception);
void (*update_eip)(struct cpu_user_regs *regs, long new_eip);
};
> That physical platform wont ever be built. The goal is to abstract
> out the hardware
> and need only maintain one of the control blocks during it's runtime.
> Does your arch
> Need a different vmcs for 64-bits?
No. For example, handling MSRs, such as MSR_LSTAR, MSR_STAR, MSR_CSTAR,
MSR_SYSCALL_MASK, MSR_EFER can be different. Some of them are
saved/restored at VMEXIT time, but some are not, or even configurable.
Handling of the control registers such as CR0, CR4, CR8 is another
example. It can be different depending on the virtualization technology.
Today we don't have sufficient data which CPU state shoud be exposed as
the generic state. If we need to expose some CPU state in the CPU (like
long mode), we should add one to the xvm_ops, not to the data structure.
>
> Elsie Wahlig
Jun
---
Intel Open Source Technology Center
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home