KVM is due to receive support for multiple architectures (ppc, ia64, and
s390, in addition to the existing x86), hopefully in time for the 2.6.25
merge window. It is awkward to place the new arch support in
drivers/kvm/, so I'd like to propose the following new layout:
virt/ top-level directory for hypervisors
virt/kvm/ kvm common code
virt/lguest/ the other hypervisor
arch/*/kvm/ arch dependent kvm code
include/linux/kvm.h arch independent interface
include/asm/kvm.h arch dependent interface
include/linux/kvm_para.h arch independent guest interface
include/asm/kvm_para.h arch dependent guest interface
The include/ hierarchy is already in place; I'm including it for
completeness.
Comments, alternative suggestions welcome.
[This was foreshadowed about a year ago in
http://lkml.org/lkml/2006/11/28/32, where the conclusion of the thread
was to wait a year before making this change. Quite an accurate
prediction.]
--
error compiling committee.c: too many arguments to function
Am Dienstag, 11. Dezember 2007 schrieb Avi Kivity:
> KVM is due to receive support for multiple architectures (ppc, ia64, and
> s390, in addition to the existing x86), hopefully in time for the 2.6.25
> merge window. It is awkward to place the new arch support in
> drivers/kvm/, so I'd like to propose the following new layout:
>
> virt/ top-level directory for hypervisors
> virt/kvm/ kvm common code
> virt/lguest/ the other hypervisor
> arch/*/kvm/ arch dependent kvm code
> include/linux/kvm.h arch independent interface
> include/asm/kvm.h arch dependent interface
> include/linux/kvm_para.h arch independent guest interface
> include/asm/kvm_para.h arch dependent guest interface
>
> The include/ hierarchy is already in place; I'm including it for
> completeness.
For completeness, where do we want to put the drivers?
drivers/*, drivers/net/* etc.
or
drivers/kvm/* drivers/xen/* etc.
Christian?
Christian Borntraeger wrote:
> Am Dienstag, 11. Dezember 2007 schrieb Avi Kivity:
>
>> KVM is due to receive support for multiple architectures (ppc, ia64, and
>> s390, in addition to the existing x86), hopefully in time for the 2.6.25
>> merge window. It is awkward to place the new arch support in
>> drivers/kvm/, so I'd like to propose the following new layout:
>>
>> virt/ top-level directory for hypervisors
>> virt/kvm/ kvm common code
>> virt/lguest/ the other hypervisor
>> arch/*/kvm/ arch dependent kvm code
>> include/linux/kvm.h arch independent interface
>> include/asm/kvm.h arch dependent interface
>> include/linux/kvm_para.h arch independent guest interface
>> include/asm/kvm_para.h arch dependent guest interface
>>
>> The include/ hierarchy is already in place; I'm including it for
>> completeness.
>>
>
> For completeness, where do we want to put the drivers?
> drivers/*, drivers/net/* etc.
> or
> drivers/kvm/* drivers/xen/* etc.
>
There's already drivers/virtio/ for kvm. If kvm-specific drivers come
up, we can place them in drivers/kvm/.
--
error compiling committee.c: too many arguments to function
On Tue, Dec 11, 2007 at 11:47:39AM +0200, Avi Kivity wrote:
> KVM is due to receive support for multiple architectures (ppc, ia64, and
> s390, in addition to the existing x86), hopefully in time for the 2.6.25
> merge window. It is awkward to place the new arch support in drivers/kvm/,
> so I'd like to propose the following new layout:
> ...
> arch/*/kvm/ arch dependent kvm code
Maybe arch/*/virt/ ? No need to add an own directory for each hypervisor.
Heiko Carstens wrote:
> On Tue, Dec 11, 2007 at 11:47:39AM +0200, Avi Kivity wrote:
>
>> KVM is due to receive support for multiple architectures (ppc, ia64, and
>> s390, in addition to the existing x86), hopefully in time for the 2.6.25
>> merge window. It is awkward to place the new arch support in drivers/kvm/,
>> so I'd like to propose the following new layout:
>> ...
>> arch/*/kvm/ arch dependent kvm code
>>
>
> Maybe arch/*/virt/ ? No need to add an own directory for each hypervisor.
>
>
There will be several kvm files in that directory for x86. If you have
just one file, I guess arch/*/virt/kvm.c is okay.
--
error compiling committee.c: too many arguments to function
On Tue, Dec 11, 2007 at 11:47:39AM +0200, Avi Kivity wrote:
> KVM is due to receive support for multiple architectures (ppc, ia64, and
> s390, in addition to the existing x86), hopefully in time for the 2.6.25
> merge window. It is awkward to place the new arch support in
> drivers/kvm/, so I'd like to propose the following new layout:
>
> virt/ top-level directory for hypervisors
> virt/kvm/ kvm common code
> virt/lguest/ the other hypervisor
> arch/*/kvm/ arch dependent kvm code
The arch/*/dir shall use same dir-name as used
in top-level directory.
So use arch/*/virt/kvm/ if kvm really requires
a subdirectory of it own. Preferably not.
A handful of files named kvm* does not warrant their own
subdirectory IMO.
Sam
Sam Ravnborg wrote:
> On Tue, Dec 11, 2007 at 11:47:39AM +0200, Avi Kivity wrote:
>
>> KVM is due to receive support for multiple architectures (ppc, ia64, and
>> s390, in addition to the existing x86), hopefully in time for the 2.6.25
>> merge window. It is awkward to place the new arch support in
>> drivers/kvm/, so I'd like to propose the following new layout:
>>
>> virt/ top-level directory for hypervisors
>> virt/kvm/ kvm common code
>> virt/lguest/ the other hypervisor
>> arch/*/kvm/ arch dependent kvm code
>>
>
> The arch/*/dir shall use same dir-name as used
> in top-level directory.
>
Well, it isn't like that now (arch/x86/oprofile, etc.)
> So use arch/*/virt/kvm/ if kvm really requires
> a subdirectory of it own. Preferably not.
> A handful of files named kvm* does not warrant their own
> subdirectory IMO.
>
>
We'll have 5-6 x86 specific files.
Where do you suggest we place them?
--
error compiling committee.c: too many arguments to function
On Tue, Dec 11, 2007 at 06:15:40PM +0200, Avi Kivity wrote:
> Sam Ravnborg wrote:
> >On Tue, Dec 11, 2007 at 11:47:39AM +0200, Avi Kivity wrote:
> >
> >>KVM is due to receive support for multiple architectures (ppc, ia64, and
> >>s390, in addition to the existing x86), hopefully in time for the 2.6.25
> >>merge window. It is awkward to place the new arch support in
> >>drivers/kvm/, so I'd like to propose the following new layout:
> >>
> >> virt/ top-level directory for hypervisors
> >> virt/kvm/ kvm common code
> >> virt/lguest/ the other hypervisor
> >> arch/*/kvm/ arch dependent kvm code
> >>
> >
> >The arch/*/dir shall use same dir-name as used
> >in top-level directory.
> >
>
> Well, it isn't like that now (arch/x86/oprofile, etc.)
oprofile is now the best leader to follow in this respect.
Just look at the utterly crap in their makefiles.
> >So use arch/*/virt/kvm/ if kvm really requires
> >a subdirectory of it own. Preferably not.
> >A handful of files named kvm* does not warrant their own
> >subdirectory IMO.
> >
> >
>
> We'll have 5-6 x86 specific files.
>
> Where do you suggest we place them?
/arch/x86/virt/
Seems logical and fit the way we handle mm/ versus arch/*/mm,
kernel/ arch/*/kernel etc.
Are there any dependencies between the arch and non-arch files
such as they are combined in a single module?
Sam
Sam Ravnborg wrote:
>
>>> So use arch/*/virt/kvm/ if kvm really requires
>>> a subdirectory of it own. Preferably not.
>>> A handful of files named kvm* does not warrant their own
>>> subdirectory IMO.
>>>
>>>
>>>
>> We'll have 5-6 x86 specific files.
>>
>> Where do you suggest we place them?
>>
> /arch/x86/virt/
>
>
But, I want to place the arch independent files in virt/kvm/, so as to
leave room for virt/lguest/.
> Seems logical and fit the way we handle mm/ versus arch/*/mm,
> kernel/ arch/*/kernel etc.
>
Exactly, so virt/kvm/ -> arch/x86/virt/kvm/.
> Are there any dependencies between the arch and non-arch files
> such as they are combined in a single module?
>
>
Yes, they are combined into a single module.
In the case of x86, some of arch/x86/... will be combined with virt/kvm/
to form kvm.ko, while others will generate kvm-intel.ko and kvm-amd.ko.
--
error compiling committee.c: too many arguments to function
On Tue, 2007-12-11 at 19:42 +0200, Avi Kivity wrote:
>
> > Are there any dependencies between the arch and non-arch files
> > such as they are combined in a single module?
>
> Yes, they are combined into a single module.
>
> In the case of x86, some of arch/x86/... will be combined with
> virt/kvm/ to form kvm.ko, while others will generate kvm-intel.ko and
> kvm-amd.ko.
Also, asm-offsets is a major sticking point. Either we create a
dependency on arch/*/kernel/asm-offsets.c, or we find a way to create a
new arch/*/virt/asm-offsets.c file.
--
Hollis Blanchard
IBM Linux Technology Center
On Tuesday 11 December 2007, Avi Kivity wrote:
> Heiko Carstens wrote:
> > On Tue, Dec 11, 2007 at 11:47:39AM +0200, Avi Kivity wrote:
> >
> >> ?arch/*/kvm/ ? arch dependent kvm code
> >> ? ?
> >
> > Maybe arch/*/virt/ ? No need to add an own directory for each hypervisor.
> >
> There will be several kvm files in that directory for x86. If you have
> just one file, I guess arch/*/virt/kvm.c is okay.
In that case, even arch/*/{mm,kernel}/kvm.c would work fine, as long as you
only want to support one hypervisor, or a small set of small files, there
is no need to have even have a virt directory.
However, if you want to have symmetry across the architectures, I think
arch/*/kvm/ works out best, along the lines of
arch/*/{perfmon,crypto,xen,power}. Neither of these is particularly large,
but arch/* is typically not that crowded either.
Arnd <><
Arnd Bergmann wrote:
> On Tuesday 11 December 2007, Avi Kivity wrote:
>
>> Heiko Carstens wrote:
>>
>>> On Tue, Dec 11, 2007 at 11:47:39AM +0200, Avi Kivity wrote:
>>>
>>>
>>>> arch/*/kvm/ arch dependent kvm code
>>>>
>>>>
>>> Maybe arch/*/virt/ ? No need to add an own directory for each hypervisor.
>>>
>>>
>> There will be several kvm files in that directory for x86. If you have
>> just one file, I guess arch/*/virt/kvm.c is okay.
>>
>
> In that case, even arch/*/{mm,kernel}/kvm.c would work fine, as long as you
> only want to support one hypervisor, or a small set of small files, there
> is no need to have even have a virt directory.
>
> However, if you want to have symmetry across the architectures, I think
> arch/*/kvm/ works out best, along the lines of
> arch/*/{perfmon,crypto,xen,power}. Neither of these is particularly large,
> but arch/* is typically not that crowded either.
>
In the case of x86, we'll have 16 arch dependent files (i8259.[ch],
irq.[ch], lapic.c, mmu.c, paging_tmpl.[ch], svm.[ch], vmx.[ch],
x86.[ch], x86_emulate.[ch]) which warrant a kvm/ subdirectory IMO.
--
error compiling committee.c: too many arguments to function
Avi Kivity wrote:
> In the case of x86, we'll have 16 arch dependent files (i8259.[ch],
> irq.[ch], lapic.c, mmu.c, paging_tmpl.[ch], svm.[ch], vmx.[ch],
> x86.[ch], x86_emulate.[ch]) which warrant a kvm/ subdirectory IMO.
I think a subdirectory makes sense too. We'll end up with more than a
single file.