Gregory Haskins wrote:
>
>>
>>> struct kvm *kvm;
>>> struct preempt_hook preempt_hook;
>>> int vcpu_id;
>>> - union {
>>> - struct vmcs *vmcs;
>>> - struct vcpu_svm *svm;
>>> - };
>>> + void *_priv;
>>>
>>>
>> The other cooks did this by embedding the one of the structures within
>> the other, which reduces indirections.
>>
>
> I don't understand what you mean. Can you elaborate more?
>
>
The suggestion I liked best (Anthony's) was
struct vmx_vcpu {
struct kvm_vcpu vcpu;
void *vmcs;
// other vmx-specific data
};
to move from a kvm_vcpu to a vmx_vcpu, you use container_of() (inside
your vmx() inline). Look ma, no pointers!
>>> @@ -1664,7 +1664,7 @@ void load_msrs(struct vmx_msr_entry *e, int n)
>>> }
>>> EXPORT_SYMBOL_GPL(load_msrs);
>>>
>>> -void save_msrs(struct vmx_msr_entry *e, int n)
>>> +void save_msrs(struct kvm_msr_entry *e, int n)
>>> {
>>> int i;
>>>
>>>
>> This isn't actually used in svm, so we can keep the name vmx_msr_entry
>>
>
> Note that the structure really is called "kvm_msr_entry" and there was a
> lingering typedef to name it "vmx_msr_entry" for places that still used
> the vmx variant. I just cleaned that up and got rid of the typedef.
>
>
Ah, okay then.
Too many people are touching this area without coordinating (and one
patch will invalidate all the rest). I'm not going to try to
coordinate; instead I'll apply the first one I like.
--
error compiling committee.c: too many arguments to function
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
kvm-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel
