[Disscussion] Moving x86 code out of kvm.h

[Disscussion] Moving x86 code out of kvm.h

[Jerone Young]

This is a continuation of a conversation I have been having with Izik
Eidus on IRC today.

I plan on moving x86 code out of kvm.h and into kvm-x86.h. kvm-x86.h
would then include kvm.h and would be included by files like svm.c
instead of kvm.h. 

Izik pointed out a big issue with this approach and that is it breaks
compatibility with older userspace. We believe that everyone still cares
that older userspace should be able to compile against a newer kvm
kernels. Is this true or should we just dump it?

Assuming this is true, we have come up with an interesting solution to
the problem.

- creation of new header name "portablekvm.h" (please give a better name
if you know one). This would be the new place for common code that would
normally be kvm.h.

- still create header "kvm-x86.h" for x86 code and would include this
new "portablekvm.h" header.

- keep compatibility with older userspace by taking header "kvm.h" and
jsut have it include kvm-x86.h &  portablekvm.h and have no other code
(unless it's for compatibility).

What does everyone thing about this ?


Also a side discussion is should we really start thinking about having a
userspace header and stop userspace apps from including kernel headers.
This does lead to a problem where if the kernel header is updated the
userspace header must also be updated (but maybe it's time to bite the
bullet)?


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

Re: [Disscussion] Moving x86 code out of kvm.h

[Avi Kivity]

Jerone Young wrote:
> This is a continuation of a conversation I have been having with Izik
> Eidus on IRC today.
>
> I plan on moving x86 code out of kvm.h and into kvm-x86.h. kvm-x86.h
> would then include kvm.h and would be included by files like svm.c
> instead of kvm.h. 
>
>   

Which kvm.h are we talking about? include/linux/kvm.h or drivers/kvm/kvm.h?

> Izik pointed out a big issue with this approach and that is it breaks
> compatibility with older userspace. We believe that everyone still cares
> that older userspace should be able to compile against a newer kvm
> kernels. Is this true or should we just dump it?
>   

Of course we can't break compatibility without an excellent reason.

> Assuming this is true, we have come up with an interesting solution to
> the problem.
>
> - creation of new header name "portablekvm.h" (please give a better name
> if you know one). This would be the new place for common code that would
> normally be kvm.h.
>
> - still create header "kvm-x86.h" for x86 code and would include this
> new "portablekvm.h" header.
>
> - keep compatibility with older userspace by taking header "kvm.h" and
> jsut have it include kvm-x86.h &  portablekvm.h and have no other code
> (unless it's for compatibility).
>
> What does everyone thing about this ?
>
>   

Have kvm.h include <asm/kvm.h>

> Also a side discussion is should we really start thinking about having a
> userspace header and stop userspace apps from including kernel headers.
> This does lead to a problem where if the kernel header is updated the
> userspace header must also be updated (but maybe it's time to bite the
> bullet)?
>
>   

The userspace header is include/linux/kvm.h.  No need to be cruel to
innocent bullets.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


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

Re: [Disscussion] Moving x86 code out of kvm.h

[Izik Eidus]

On Thu, 2007-11-15 at 10:34 +0200, Avi Kivity wrote:
> Jerone Young wrote:
> > This is a continuation of a conversation I have been having with Izik
> > Eidus on IRC today.
> >
> > I plan on moving x86 code out of kvm.h and into kvm-x86.h. kvm-x86.h
> > would then include kvm.h and would be included by files like svm.c
> > instead of kvm.h. 
> >
> >   
> 
> Which kvm.h are we talking about? include/linux/kvm.h or drivers/kvm/kvm.h?
> 
> > Izik pointed out a big issue with this approach and that is it breaks
> > compatibility with older userspace. We believe that everyone still cares
> > that older userspace should be able to compile against a newer kvm
> > kernels. Is this true or should we just dump it?
> >   
> 
> Of course we can't break compatibility without an excellent reason.
> 
> > Assuming this is true, we have come up with an interesting solution to
> > the problem.
> >
> > - creation of new header name "portablekvm.h" (please give a better name
> > if you know one). This would be the new place for common code that would
> > normally be kvm.h.
> >
> > - still create header "kvm-x86.h" for x86 code and would include this
> > new "portablekvm.h" header.
> >
> > - keep compatibility with older userspace by taking header "kvm.h" and
> > jsut have it include kvm-x86.h &  portablekvm.h and have no other code
> > (unless it's for compatibility).
> >
> > What does everyone thing about this ?
> >
> >   
> 
> Have kvm.h include <asm/kvm.h>
what you mean by that?


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

Re: [Disscussion] Moving x86 code out of kvm.h

[Avi Kivity]

Izik Eidus wrote:
>>>   
>>>       
>> Have kvm.h include <asm/kvm.h>
>>     
> what you mean by that?
>
>   

include/asm is a symlink to include/asm-$arch, and this is where
arch-specific definitions are placed in Linux.


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


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

Re: [Disscussion] Moving x86 code out of kvm.h

[Jerone Young]

On Thu, 2007-11-15 at 10:34 +0200, Avi Kivity wrote:
> Jerone Young wrote:
> > This is a continuation of a conversation I have been having with Izik
> > Eidus on IRC today.
> >
> > I plan on moving x86 code out of kvm.h and into kvm-x86.h. kvm-x86.h
> > would then include kvm.h and would be included by files like svm.c
> > instead of kvm.h. 
> >
> >   
> 
> Which kvm.h are we talking about? include/linux/kvm.h or drivers/kvm/kvm.h?

Whoops should have been more clear about this. It was late for me :-)

But I was first referring to inclue/linux/kvm.h.

I believe I actually started looking at drivers/kvm/kvm.h at the same
time (which is why my email is so screwed, but this is not as big of a
deal for now). 

Never the less it looks like the discussion has taken off. I'll just
join in that.


> 
> > Izik pointed out a big issue with this approach and that is it breaks
> > compatibility with older userspace. We believe that everyone still cares
> > that older userspace should be able to compile against a newer kvm
> > kernels. Is this true or should we just dump it?
> >   
> 
> Of course we can't break compatibility without an excellent reason.
> 
> > Assuming this is true, we have come up with an interesting solution to
> > the problem.
> >
> > - creation of new header name "portablekvm.h" (please give a better name
> > if you know one). This would be the new place for common code that would
> > normally be kvm.h.
> >
> > - still create header "kvm-x86.h" for x86 code and would include this
> > new "portablekvm.h" header.
> >
> > - keep compatibility with older userspace by taking header "kvm.h" and
> > jsut have it include kvm-x86.h &  portablekvm.h and have no other code
> > (unless it's for compatibility).
> >
> > What does everyone thing about this ?
> >
> >   
> 
> Have kvm.h include <asm/kvm.h>
> 
> > Also a side discussion is should we really start thinking about having a
> > userspace header and stop userspace apps from including kernel headers.
> > This does lead to a problem where if the kernel header is updated the
> > userspace header must also be updated (but maybe it's time to bite the
> > bullet)?
> >
> >   
> 
> The userspace header is include/linux/kvm.h.  No need to be cruel to
> innocent bullets.
> 


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

Re: [Disscussion] Moving x86 code out of kvm.h

[Zhang, Xiantao]

Jerone Young wrote:
> This is a continuation of a conversation I have been having with Izik
> Eidus on IRC today.
> 
> I plan on moving x86 code out of kvm.h and into kvm-x86.h. kvm-x86.h
> would then include kvm.h and would be included by files like svm.c
> instead of kvm.h.

I assume you are talking about include/linux/kvm.h, since userspace
doesn't need drivers/kvm/kvm.h. 

For driver/kvm/kvm.h,  I have a proposal before in mailing list.  In my
proposal, we can split x86-specific code of kvm.h into current x86.h,
and make code in kvm.h as common. Then, we rename kvm.h to kvm_comm.h,
and also rename x86.h to kvm-x86.h, and meantime kvm-x86.h would include
kvm_comm.h. 
At compile time, we can make symbol link for changing kvm-x86.h to
kvm.h.  So, it should be more portable, because different archs can
define its kvm-$arch.h to hold its arch-specific code. 

Xiantao

> Izik pointed out a big issue with this approach and that is it breaks
> compatibility with older userspace. We believe that everyone still

> 
> 
>
------------------------------------------------------------------------
-
> 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-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel

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

Re: [Disscussion] Moving x86 code out of kvm.h

[Avi Kivity]

Zhang, Xiantao wrote:
> Jerone Young wrote:
>   
>> This is a continuation of a conversation I have been having with Izik
>> Eidus on IRC today.
>>
>> I plan on moving x86 code out of kvm.h and into kvm-x86.h. kvm-x86.h
>> would then include kvm.h and would be included by files like svm.c
>> instead of kvm.h.
>>     
>
> I assume you are talking about include/linux/kvm.h, since userspace
> doesn't need drivers/kvm/kvm.h. 
>
> For driver/kvm/kvm.h,  I have a proposal before in mailing list.  In my
> proposal, we can split x86-specific code of kvm.h into current x86.h,
> and make code in kvm.h as common. Then, we rename kvm.h to kvm_comm.h,
> and also rename x86.h to kvm-x86.h, and meantime kvm-x86.h would include
> kvm_comm.h. 
> At compile time, we can make symbol link for changing kvm-x86.h to
> kvm.h.  So, it should be more portable, because different archs can
> define its kvm-$arch.h to hold its arch-specific code. 
>   

I prefer not to have dynamic symlinks, it's too tricky.

What's wrong with just the first part, x86.h which includes kvm.h?  
x86.c will include x86.h, and arch neutral files will include kvm.h.

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

Re: [Disscussion] Moving x86 code out of kvm.h

[Zhang, Xiantao]

Avi Kivity wrote:
> Zhang, Xiantao wrote:
>> Jerone Young wrote:
>> 
>>> This is a continuation of a conversation I have been having with
>>> Izik Eidus on IRC today. 
>>> 
>>> I plan on moving x86 code out of kvm.h and into kvm-x86.h. kvm-x86.h
>>> would then include kvm.h and would be included by files like svm.c
>>> instead of kvm.h. 
>>> 
>> 
>> I assume you are talking about include/linux/kvm.h, since userspace
>> doesn't need drivers/kvm/kvm.h.
>> 
>> For driver/kvm/kvm.h,  I have a proposal before in mailing list.  In
>> my proposal, we can split x86-specific code of kvm.h into current
>> x86.h, and make code in kvm.h as common. Then, we rename kvm.h to
>> kvm_comm.h, and also rename x86.h to kvm-x86.h, and meantime
>> kvm-x86.h would include kvm_comm.h. At compile time, we can make
>> symbol link for changing kvm-x86.h to kvm.h.  So, it should be more
>> portable, because different archs can define its kvm-$arch.h to hold
>> its arch-specific code. 
>> 
> 
> I prefer not to have dynamic symlinks, it's too tricky.
> 
> What's wrong with just the first part, x86.h which includes kvm.h?
> x86.c will include x86.h, and arch neutral files will include kvm.h.

I think it may have issues. For example, where do we put struct
kvm_vcpu, and struct kvm? If we place them in x86.h, then kvm_main.c and
other neutral files can't reach it.  If we put them in kvm.h, how to
handle arch-specific fields in them ?

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/

Re: [Disscussion] Moving x86 code out of kvm.h

[Avi Kivity]

Zhang, Xiantao wrote:
>>> For driver/kvm/kvm.h,  I have a proposal before in mailing list.  In
>>> my proposal, we can split x86-specific code of kvm.h into current
>>> x86.h, and make code in kvm.h as common. Then, we rename kvm.h to
>>> kvm_comm.h, and also rename x86.h to kvm-x86.h, and meantime
>>> kvm-x86.h would include kvm_comm.h. At compile time, we can make
>>> symbol link for changing kvm-x86.h to kvm.h.  So, it should be more
>>> portable, because different archs can define its kvm-$arch.h to hold
>>> its arch-specific code. 
>>>
>>>       
>> I prefer not to have dynamic symlinks, it's too tricky.
>>
>> What's wrong with just the first part, x86.h which includes kvm.h?
>> x86.c will include x86.h, and arch neutral files will include kvm.h.
>>     
>
> I think it may have issues. For example, where do we put struct
> kvm_vcpu, and struct kvm? If we place them in x86.h, then kvm_main.c and
> other neutral files can't reach it.  If we put them in kvm.h, how to
> handle arch-specific fields in them ?
>   

Someone (I forget who) suggested using the same trick we use for vmx and 
svm.  We nest as follows:

struct vcpu_vmx {
   struct vcpu_x86 {
        struct kvm_vcpu {
             // common fields;
        } vcpu;
        // x86 specific fields;
   } x86;
   // vmx specific fields;
};

Allocation is done by arch specific code which allocates the outermost 
structure.  Common code sees only kvm_vcpu and its fields.  When it 
calls x86 arch hooks, they use the vcpu_x86() macro (which is a call to 
container_of()) to gain access to x86 specific fields.  When x86 code 
calls vmx specific code (using kvm_x86_ops), that uses vcpu_vmx() to 
gain access to the vmx specific fields.  Any similarity to a language 
derived from C, living or dead, is purely coincidental and unintended.

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

Re: [Disscussion] Moving x86 code out of kvm.h

[Zhang, Xiantao]

Avi Kivity wrote:
> Zhang, Xiantao wrote:
>>>> For driver/kvm/kvm.h,  I have a proposal before in mailing list. 
>>>> In my proposal, we can split x86-specific code of kvm.h into
>>>> current x86.h, and make code in kvm.h as common. Then, we rename
>>>> kvm.h to kvm_comm.h, and also rename x86.h to kvm-x86.h, and
>>>> meantime kvm-x86.h would include kvm_comm.h. At compile time, we
>>>> can make symbol link for changing kvm-x86.h to kvm.h.  So, it
>>>> should be more portable, because different archs can define its
>>>> kvm-$arch.h to hold its arch-specific code. 
>>>> 
>>>> 
>>> I prefer not to have dynamic symlinks, it's too tricky.
>>> 
>>> What's wrong with just the first part, x86.h which includes kvm.h?
>>> x86.c will include x86.h, and arch neutral files will include kvm.h.
>>> 
>> 
>> I think it may have issues. For example, where do we put struct
>> kvm_vcpu, and struct kvm? If we place them in x86.h, then kvm_main.c
>> and other neutral files can't reach it.  If we put them in kvm.h,
>> how to handle arch-specific fields in them ?
>> 
> 
> Someone (I forget who) suggested using the same trick we use for vmx
> and svm.  We nest as follows:
> 
> struct vcpu_vmx {
>    struct vcpu_x86 {
>         struct kvm_vcpu {
>              // common fields;
>         } vcpu;
>         // x86 specific fields;
>    } x86;
>    // vmx specific fields;
> };
> 
> Allocation is done by arch specific code which allocates the outermost
> structure.  Common code sees only kvm_vcpu and its fields.  When it
> calls x86 arch hooks, they use the vcpu_x86() macro (which is a call
> to container_of()) to gain access to x86 specific fields.  When x86
> code calls vmx specific code (using kvm_x86_ops), that uses
> vcpu_vmx() to gain access to the vmx specific fields.  Any similarity
> to a language derived from C, living or dead, is purely coincidental
> and unintended. 

Indeed a tricky way!  From code logic, it should works well, but don't
know it is an elegant way to define such structure :-)

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/