All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
To: "Zhang, Xiantao" <xiantao.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Patch] [0/3] Patches to support new architectures.
Date: Thu, 11 Oct 2007 15:01:10 +0200	[thread overview]
Message-ID: <470E1E96.4040601@qumranet.com> (raw)
In-Reply-To: <42DFA526FC41B1429CE7279EF83C6BDC7AEE24-wq7ZOvIWXbMAbVU2wMM1CrfspsVTdybXVpNB7YpNyf8@public.gmane.org>

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.


-- 
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/

  parent reply	other threads:[~2007-10-11 13:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-11  9:08 [Patch] [0/3] Patches to support new architectures Zhang, Xiantao
     [not found] ` <42DFA526FC41B1429CE7279EF83C6BDC7AEDD6-wq7ZOvIWXbMAbVU2wMM1CrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2007-10-11  9:26   ` Carsten Otte
     [not found]     ` <470DEC63.1030004-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
2007-10-11  9:39       ` Zhang, Xiantao
2007-10-11 11:14   ` Avi Kivity
     [not found]     ` <470E0599.40102-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-10-11 12:56       ` Zhang, Xiantao
     [not found]         ` <42DFA526FC41B1429CE7279EF83C6BDC7AEE24-wq7ZOvIWXbMAbVU2wMM1CrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2007-10-11 13:01           ` Avi Kivity [this message]
     [not found]             ` <470E1E96.4040601-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-10-12  1:57               ` Zhang, Xiantao
     [not found]                 ` <42DFA526FC41B1429CE7279EF83C6BDC7AEEFB-wq7ZOvIWXbMAbVU2wMM1CrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2007-10-12  6:36                   ` Avi Kivity
     [not found]                     ` <470F15D7.7080205-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-10-12  6:40                       ` Zhang, Xiantao
     [not found]                         ` <42DFA526FC41B1429CE7279EF83C6BDC808CB3-wq7ZOvIWXbMAbVU2wMM1CrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2007-10-12  8:34                           ` Carsten Otte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=470E1E96.4040601@qumranet.com \
    --to=avi-atkuwr5tajbwk0htik3j/w@public.gmane.org \
    --cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=xiantao.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.