Re: [kvm-devel] [PATCH] make KVM selectable again

2008-02-10 Thread Sam Ravnborg
On Sat, Feb 09, 2008 at 10:24:01PM +0100, Ingo Molnar wrote:
 
 * Dave Hansen [EMAIL PROTECTED] wrote:
 
   config HAVE_SETUP_PER_CPU_AREA
  def_bool X86_64
   
  -select HAVE_KVM
  +config HAVE_KVM
  +   def_bool y
 
 i think it might be better to just move the select to after the config 
 X86 option. (this is a legitimate use of select) Sam, do you concur?

Correct.
We should see it used like this:

config X86
select HAVE_KVM

Sam

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] [PATCH] make KVM selectable again

2008-02-10 Thread Sam Ravnborg
Hi Dave.
 
 I've verified that arch/x86/kvm/Kconfig was getting run by putting some
 comments in it.  It seems to me like just putting:
 
   config HAVE_KVM
  bool
 
 isn't letting anything come into my .config at all.  I'm not sure why we
 do that, and then have:
 
   select HAVE_KVM
 
 in arch/x86/Kconfig.

See rationale in Documentation/kbuild/kconfig-language.txt - last chapter.
In this case the select was just placed wrongly.

Sam

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] [PATCH 21/54] KVM: Export include/linux/kvm.h only if $ARCH actually supports KVM

2008-01-01 Thread Sam Ravnborg
On Tue, Jan 01, 2008 at 05:35:47PM +0200, Avi Kivity wrote:
 Currently, make headers_check barfs due to asm/kvm.h, which linux/kvm.h
 includes, not existing.  Rather than add a zillion asm/kvm.hs, export kvm.h
 only if the arch actually supports it.
 
 Signed-off-by: Avi Kivity [EMAIL PROTECTED]
 ---
  arch/x86/Kconfig |4 
  drivers/kvm/Kconfig  |4 ++--
  include/linux/Kbuild |2 +-
  3 files changed, 7 insertions(+), 3 deletions(-)
 
 diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
 index 80b7ba4..e029a93 100644
 --- a/arch/x86/Kconfig
 +++ b/arch/x86/Kconfig
 @@ -116,6 +116,10 @@ config ARCH_SUPPORTS_OPROFILE
   bool
   default y
  
 +config ARCH_SUPPORTS_KVM
 + bool
 + default y
 +
  
  config ZONE_DMA32
   bool
 diff --git a/drivers/kvm/Kconfig b/drivers/kvm/Kconfig
 index 6569206..4086080 100644
 --- a/drivers/kvm/Kconfig
 +++ b/drivers/kvm/Kconfig
 @@ -3,7 +3,7 @@
  #
  menuconfig VIRTUALIZATION
   bool Virtualization
 - depends on X86
 + depends on ARCH_SUPPORTS_KVM || X86
   default y
   ---help---
 Say Y here to get to see options for using your Linux host to run 
 other
 @@ -16,7 +16,7 @@ if VIRTUALIZATION
  
  config KVM
   tristate Kernel-based Virtual Machine (KVM) support
 - depends on X86  EXPERIMENTAL
 + depends on ARCH_SUPPORTS_KVM  EXPERIMENTAL
   select PREEMPT_NOTIFIERS
   select ANON_INODES
   ---help---

An approach like the following is preferred:
kvm/Kconfig:

# config symbols to be selected by archs that implment virtualization/kvm
config HAVE_VIRTUALIZATION
config HAVE_KVM

menuconfig VIRTUALIZATION
bool ...
depends on HAVE_VIRTUALIZATION

config KVM
tristate ...
depends on HAVE_KVM

arch/x86/Kconfig:

config X86
select HAVE_VIRTUALIZATION
select HAVE_KVM


I dunno about the additional HAVE_VIRTUALIZATION - I added it
because I assume virtualization is more than just kvm.

The rationales behinds this approach is:

- We do not define a new config variable for each arch
- We have a common way to say that an arch supports a feature
- We have a common naming scheme


Sam

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] [PATCH 00/55] KVM patch queue review for 2.6.25 merge window (part II)

2007-12-26 Thread Sam Ravnborg
On Wed, Dec 26, 2007 at 01:05:05PM +0200, Avi Kivity wrote:
 The second 2.6.25 kvm patch series, for your review.  Three more to go.

Hi Avi.

A diffstat in your introduction mail would be nice so one does not
have to check 50+ patches to see if it touches any file I can give
feedback on.

Sam

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] [RFC] Proposed new directory layout for kvm and virtualization

2007-12-11 Thread Sam Ravnborg
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

-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] [RFC] Proposed new directory layout for kvm and virtualization

2007-12-11 Thread Sam Ravnborg
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

-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


Re: [kvm-devel] [RFC] KVM Source layout Proposal to accommodate new CPU architecture

2007-09-29 Thread Sam Ravnborg
Hi Rusty.

On Sat, Sep 29, 2007 at 11:06:51PM +1000, Rusty Russell wrote:
 On Thu, 2007-09-27 at 11:18 +0200, Avi Kivity wrote:
  The whole drivers/kvm/ thing was just a trick to get merged quickly.  I
  think the new layout should be something like
  
virt/kvm/, include/linux/kvm*.h - common code
virt/lguest/ - the other hypervisor
virt/virtio/ - shared I/O infrastructure
virt/ - the CONFIG_VIRTIALIZATION menu
arch/x86/kvm/, include/asm-x86/ - x86 specific code
arch/ia64/kvm/, include/asm-ia64/ - ia64 specific code
 
 The problem with this separation is that module source cannot span
 directories (at least, not that I could find).

That's supported but not in the most elegant fashion.
In your Makefile in the top-level directory
just specify the relevant .o files in the subdirectories.
So you would have:
lguest-y := file.o
lguest-y += dir/foo.o
lguest-y += dir2/bar.o

obj-$(CONFIG_...) := lguset.o

If you have trouble making this work drop me a mail and I
will try to help with a more specific example.

Sam

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel