Avi Kivity wrote:
> Zhang, Xiantao wrote:
>> Avi Kivity wrote:
>>
>>> Zhang, Xiantao wrote:
>>>
>>>> 2. kvm_x86_ops-kvm_ops.patch. In order to adapt different
>>>> architectures, we have to change it to an neutral name. kvm_ops
>>>> maybe not the best name, but shouldn't introduce different
>>>> meanings. In the third patch, we add a sub field struct
>>>> kvm_arch_ops for arch-specific ops. That is, different CPU archs
>>>> can define its arch-specific
>>>> ops for its special need. IMO, we should treat x86, IA64, ppc etc
>>>> as different archtiectures, other than see vmx, svm as different
>>>> archs. svm and vmx should be two different virtualization
>>>> approaches for x86 arch from the point view of platforms.
>>>>
>>>>
>>> ia64, ppc, and s390 don't need to select an implementation at
>>> runtime (since each have just one instruction set) so they don't
>>> need function pointers. Instead we should use linkage (different
>>> functions for each arch, but with the same names). Kbuild will
>>> select the right files to compile depending on arch.
>>>
>>
>> For x86 side, how to handle the co-existence of vmx and svm ? For
>> example, in a release linux kernel which supports KVM, how to know
>> it will be installed to Intel or AMD platforms ? If we determin it in
>> advance, we have to compile them all in at one time, but it maybe
>> difficult for current kvm code to implement.
>>
>
> x86 will continue to use kvm_x86_ops for that purposes. But other
> archs should not.
>
> x86 will use both mechanisms: first, linkage will select the x86
> function, and then kvm_x86_ops will be used to select the
> implementation dependent code. The two levels are very different as
> kvm_x86_ops is very low level and x86 specific.
Hi Avi,
Maybe linkage is a better choice. But if we need to maintain two
different implmentation for different archs, it may introduce
unnecessary effort.
In addition, I can't figure out any disadvantages with function
pointers, moreover, it makes source uniform for all architectures,
though it is not very necessary.
Thanks
Xiantao
-------------------------------------------------------------------------
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
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
