[RFC PATCH 00/16] kvm tools: add support for ARMv7 processors

[RFC PATCH 00/16] kvm tools: add support for ARMv7 processors

[Will Deacon]

Hello,

This patch series adds support for ARMv7 processors (Cortex-A15) to kvm
tool. The majority of the series consists of small changes in
preparation for ARM support, which is added by the final patch. I can
try to split this up further, but given that there is no current support
for ARM, the sub-patches wouldn't be especially meaningful.

To boot a guest, you will need:

  - A Cortex-A15 platform with a kvm-capable bootloader
  - The latest kvm-arm patches:
    git://github.com/virtualopensystems/linux-kvm-arm.git kvm-arm-master
  - A guest kernel configured for our virtual target:
    git://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git kvm/mach-virt

I'm also working on an ARMv8 (AArch64) port which fits neatly into the
code presented here.

All feedback welcome,

Will


Will Deacon (16):
  kvm tools: include arch uapi/asm directories in include path
  kvm tools: only enable LTO if supported by GCC
  kvm tools: avoid linking dynamically against libbfd
  kvm tools: specify compiler by name when overriding make default
  kvm tools: don't bother including linux/compiler.h
  kvm tools: don't pass -Wcast-align to the compiler
  kvm tools: die if init_list__init returns failure
  kvm tools: add generic device registration mechanism
  kvm tools: make _FDT macro usable by other architectures
  kvm tools: virtio-mmio: use subsys_id instead of pci device ID
  kvm tools: virtio: add dummy set_size_vq implementations
  kvm tools: allow arch to specify default virtio transport
  kvm tools: keep track of registered memory banks in struct kvm
  kvm tools: teach guest_flat_to_host about memory banks starting above
    0
  kvm tools: provide a mechanism for translating host to guest
    addresses
  kvm tools: add support for ARMv7 processors

 tools/kvm/Makefile                           |   38 +++-
 tools/kvm/arm/aarch32/cortex-a15.c           |   98 ++++++++++
 tools/kvm/arm/aarch32/include/kvm/barrier.h  |   10 +
 tools/kvm/arm/aarch32/include/kvm/kvm-arch.h |   28 +++
 tools/kvm/arm/aarch32/kvm-cpu.c              |  111 +++++++++++
 tools/kvm/arm/aarch32/smp-pen.S              |   14 ++
 tools/kvm/arm/fdt.c                          |  269 ++++++++++++++++++++++++++
 tools/kvm/arm/gic.c                          |   86 ++++++++
 tools/kvm/arm/include/arm-common/gic.h       |   29 +++
 tools/kvm/arm/include/arm-common/kvm-arch.h  |   31 +++
 tools/kvm/arm/include/arm-common/smp.h       |    7 +
 tools/kvm/arm/include/kvm/kvm-cpu-arch.h     |   47 +++++
 tools/kvm/arm/ioport.c                       |    5 +
 tools/kvm/arm/irq.c                          |   25 +++
 tools/kvm/arm/kvm-cpu.c                      |  112 +++++++++++
 tools/kvm/arm/kvm.c                          |   69 +++++++
 tools/kvm/arm/smp.c                          |   13 ++
 tools/kvm/builtin-run.c                      |    3 +-
 tools/kvm/devices.c                          |   24 +++
 tools/kvm/hw/pci-shmem.c                     |    8 +-
 tools/kvm/hw/vesa.c                          |    8 +-
 tools/kvm/include/kvm/devices.h              |   21 ++
 tools/kvm/include/kvm/fdt.h                  |   26 +++
 tools/kvm/include/kvm/kvm.h                  |   16 +-
 tools/kvm/include/kvm/pci.h                  |    2 -
 tools/kvm/include/kvm/virtio-mmio.h          |    1 +
 tools/kvm/include/kvm/virtio-pci.h           |    2 +
 tools/kvm/include/linux/stddef.h             |    6 -
 tools/kvm/kvm.c                              |   55 +++++-
 tools/kvm/pci.c                              |   40 ++---
 tools/kvm/powerpc/include/kvm/kvm-arch.h     |   13 +-
 tools/kvm/powerpc/irq.c                      |    3 +-
 tools/kvm/powerpc/kvm.c                      |    2 +-
 tools/kvm/powerpc/spapr_pci.c                |    4 +-
 tools/kvm/virtio/9p.c                        |   10 +-
 tools/kvm/virtio/balloon.c                   |    3 +-
 tools/kvm/virtio/blk.c                       |    3 +-
 tools/kvm/virtio/console.c                   |   10 +-
 tools/kvm/virtio/mmio.c                      |    9 +-
 tools/kvm/virtio/pci.c                       |    7 +-
 tools/kvm/virtio/rng.c                       |   10 +-
 tools/kvm/virtio/scsi.c                      |    3 +-
 tools/kvm/x86/include/kvm/kvm-arch.h         |   11 +-
 tools/kvm/x86/kvm.c                          |    7 +
 44 files changed, 1214 insertions(+), 85 deletions(-)
 create mode 100644 tools/kvm/arm/aarch32/cortex-a15.c
 create mode 100644 tools/kvm/arm/aarch32/include/kvm/barrier.h
 create mode 100644 tools/kvm/arm/aarch32/include/kvm/kvm-arch.h
 create mode 100644 tools/kvm/arm/aarch32/kvm-cpu.c
 create mode 100644 tools/kvm/arm/aarch32/smp-pen.S
 create mode 100644 tools/kvm/arm/fdt.c
 create mode 100644 tools/kvm/arm/gic.c
 create mode 100644 tools/kvm/arm/include/arm-common/gic.h
 create mode 100644 tools/kvm/arm/include/arm-common/kvm-arch.h
 create mode 100644 tools/kvm/arm/include/arm-common/smp.h
 create mode 100644 tools/kvm/arm/include/kvm/kvm-cpu-arch.h
 create mode 100644 tools/kvm/arm/ioport.c
 create mode 100644 tools/kvm/arm/irq.c
 create mode 100644 tools/kvm/arm/kvm-cpu.c
 create mode 100644 tools/kvm/arm/kvm.c
 create mode 100644 tools/kvm/arm/smp.c
 create mode 100644 tools/kvm/devices.c
 create mode 100644 tools/kvm/include/kvm/devices.h
 create mode 100644 tools/kvm/include/kvm/fdt.h

-- 
1.7.4.1

[RFC PATCH 01/16] kvm tools: include arch uapi/asm directories in include path

[Will Deacon]

Architectures such as ARM and powerpc place asm/kvm.h under
arch/$ARCH/include/uapi/asm, so ensure that this is part of the C
include path.

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 tools/kvm/Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/kvm/Makefile b/tools/kvm/Makefile
index 64f2646..f12e587 100644
--- a/tools/kvm/Makefile
+++ b/tools/kvm/Makefile
@@ -244,7 +244,7 @@ DEFINES	+= -DKVMTOOLS_VERSION='"$(KVMTOOLS_VERSION)"'
 DEFINES	+= -DBUILD_ARCH='"$(ARCH)"'
 
 KVM_INCLUDE := include
-CFLAGS	+= $(CPPFLAGS) $(DEFINES) -I$(KVM_INCLUDE) -I$(ARCH_INCLUDE) -I$(KINCL_PATH)/include/uapi -I$(KINCL_PATH)/include -I$(KINCL_PATH)/arch/$(ARCH)/include/ -O2 -fno-strict-aliasing -g -flto
+CFLAGS	+= $(CPPFLAGS) $(DEFINES) -I$(KVM_INCLUDE) -I$(ARCH_INCLUDE) -I$(KINCL_PATH)/include/uapi -I$(KINCL_PATH)/include -I$(KINCL_PATH)/arch/$(ARCH)/include/uapi -I$(KINCL_PATH)/arch/$(ARCH)/include/ -O2 -fno-strict-aliasing -g -flto
 
 WARNINGS += -Wall
 WARNINGS += -Wcast-align
-- 
1.7.4.1

[RFC PATCH 02/16] kvm tools: only enable LTO if supported by GCC

[Will Deacon]

Commit 99423f12db2a ("kvm tools: enable LTO") unconditionally enabled
link-time-optimisations when building kvmtool. Unfortunately, passing
-flto to a GCC without support for the option, results in a fatal build
error:

  cc1: error: LTO support has not been enabled in this configuration

This patch adds a check to the kvm tools Makefile so that LTO is only
enabled if the host compiler supports it.

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 tools/kvm/Makefile |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/tools/kvm/Makefile b/tools/kvm/Makefile
index f12e587..23a7c40 100644
--- a/tools/kvm/Makefile
+++ b/tools/kvm/Makefile
@@ -226,6 +226,11 @@ ifeq ($(call try-cc,$(SOURCE_AIO),$(FLAGS_AIO) -static),y)
 	LIBS_STATOPT	+= -laio
 endif
 
+FLAGS_LTO := -flto
+ifeq ($(call try-cc,$(SOURCE_HELLO),$(FLAGS_LTO)),y)
+	CFLAGS		+= $(FLAGS_LTO)
+endif
+
 ifneq ($(call try-build,$(SOURCE_STATIC),-static,),y)
 $(error No static libc found. Please install glibc-static package.)
 endif
@@ -244,7 +249,7 @@ DEFINES	+= -DKVMTOOLS_VERSION='"$(KVMTOOLS_VERSION)"'
 DEFINES	+= -DBUILD_ARCH='"$(ARCH)"'
 
 KVM_INCLUDE := include
-CFLAGS	+= $(CPPFLAGS) $(DEFINES) -I$(KVM_INCLUDE) -I$(ARCH_INCLUDE) -I$(KINCL_PATH)/include/uapi -I$(KINCL_PATH)/include -I$(KINCL_PATH)/arch/$(ARCH)/include/uapi -I$(KINCL_PATH)/arch/$(ARCH)/include/ -O2 -fno-strict-aliasing -g -flto
+CFLAGS	+= $(CPPFLAGS) $(DEFINES) -I$(KVM_INCLUDE) -I$(ARCH_INCLUDE) -I$(KINCL_PATH)/include/uapi -I$(KINCL_PATH)/include -I$(KINCL_PATH)/arch/$(ARCH)/include/uapi -I$(KINCL_PATH)/arch/$(ARCH)/include/ -O2 -fno-strict-aliasing -g
 
 WARNINGS += -Wall
 WARNINGS += -Wcast-align
-- 
1.7.4.1

[RFC PATCH 03/16] kvm tools: avoid linking dynamically against libbfd

[Will Deacon]

Linking dynamically against libbfd results in a non-portable application
binary and is generally frowned upon by distributions: Debian forbids it
explicitly and on Gentoo, it results in a failure at run-time:

  ./lkvm: error while loading shared libraries: libbfd-2.22.so: cannot
  open shared object file: No such file or directory

Avoid these problems by linking statically instead.

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 tools/kvm/Makefile |    5 -----
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/tools/kvm/Makefile b/tools/kvm/Makefile
index 23a7c40..44a55c2 100644
--- a/tools/kvm/Makefile
+++ b/tools/kvm/Makefile
@@ -171,11 +171,6 @@ endif
 # both and only build those that link!
 
 FLAGS_BFD := $(CFLAGS) -lbfd
-ifeq ($(call try-cc,$(SOURCE_BFD),$(FLAGS_BFD)),y)
-	CFLAGS_DYNOPT	+= -DCONFIG_HAS_BFD
-	OBJS_DYNOPT	+= symbol.o
-	LIBS_DYNOPT	+= -lbfd
-endif
 ifeq ($(call try-cc,$(SOURCE_BFD),$(FLAGS_BFD) -static),y)
 	CFLAGS_STATOPT	+= -DCONFIG_HAS_BFD
 	OBJS_STATOPT	+= symbol.o
-- 
1.7.4.1

[RFC PATCH 04/16] kvm tools: specify compiler by name when overriding make default

[Will Deacon]

GNU make defaults "$(CC)" to "cc", which breaks compilation when we try
to execute $(CROSS_COMPILE)-cc.

This patch copies what the top-level kernel Makefile does, by specifying
"gcc" directly when overriding the $CC environment variable.

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 tools/kvm/Makefile |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/kvm/Makefile b/tools/kvm/Makefile
index 44a55c2..bb22587 100644
--- a/tools/kvm/Makefile
+++ b/tools/kvm/Makefile
@@ -19,8 +19,8 @@ export E Q KINCL_PATH
 include config/utilities.mak
 include config/feature-tests.mak
 
-CC	:= $(CROSS_COMPILE)$(CC)
-LD	:= $(CROSS_COMPILE)$(LD)
+CC	:= $(CROSS_COMPILE)gcc
+LD	:= $(CROSS_COMPILE)ld
 
 FIND	:= find
 CSCOPE	:= cscope
-- 
1.7.4.1

[RFC PATCH 05/16] kvm tools: don't bother including linux/compiler.h

[Will Deacon]

linux/compiler.h will never give us a definition for __compiler_offsetof
because __KERNEL__ isn't defined, so just use the simple definition that
we have already.

This patch removes the redundant code.

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 tools/kvm/include/linux/stddef.h |    6 ------
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/tools/kvm/include/linux/stddef.h b/tools/kvm/include/linux/stddef.h
index 60ea512..39da808 100644
--- a/tools/kvm/include/linux/stddef.h
+++ b/tools/kvm/include/linux/stddef.h
@@ -1,16 +1,10 @@
 #ifndef _LINUX_STDDEF_H
 #define _LINUX_STDDEF_H
 
-#include <linux/compiler.h>
-
 #undef NULL
 #define NULL ((void *)0)
 
 #undef offsetof
-#ifdef __compiler_offsetof
-#define offsetof(TYPE,MEMBER) __compiler_offsetof(TYPE,MEMBER)
-#else
 #define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
-#endif
 
 #endif
-- 
1.7.4.1

Re: [RFC PATCH 05/16] kvm tools: don't bother including linux/compiler.h

[Pekka Enberg]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1761 bytes --]

On Mon, 12 Nov 2012, Will Deacon wrote:

> linux/compiler.h will never give us a definition for __compiler_offsetof
> because __KERNEL__ isn't defined, so just use the simple definition that
> we have already.
> 
> This patch removes the redundant code.
> 
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
>  tools/kvm/include/linux/stddef.h |    6 ------
>  1 files changed, 0 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/kvm/include/linux/stddef.h b/tools/kvm/include/linux/stddef.h
> index 60ea512..39da808 100644
> --- a/tools/kvm/include/linux/stddef.h
> +++ b/tools/kvm/include/linux/stddef.h
> @@ -1,16 +1,10 @@
>  #ifndef _LINUX_STDDEF_H
>  #define _LINUX_STDDEF_H
>  
> -#include <linux/compiler.h>
> -
>  #undef NULL
>  #define NULL ((void *)0)
>  
>  #undef offsetof
> -#ifdef __compiler_offsetof
> -#define offsetof(TYPE,MEMBER) __compiler_offsetof(TYPE,MEMBER)
> -#else
>  #define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
> -#endif
>  
>  #endif

I'm seeing the following breakage with this patch applied:

[penberg@tux kvm]$ make
  CC       hw/rtc.o
  CC       ioport.o
  CC       kvm-cpu.o
  CC       kvm.o
In file included from include/kvm/rbtree-interval.h:4:0,
                 from include/kvm/ioport.h:4,
                 from hw/rtc.c:3:
../../include/linux/rbtree_augmented.h:125:24: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘void’
In file included from include/kvm/rbtree-interval.h:4:0,
                 from include/kvm/ioport.h:4,
                 from ioport.c:1:
../../include/linux/rbtree_augmented.h:125:24: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘void’
make: *** [hw/rtc.o] Error 1
make: *** Waiting for unfinished jobs....
make: *** [ioport.o] Error 1

Re: [RFC PATCH 05/16] kvm tools: don't bother including linux/compiler.h

[Will Deacon]

[ apologies if you receive this twice -- my email is playing up ]

Hi Pekka,

On Tue, Nov 13, 2012 at 07:26:36AM +0000, Pekka Enberg wrote:
> On Mon, 12 Nov 2012, Will Deacon wrote:
> > diff --git a/tools/kvm/include/linux/stddef.h b/tools/kvm/include/linux/stddef.h
> > index 60ea512..39da808 100644
> > --- a/tools/kvm/include/linux/stddef.h
> > +++ b/tools/kvm/include/linux/stddef.h
> > @@ -1,16 +1,10 @@
> >  #ifndef _LINUX_STDDEF_H
> >  #define _LINUX_STDDEF_H
> >  
> > -#include <linux/compiler.h>
> > -
> >  #undef NULL
> >  #define NULL ((void *)0)
> >  
> >  #undef offsetof
> > -#ifdef __compiler_offsetof
> > -#define offsetof(TYPE,MEMBER) __compiler_offsetof(TYPE,MEMBER)
> > -#else
> >  #define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
> > -#endif
> >  
> >  #endif
> 
> I'm seeing the following breakage with this patch applied:
> 
> [penberg@tux kvm]$ make
>   CC       hw/rtc.o
>   CC       ioport.o
>   CC       kvm-cpu.o
>   CC       kvm.o
> In file included from include/kvm/rbtree-interval.h:4:0,
>                  from include/kvm/ioport.h:4,
>                  from hw/rtc.c:3:
> ../../include/linux/rbtree_augmented.h:125:24: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘void’
> In file included from include/kvm/rbtree-interval.h:4:0,
>                  from include/kvm/ioport.h:4,
>                  from ioport.c:1:
> ../../include/linux/rbtree_augmented.h:125:24: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘void’
> make: *** [hw/rtc.o] Error 1
> make: *** Waiting for unfinished jobs....
> make: *** [ioport.o] Error 1

I'm struggling to reproduce this with my tree. Can you confirm whether or
not you have commit 29fc7c5a4f51 ("rbtree: include linux/compiler.h for
definition of __always_inline") in your *kernel* sources please?

Cheers,

Will

Re: [RFC PATCH 05/16] kvm tools: don't bother including linux/compiler.h

[Pekka Enberg]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1221 bytes --]

On Fri, 16 Nov 2012, Will Deacon wrote:
> > I'm seeing the following breakage with this patch applied:
> > 
> > [penberg@tux kvm]$ make
> >   CC       hw/rtc.o
> >   CC       ioport.o
> >   CC       kvm-cpu.o
> >   CC       kvm.o
> > In file included from include/kvm/rbtree-interval.h:4:0,
> >                  from include/kvm/ioport.h:4,
> >                  from hw/rtc.c:3:
> > ../../include/linux/rbtree_augmented.h:125:24: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘void’
> > In file included from include/kvm/rbtree-interval.h:4:0,
> >                  from include/kvm/ioport.h:4,
> >                  from ioport.c:1:
> > ../../include/linux/rbtree_augmented.h:125:24: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘void’
> > make: *** [hw/rtc.o] Error 1
> > make: *** Waiting for unfinished jobs....
> > make: *** [ioport.o] Error 1
> 
> I'm struggling to reproduce this with my tree. Can you confirm whether or
> not you have commit 29fc7c5a4f51 ("rbtree: include linux/compiler.h for
> definition of __always_inline") in your *kernel* sources please?

No, I don't. I can cherry-pick that to my tree if necessary.

			Pekka

Re: [RFC PATCH 05/16] kvm tools: don't bother including linux/compiler.h

[Will Deacon]

On Fri, Nov 16, 2012 at 10:01:01PM +0000, Pekka Enberg wrote:
> On Fri, 16 Nov 2012, Will Deacon wrote:
> > > I'm seeing the following breakage with this patch applied:
> > > 
> > > [penberg@tux kvm]$ make
> > >   CC       hw/rtc.o
> > >   CC       ioport.o
> > >   CC       kvm-cpu.o
> > >   CC       kvm.o
> > > In file included from include/kvm/rbtree-interval.h:4:0,
> > >                  from include/kvm/ioport.h:4,
> > >                  from hw/rtc.c:3:
> > > ../../include/linux/rbtree_augmented.h:125:24: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘void’
> > > In file included from include/kvm/rbtree-interval.h:4:0,
> > >                  from include/kvm/ioport.h:4,
> > >                  from ioport.c:1:
> > > ../../include/linux/rbtree_augmented.h:125:24: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘void’
> > > make: *** [hw/rtc.o] Error 1
> > > make: *** Waiting for unfinished jobs....
> > > make: *** [ioport.o] Error 1
> > 
> > I'm struggling to reproduce this with my tree. Can you confirm whether or
> > not you have commit 29fc7c5a4f51 ("rbtree: include linux/compiler.h for
> > definition of __always_inline") in your *kernel* sources please?
> 
> No, I don't. I can cherry-pick that to my tree if necessary.

Aha, that's probably the issue then since you won't have a definition of
__always_inline from linux/compiler.h. If you cherry-pick that patch, then
this one should work as intended. If you prefer, I can include that patch
in v2 of my series.

Cheers,

Will

Re: [RFC PATCH 05/16] kvm tools: don't bother including linux/compiler.h

[Pekka Enberg]

Hi Will,

On Mon, 19 Nov 2012, Will Deacon wrote:
> > > I'm struggling to reproduce this with my tree. Can you confirm whether or
> > > not you have commit 29fc7c5a4f51 ("rbtree: include linux/compiler.h for
> > > definition of __always_inline") in your *kernel* sources please?
> > 
> > No, I don't. I can cherry-pick that to my tree if necessary.
> 
> Aha, that's probably the issue then since you won't have a definition of
> __always_inline from linux/compiler.h. If you cherry-pick that patch, then
> this one should work as intended. If you prefer, I can include that patch
> in v2 of my series.

Please just include the patch in your series.

			Pekka

[RFC PATCH 06/16] kvm tools: don't pass -Wcast-align to the compiler

[Will Deacon]

GCC 4.7 with -Wcast-align will warn for code like the following:

	bar = (struct foo *)(char *)(0);

which is exactly the sort of code generated by container_of. In
combination with -Werror, this breaks the build.

This patch removes the option from the kvmtool Makefile.

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 tools/kvm/Makefile |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/tools/kvm/Makefile b/tools/kvm/Makefile
index bb22587..c105de1 100644
--- a/tools/kvm/Makefile
+++ b/tools/kvm/Makefile
@@ -247,7 +247,6 @@ KVM_INCLUDE := include
 CFLAGS	+= $(CPPFLAGS) $(DEFINES) -I$(KVM_INCLUDE) -I$(ARCH_INCLUDE) -I$(KINCL_PATH)/include/uapi -I$(KINCL_PATH)/include -I$(KINCL_PATH)/arch/$(ARCH)/include/uapi -I$(KINCL_PATH)/arch/$(ARCH)/include/ -O2 -fno-strict-aliasing -g
 
 WARNINGS += -Wall
-WARNINGS += -Wcast-align
 WARNINGS += -Wformat=2
 WARNINGS += -Winit-self
 WARNINGS += -Wmissing-declarations
-- 
1.7.4.1

[RFC PATCH 07/16] kvm tools: die if init_list__init returns failure

[Will Deacon]

If init_list__init returns failure when initialising kvm tool, we can't
rely on our structures being fully initialised, so die rather than try
to continue and fail gracefully later on.

This prevents a SEGV when kvm is not available on the host:

  Error: '/dev/kvm' not found. Please make sure your kernel has CONFIG_KVM enabled and that the KVM modules are loaded.
  Warning: Failed init: kvm__init

Segmentation fault

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 tools/kvm/builtin-run.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/tools/kvm/builtin-run.c b/tools/kvm/builtin-run.c
index dec2e74..96e68af 100644
--- a/tools/kvm/builtin-run.c
+++ b/tools/kvm/builtin-run.c
@@ -665,7 +665,8 @@ static struct kvm *kvm_cmd_run_init(int argc, const char **argv)
 	printf("  # %s run -k %s -m %Lu -c %d --name %s\n", KVM_BINARY_NAME,
 		kvm->cfg.kernel_filename, kvm->cfg.ram_size / 1024 / 1024, kvm->cfg.nrcpus, kvm->cfg.guest_name);
 
-	init_list__init(kvm);
+	if (init_list__init(kvm) < 0)
+		die ("Initialisation failed");
 
 	return kvm;
 }
-- 
1.7.4.1

[RFC PATCH 08/16] kvm tools: add generic device registration mechanism

[Will Deacon]

PCI devices are currently registered into the pci_devices array via the
pci__register function, which can then be indexed later by architecture
code to construct device tree nodes. For MMIO devices, there is no such
utility.

Rather than invent a similar mechanism for MMIO, this patch creates a
global device registration mechanism, which allows the device type to be
specified when registered or indexing a device. Current users of the pci
registration code are migrated to the new infrastructure and virtio MMIO
devices are registered at init time.

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 tools/kvm/Makefile                  |    1 +
 tools/kvm/devices.c                 |   24 +++++++++++++++++++++
 tools/kvm/hw/pci-shmem.c            |    8 ++++++-
 tools/kvm/hw/vesa.c                 |    8 ++++++-
 tools/kvm/include/kvm/devices.h     |   21 ++++++++++++++++++
 tools/kvm/include/kvm/pci.h         |    2 -
 tools/kvm/include/kvm/virtio-mmio.h |    1 +
 tools/kvm/include/kvm/virtio-pci.h  |    2 +
 tools/kvm/pci.c                     |   40 ++++++++++++----------------------
 tools/kvm/powerpc/irq.c             |    3 +-
 tools/kvm/powerpc/spapr_pci.c       |    2 +-
 tools/kvm/virtio/mmio.c             |    7 ++++++
 tools/kvm/virtio/pci.c              |    7 +++++-
 13 files changed, 93 insertions(+), 33 deletions(-)
 create mode 100644 tools/kvm/devices.c
 create mode 100644 tools/kvm/include/kvm/devices.h

diff --git a/tools/kvm/Makefile b/tools/kvm/Makefile
index c105de1..5da416f 100644
--- a/tools/kvm/Makefile
+++ b/tools/kvm/Makefile
@@ -50,6 +50,7 @@ OBJS	+= builtin-run.o
 OBJS	+= builtin-setup.o
 OBJS	+= builtin-stop.o
 OBJS	+= builtin-version.o
+OBJS	+= devices.o
 OBJS	+= disk/core.o
 OBJS	+= framebuffer.o
 OBJS	+= guest_compat.o
diff --git a/tools/kvm/devices.c b/tools/kvm/devices.c
new file mode 100644
index 0000000..f9666b9
--- /dev/null
+++ b/tools/kvm/devices.c
@@ -0,0 +1,24 @@
+#include "kvm/devices.h"
+#include "kvm/kvm.h"
+
+#include <linux/err.h>
+
+static struct device_header *devices[KVM_MAX_DEVICES];
+
+int device__register(struct device_header *dev, u8 dev_num)
+{
+	if (dev_num >= KVM_MAX_DEVICES)
+		return -ENOSPC;
+
+	devices[dev_num] = dev;
+
+	return 0;
+}
+
+struct device_header *device__find_dev(u8 dev_num)
+{
+	if (dev_num >= KVM_MAX_DEVICES)
+		return ERR_PTR(-EOVERFLOW);
+
+	return devices[dev_num];
+}
diff --git a/tools/kvm/hw/pci-shmem.c b/tools/kvm/hw/pci-shmem.c
index 4161335..f06c013 100644
--- a/tools/kvm/hw/pci-shmem.c
+++ b/tools/kvm/hw/pci-shmem.c
@@ -1,3 +1,4 @@
+#include "kvm/devices.h"
 #include "kvm/pci-shmem.h"
 #include "kvm/virtio-pci-dev.h"
 #include "kvm/irq.h"
@@ -30,6 +31,11 @@ static struct pci_device_header pci_shmem_pci_device = {
 	.msix.pba_offset = cpu_to_le32(0x1001),		/* Use BAR 1 */
 };
 
+static struct device_header pci_shmem_device = {
+	.bus_type	= DEVICE_BUS_PCI,
+	.data		= &pci_shmem_pci_device,
+};
+
 /* registers for the Inter-VM shared memory device */
 enum ivshmem_registers {
 	INTRMASK = 0,
@@ -384,7 +390,7 @@ int pci_shmem__init(struct kvm *kvm)
 	pci_shmem_pci_device.bar[2] = cpu_to_le32(shmem_region->phys_addr | PCI_BASE_ADDRESS_SPACE_MEMORY);
 	pci_shmem_pci_device.bar_size[2] = shmem_region->size;
 
-	pci__register(&pci_shmem_pci_device, dev);
+	device__register(&pci_shmem_device, dev);
 
 	/* Open shared memory and plug it into the guest */
 	mem = setup_shmem(shmem_region->handle, shmem_region->size,
diff --git a/tools/kvm/hw/vesa.c b/tools/kvm/hw/vesa.c
index a211491..630d8c9 100644
--- a/tools/kvm/hw/vesa.c
+++ b/tools/kvm/hw/vesa.c
@@ -1,5 +1,6 @@
 #include "kvm/vesa.h"
 
+#include "kvm/devices.h"
 #include "kvm/virtio-pci-dev.h"
 #include "kvm/framebuffer.h"
 #include "kvm/kvm-cpu.h"
@@ -44,6 +45,11 @@ static struct pci_device_header vesa_pci_device = {
 	.bar_size[1]		= VESA_MEM_SIZE,
 };
 
+static struct device_header vesa_device = {
+	.bus_type	= DEVICE_BUS_PCI,
+	.data		= &vesa_pci_device,
+};
+
 static struct framebuffer vesafb;
 
 struct framebuffer *vesa__init(struct kvm *kvm)
@@ -68,7 +74,7 @@ struct framebuffer *vesa__init(struct kvm *kvm)
 	vesa_pci_device.irq_line	= line;
 	vesa_base_addr			= (u16)r;
 	vesa_pci_device.bar[0]		= cpu_to_le32(vesa_base_addr | PCI_BASE_ADDRESS_SPACE_IO);
-	pci__register(&vesa_pci_device, dev);
+	device__register(&vesa_device, dev);
 
 	mem = mmap(NULL, VESA_MEM_SIZE, PROT_RW, MAP_ANON_NORESERVE, -1, 0);
 	if (mem == MAP_FAILED)
diff --git a/tools/kvm/include/kvm/devices.h b/tools/kvm/include/kvm/devices.h
new file mode 100644
index 0000000..3546904
--- /dev/null
+++ b/tools/kvm/include/kvm/devices.h
@@ -0,0 +1,21 @@
+#ifndef KVM__DEVICES_H
+#define KVM__DEVICES_H
+
+#include <linux/types.h>
+
+#define KVM_MAX_DEVICES	256
+
+enum device_bus_type {
+	DEVICE_BUS_PCI,
+	DEVICE_BUS_MMIO,
+};
+
+struct device_header {
+	enum device_bus_type	bus_type;
+	void			*data;
+};
+
+int device__register(struct device_header *dev, u8 dev_num);
+struct device_header *device__find_dev(u8 dev_num);
+
+#endif /* KVM__DEVICES_H */
diff --git a/tools/kvm/include/kvm/pci.h b/tools/kvm/include/kvm/pci.h
index 26639b5..3da3811 100644
--- a/tools/kvm/include/kvm/pci.h
+++ b/tools/kvm/include/kvm/pci.h
@@ -9,7 +9,6 @@
 #include "kvm/kvm.h"
 #include "kvm/msi.h"
 
-#define PCI_MAX_DEVICES		256
 /*
  * PCI Configuration Mechanism #1 I/O ports. See Section 3.7.4.1.
  * ("Configuration Mechanism #1") of the PCI Local Bus Specification 2.1 for
@@ -86,7 +85,6 @@ struct pci_device_header {
 
 int pci__init(struct kvm *kvm);
 int pci__exit(struct kvm *kvm);
-int pci__register(struct pci_device_header *dev, u8 dev_num);
 struct pci_device_header *pci__find_dev(u8 dev_num);
 u32 pci_get_io_space_block(u32 size);
 void pci__config_wr(struct kvm *kvm, union pci_config_address addr, void *data, int size);
diff --git a/tools/kvm/include/kvm/virtio-mmio.h b/tools/kvm/include/kvm/virtio-mmio.h
index e0ede3c..983c8fc 100644
--- a/tools/kvm/include/kvm/virtio-mmio.h
+++ b/tools/kvm/include/kvm/virtio-mmio.h
@@ -47,6 +47,7 @@ struct virtio_mmio {
 	struct kvm		*kvm;
 	u8			irq;
 	struct virtio_mmio_hdr	hdr;
+	struct device_header	dev_hdr;
 	struct virtio_mmio_ioevent_param ioeventfds[VIRTIO_MMIO_MAX_VQ];
 };
 
diff --git a/tools/kvm/include/kvm/virtio-pci.h b/tools/kvm/include/kvm/virtio-pci.h
index 44130e0c..6d9a558 100644
--- a/tools/kvm/include/kvm/virtio-pci.h
+++ b/tools/kvm/include/kvm/virtio-pci.h
@@ -1,6 +1,7 @@
 #ifndef KVM__VIRTIO_PCI_H
 #define KVM__VIRTIO_PCI_H
 
+#include "kvm/devices.h"
 #include "kvm/pci.h"
 
 #include <linux/types.h>
@@ -19,6 +20,7 @@ struct virtio_pci_ioevent_param {
 
 struct virtio_pci {
 	struct pci_device_header pci_hdr;
+	struct device_header	dev_hdr;
 	void			*dev;
 
 	u16			base_addr;
diff --git a/tools/kvm/pci.c b/tools/kvm/pci.c
index c77d3cc..0c70343 100644
--- a/tools/kvm/pci.c
+++ b/tools/kvm/pci.c
@@ -1,3 +1,4 @@
+#include "kvm/devices.h"
 #include "kvm/pci.h"
 #include "kvm/ioport.h"
 #include "kvm/util.h"
@@ -8,8 +9,6 @@
 
 #define PCI_BAR_OFFSET(b)		(offsetof(struct pci_device_header, bar[b]))
 
-static struct pci_device_header		*pci_devices[PCI_MAX_DEVICES];
-
 static union pci_config_address		pci_config_address;
 
 /* This is within our PCI gap - in an unused area.
@@ -63,7 +62,7 @@ static struct ioport_operations pci_config_address_ops = {
 
 static bool pci_device_exists(u8 bus_number, u8 device_number, u8 function_number)
 {
-	struct pci_device_header *dev;
+	struct device_header *dev;
 
 	if (pci_config_address.bus_number != bus_number)
 		return false;
@@ -71,12 +70,8 @@ static bool pci_device_exists(u8 bus_number, u8 device_number, u8 function_numbe
 	if (pci_config_address.function_number != function_number)
 		return false;
 
-	if (device_number >= PCI_MAX_DEVICES)
-		return false;
-
-	dev = pci_devices[device_number];
-
-	return dev != NULL;
+	dev = device__find_dev(device_number);
+	return !IS_ERR_OR_NULL(dev) && dev->bus_type == DEVICE_BUS_PCI;
 }
 
 static bool pci_config_data_out(struct ioport *ioport, struct kvm *kvm, u16 port, void *data, int size)
@@ -121,12 +116,13 @@ void pci__config_wr(struct kvm *kvm, union pci_config_address addr, void *data,
 
 		offset = addr.w & 0xff;
 		if (offset < sizeof(struct pci_device_header)) {
-			void *p = pci_devices[dev_num];
+			void *p = device__find_dev(dev_num)->data;
+			struct pci_device_header *hdr = p;
 			u8 bar = (offset - PCI_BAR_OFFSET(0)) / (sizeof(u32));
 			u32 sz = PCI_IO_SIZE;
 
-			if (bar < 6 && pci_devices[dev_num]->bar_size[bar])
-				sz = pci_devices[dev_num]->bar_size[bar];
+			if (bar < 6 && hdr->bar_size[bar])
+				sz = hdr->bar_size[bar];
 
 			/*
 			 * If the kernel masks the BAR it would expect to find the
@@ -158,7 +154,7 @@ void pci__config_rd(struct kvm *kvm, union pci_config_address addr, void *data,
 
 		offset = addr.w & 0xff;
 		if (offset < sizeof(struct pci_device_header)) {
-			void *p = pci_devices[dev_num];
+			void *p = device__find_dev(dev_num)->data;
 
 			memcpy(data, p + offset, size);
 		} else {
@@ -169,22 +165,14 @@ void pci__config_rd(struct kvm *kvm, union pci_config_address addr, void *data,
 	}
 }
 
-int pci__register(struct pci_device_header *dev, u8 dev_num)
-{
-	if (dev_num >= PCI_MAX_DEVICES)
-		return -ENOSPC;
-
-	pci_devices[dev_num] = dev;
-
-	return 0;
-}
-
 struct pci_device_header *pci__find_dev(u8 dev_num)
 {
-	if (dev_num >= PCI_MAX_DEVICES)
-		return ERR_PTR(-EOVERFLOW);
+	struct device_header *hdr = device__find_dev(dev_num);
+
+	if (IS_ERR(hdr) || hdr->bus_type != DEVICE_BUS_PCI)
+		return NULL;
 
-	return pci_devices[dev_num];
+	return hdr->data;
 }
 
 int pci__init(struct kvm *kvm)
diff --git a/tools/kvm/powerpc/irq.c b/tools/kvm/powerpc/irq.c
index e89fa3b..af239fb 100644
--- a/tools/kvm/powerpc/irq.c
+++ b/tools/kvm/powerpc/irq.c
@@ -8,6 +8,7 @@
  * by the Free Software Foundation.
  */
 
+#include "kvm/devices.h"
 #include "kvm/irq.h"
 #include "kvm/kvm.h"
 #include "kvm/util.h"
@@ -35,7 +36,7 @@ static int pci_devs = 0;
 
 int irq__register_device(u32 dev, u8 *num, u8 *pin, u8 *line)
 {
-	if (pci_devs >= PCI_MAX_DEVICES)
+	if (pci_devs >= KVM_MAX_DEVICES)
 		die("Hit PCI device limit!\n");
 
 	*num = pci_devs++;
diff --git a/tools/kvm/powerpc/spapr_pci.c b/tools/kvm/powerpc/spapr_pci.c
index b74790e..5bfcec1 100644
--- a/tools/kvm/powerpc/spapr_pci.c
+++ b/tools/kvm/powerpc/spapr_pci.c
@@ -302,7 +302,7 @@ int spapr_populate_pci_devices(struct kvm *kvm,
 	/* Populate PCI devices and allocate IRQs */
 	devices = 0;
 
-	for (devid = 0; devid < PCI_MAX_DEVICES; devid++) {
+	for (devid = 0; devid < KVM_MAX_DEVICES; devid++) {
 		uint32_t *irqmap = interrupt_map[devices];
 		struct pci_device_header *hdr = pci__find_dev(devid);
 
diff --git a/tools/kvm/virtio/mmio.c b/tools/kvm/virtio/mmio.c
index 6ec33ec..2d538b8 100644
--- a/tools/kvm/virtio/mmio.c
+++ b/tools/kvm/virtio/mmio.c
@@ -1,3 +1,4 @@
+#include "kvm/devices.h"
 #include "kvm/virtio-mmio.h"
 #include "kvm/ioeventfd.h"
 #include "kvm/ioport.h"
@@ -238,6 +239,12 @@ int virtio_mmio_init(struct kvm *kvm, void *dev, struct virtio_device *vdev,
 	if (irq__register_device(subsys_id, &device, &pin, &line) < 0)
 		return -1;
 	vmmio->irq = line;
+	vmmio->dev_hdr = (struct device_header) {
+		.bus_type	= DEVICE_BUS_MMIO,
+		.data		= vmmio,
+	};
+
+	device__register(&vmmio->dev_hdr, device);
 
 	/*
 	 * Instantiate guest virtio-mmio devices using kernel command line
diff --git a/tools/kvm/virtio/pci.c b/tools/kvm/virtio/pci.c
index adc8efc..e3cfb0a 100644
--- a/tools/kvm/virtio/pci.c
+++ b/tools/kvm/virtio/pci.c
@@ -343,6 +343,11 @@ int virtio_pci__init(struct kvm *kvm, void *dev, struct virtio_device *vdev,
 		.bar_size[3]		= PCI_IO_SIZE,
 	};
 
+	vpci->dev_hdr = (struct device_header) {
+		.bus_type		= DEVICE_BUS_PCI,
+		.data			= &vpci->pci_hdr,
+	};
+
 	vpci->pci_hdr.msix.cap = PCI_CAP_ID_MSIX;
 	vpci->pci_hdr.msix.next = 0;
 	/*
@@ -375,7 +380,7 @@ int virtio_pci__init(struct kvm *kvm, void *dev, struct virtio_device *vdev,
 
 	vpci->pci_hdr.irq_pin	= pin;
 	vpci->pci_hdr.irq_line	= line;
-	r = pci__register(&vpci->pci_hdr, ndev);
+	r = device__register(&vpci->dev_hdr, ndev);
 	if (r < 0)
 		goto free_ioport;
 
-- 
1.7.4.1

Re: [RFC PATCH 08/16] kvm tools: add generic device registration mechanism

[Sasha Levin]

On 11/12/2012 06:57 AM, Will Deacon wrote:
> PCI devices are currently registered into the pci_devices array via the
> pci__register function, which can then be indexed later by architecture
> code to construct device tree nodes. For MMIO devices, there is no such
> utility.
> 
> Rather than invent a similar mechanism for MMIO, this patch creates a
> global device registration mechanism, which allows the device type to be
> specified when registered or indexing a device. Current users of the pci
> registration code are migrated to the new infrastructure and virtio MMIO
> devices are registered at init time.
> 
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
>  tools/kvm/Makefile                  |    1 +
>  tools/kvm/devices.c                 |   24 +++++++++++++++++++++
>  tools/kvm/hw/pci-shmem.c            |    8 ++++++-
>  tools/kvm/hw/vesa.c                 |    8 ++++++-
>  tools/kvm/include/kvm/devices.h     |   21 ++++++++++++++++++
>  tools/kvm/include/kvm/pci.h         |    2 -
>  tools/kvm/include/kvm/virtio-mmio.h |    1 +
>  tools/kvm/include/kvm/virtio-pci.h  |    2 +
>  tools/kvm/pci.c                     |   40 ++++++++++++----------------------
>  tools/kvm/powerpc/irq.c             |    3 +-
>  tools/kvm/powerpc/spapr_pci.c       |    2 +-
>  tools/kvm/virtio/mmio.c             |    7 ++++++
>  tools/kvm/virtio/pci.c              |    7 +++++-
>  13 files changed, 93 insertions(+), 33 deletions(-)
>  create mode 100644 tools/kvm/devices.c
>  create mode 100644 tools/kvm/include/kvm/devices.h
> 
> diff --git a/tools/kvm/Makefile b/tools/kvm/Makefile
> index c105de1..5da416f 100644
> --- a/tools/kvm/Makefile
> +++ b/tools/kvm/Makefile
> @@ -50,6 +50,7 @@ OBJS	+= builtin-run.o
>  OBJS	+= builtin-setup.o
>  OBJS	+= builtin-stop.o
>  OBJS	+= builtin-version.o
> +OBJS	+= devices.o
>  OBJS	+= disk/core.o
>  OBJS	+= framebuffer.o
>  OBJS	+= guest_compat.o
> diff --git a/tools/kvm/devices.c b/tools/kvm/devices.c
> new file mode 100644
> index 0000000..f9666b9
> --- /dev/null
> +++ b/tools/kvm/devices.c
> @@ -0,0 +1,24 @@
> +#include "kvm/devices.h"
> +#include "kvm/kvm.h"
> +
> +#include <linux/err.h>
> +
> +static struct device_header *devices[KVM_MAX_DEVICES];

Does it really have a hard limit at KVM_MAX_DEVICES? Or can we turn it into
something more dynamic (list/tree/whatever)?


Thanks,
Sasha

Re: [RFC PATCH 08/16] kvm tools: add generic device registration mechanism

[Will Deacon]

Hi Sasha,

On Tue, Nov 13, 2012 at 04:29:33AM +0000, Sasha Levin wrote:
> On 11/12/2012 06:57 AM, Will Deacon wrote:
> > diff --git a/tools/kvm/devices.c b/tools/kvm/devices.c
> > new file mode 100644
> > index 0000000..f9666b9
> > --- /dev/null
> > +++ b/tools/kvm/devices.c
> > @@ -0,0 +1,24 @@
> > +#include "kvm/devices.h"
> > +#include "kvm/kvm.h"
> > +
> > +#include <linux/err.h>
> > +
> > +static struct device_header *devices[KVM_MAX_DEVICES];
> 
> Does it really have a hard limit at KVM_MAX_DEVICES? Or can we turn it into
> something more dynamic (list/tree/whatever)?

Sure, I'm happy to change the datatype to something more appropriate. Matt
also suggested trying to split up PCI devices from MMIO devices so that they
have their own ID namespaces, so I'll need to have a play.

Cheers,

Will

[RFC PATCH 09/16] kvm tools: make _FDT macro usable by other architectures

[Will Deacon]

The _FDT macro is useful when generating device trees for a guest, so
make it available to other architectures.

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 tools/kvm/include/kvm/fdt.h              |   26 ++++++++++++++++++++++++++
 tools/kvm/powerpc/include/kvm/kvm-arch.h |   11 -----------
 tools/kvm/powerpc/kvm.c                  |    2 +-
 tools/kvm/powerpc/spapr_pci.c            |    2 +-
 4 files changed, 28 insertions(+), 13 deletions(-)
 create mode 100644 tools/kvm/include/kvm/fdt.h

diff --git a/tools/kvm/include/kvm/fdt.h b/tools/kvm/include/kvm/fdt.h
new file mode 100644
index 0000000..19f95ac
--- /dev/null
+++ b/tools/kvm/include/kvm/fdt.h
@@ -0,0 +1,26 @@
+#ifndef KVM__FDT_H
+#define KVM__FDT_H
+
+#include "libfdt.h"
+
+#include <linux/types.h>
+
+#define FDT_MAX_SIZE	0x10000
+
+/* Helper for the various bits of code that generate FDT nodes */
+#define _FDT(exp)							\
+	do {								\
+		int ret = (exp);					\
+		if (ret < 0) {						\
+			die("Error creating device tree: %s: %s\n",	\
+			    #exp, fdt_strerror(ret));			\
+		}							\
+	} while (0)
+
+static inline u32 fdt__alloc_phandle(void)
+{
+	static u32 phandle = 0;
+	return ++phandle;
+}
+
+#endif /* KVM__FDT_H */
diff --git a/tools/kvm/powerpc/include/kvm/kvm-arch.h b/tools/kvm/powerpc/include/kvm/kvm-arch.h
index 97181c4..dd8a307 100644
--- a/tools/kvm/powerpc/include/kvm/kvm-arch.h
+++ b/tools/kvm/powerpc/include/kvm/kvm-arch.h
@@ -27,7 +27,6 @@
 #define KERNEL_SECONDARY_START_ADDR     0x0000000000000060
 #define INITRD_LOAD_ADDR        	0x0000000002800000
 
-#define FDT_MAX_SIZE            	0x10000
 #define RTAS_MAX_SIZE           	0x10000
 
 #define TIMEBASE_FREQ           	512000000ULL
@@ -55,14 +54,4 @@ struct kvm_arch {
 	struct spapr_phb	*phb;
 };
 
-/* Helper for the various bits of code that generate FDT nodes */
-#define _FDT(exp)							\
-	do {								\
-		int ret = (exp);					\
-		if (ret < 0) {						\
-			die("Error creating device tree: %s: %s\n",	\
-			    #exp, fdt_strerror(ret));			\
-		}							\
-	} while (0)
-
 #endif /* KVM__KVM_ARCH_H */
diff --git a/tools/kvm/powerpc/kvm.c b/tools/kvm/powerpc/kvm.c
index d675265..d8dfc01 100644
--- a/tools/kvm/powerpc/kvm.c
+++ b/tools/kvm/powerpc/kvm.c
@@ -11,9 +11,9 @@
  * by the Free Software Foundation.
  */
 
+#include "kvm/fdt.h"
 #include "kvm/kvm.h"
 #include "kvm/util.h"
-#include "libfdt.h"
 #include "cpu_info.h"
 
 #include "spapr.h"
diff --git a/tools/kvm/powerpc/spapr_pci.c b/tools/kvm/powerpc/spapr_pci.c
index 5bfcec1..5f4016c 100644
--- a/tools/kvm/powerpc/spapr_pci.c
+++ b/tools/kvm/powerpc/spapr_pci.c
@@ -15,9 +15,9 @@
 
 #include "spapr.h"
 #include "spapr_pci.h"
+#include "kvm/fdt.h"
 #include "kvm/util.h"
 #include "kvm/pci.h"
-#include "libfdt.h"
 
 #include <linux/pci_regs.h>
 #include <linux/byteorder.h>
-- 
1.7.4.1

[RFC PATCH 10/16] kvm tools: virtio-mmio: use subsys_id instead of pci device ID

[Will Deacon]

The virtio MMIO code attempts to map PCI device IDs to virtio MMIO
device IDs by subtracting 0x1000 and adding 1, however this conversion
only works for NET and BLK devices.

This patch uses the subsys_id (which is actually the virtio device ID
for virtio-mmio devices) instead of the PCI device ID when populating
the mmio device header.

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 tools/kvm/virtio/mmio.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/kvm/virtio/mmio.c b/tools/kvm/virtio/mmio.c
index 2d538b8..18a268b 100644
--- a/tools/kvm/virtio/mmio.c
+++ b/tools/kvm/virtio/mmio.c
@@ -231,7 +231,7 @@ int virtio_mmio_init(struct kvm *kvm, void *dev, struct virtio_device *vdev,
 	vmmio->hdr = (struct virtio_mmio_hdr) {
 		.magic		= {'v', 'i', 'r', 't'},
 		.version	= 1,
-		.device_id	= device_id - 0x1000 + 1,
+		.device_id	= subsys_id,
 		.vendor_id	= 0x4d564b4c , /* 'LKVM' */
 		.queue_num_max	= 256,
 	};
-- 
1.7.4.1

[RFC PATCH 11/16] kvm tools: virtio: add dummy set_size_vq implementations

[Will Deacon]

When a guest kernel initialises a virtio device using an MMIO transport,
it attempts to set the size of the virtual queue. For devices that expect
a PCI transport, this is not the case and, as such, our console, 9p and
rng virtio devices do not set a pointer for this function and subsequently
SEGV.

This patch adds a dummy implementation of the function to avoid the fatal
signal.

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 tools/kvm/virtio/9p.c      |    7 +++++++
 tools/kvm/virtio/console.c |    7 +++++++
 tools/kvm/virtio/rng.c     |    7 +++++++
 3 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/tools/kvm/virtio/9p.c b/tools/kvm/virtio/9p.c
index 835a8c4..a372c22 100644
--- a/tools/kvm/virtio/9p.c
+++ b/tools/kvm/virtio/9p.c
@@ -1300,6 +1300,12 @@ static int get_size_vq(struct kvm *kvm, void *dev, u32 vq)
 	return VIRTQUEUE_NUM;
 }
 
+static int set_size_vq(struct kvm *kvm, void *dev, u32 vq, int size)
+{
+	/* FIXME: dynamic */
+	return size;
+}
+
 struct virtio_ops p9_dev_virtio_ops = (struct virtio_ops) {
 	.get_config		= get_config,
 	.get_host_features	= get_host_features,
@@ -1308,6 +1314,7 @@ struct virtio_ops p9_dev_virtio_ops = (struct virtio_ops) {
 	.notify_vq		= notify_vq,
 	.get_pfn_vq		= get_pfn_vq,
 	.get_size_vq		= get_size_vq,
+	.set_size_vq		= set_size_vq,
 };
 
 int virtio_9p_rootdir_parser(const struct option *opt, const char *arg, int unset)
diff --git a/tools/kvm/virtio/console.c b/tools/kvm/virtio/console.c
index 1df6cb0..ea5d974 100644
--- a/tools/kvm/virtio/console.c
+++ b/tools/kvm/virtio/console.c
@@ -172,6 +172,12 @@ static int get_size_vq(struct kvm *kvm, void *dev, u32 vq)
 	return VIRTIO_CONSOLE_QUEUE_SIZE;
 }
 
+static int set_size_vq(struct kvm *kvm, void *dev, u32 vq, int size)
+{
+	/* FIXME: dynamic */
+	return size;
+}
+
 static struct virtio_ops con_dev_virtio_ops = (struct virtio_ops) {
 	.get_config		= get_config,
 	.get_host_features	= get_host_features,
@@ -180,6 +186,7 @@ static struct virtio_ops con_dev_virtio_ops = (struct virtio_ops) {
 	.notify_vq		= notify_vq,
 	.get_pfn_vq		= get_pfn_vq,
 	.get_size_vq		= get_size_vq,
+	.set_size_vq		= set_size_vq,
 };
 
 int virtio_console__init(struct kvm *kvm)
diff --git a/tools/kvm/virtio/rng.c b/tools/kvm/virtio/rng.c
index b2616d8..e1e4fc0 100644
--- a/tools/kvm/virtio/rng.c
+++ b/tools/kvm/virtio/rng.c
@@ -132,6 +132,12 @@ static int get_size_vq(struct kvm *kvm, void *dev, u32 vq)
 	return VIRTIO_RNG_QUEUE_SIZE;
 }
 
+static int set_size_vq(struct kvm *kvm, void *dev, u32 vq, int size)
+{
+	/* FIXME: dynamic */
+	return size;
+}
+
 static struct virtio_ops rng_dev_virtio_ops = (struct virtio_ops) {
 	.get_config		= get_config,
 	.get_host_features	= get_host_features,
@@ -140,6 +146,7 @@ static struct virtio_ops rng_dev_virtio_ops = (struct virtio_ops) {
 	.notify_vq		= notify_vq,
 	.get_pfn_vq		= get_pfn_vq,
 	.get_size_vq		= get_size_vq,
+	.set_size_vq		= set_size_vq,
 };
 
 int virtio_rng__init(struct kvm *kvm)
-- 
1.7.4.1

[RFC PATCH 12/16] kvm tools: allow arch to specify default virtio transport

[Will Deacon]

Some architectures may provide only a restricted PCI implementation and
therefore prefer MMIO as the transport for virtio devices.

This patch allows the arch backend to specify the default virtio
transport. Some devices (e.g. net) allow the transport to be overriden
by the user and are left alone by this change.

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 tools/kvm/powerpc/include/kvm/kvm-arch.h |    2 ++
 tools/kvm/virtio/9p.c                    |    3 ++-
 tools/kvm/virtio/balloon.c               |    3 ++-
 tools/kvm/virtio/blk.c                   |    3 ++-
 tools/kvm/virtio/console.c               |    3 ++-
 tools/kvm/virtio/rng.c                   |    3 ++-
 tools/kvm/virtio/scsi.c                  |    3 ++-
 tools/kvm/x86/include/kvm/kvm-arch.h     |    2 ++
 8 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/tools/kvm/powerpc/include/kvm/kvm-arch.h b/tools/kvm/powerpc/include/kvm/kvm-arch.h
index dd8a307..d93e142 100644
--- a/tools/kvm/powerpc/include/kvm/kvm-arch.h
+++ b/tools/kvm/powerpc/include/kvm/kvm-arch.h
@@ -40,6 +40,8 @@
 #define KVM_PCI_MMIO_AREA		0x1000000
 #define KVM_VIRTIO_MMIO_AREA		0x2000000
 
+#define VIRTIO_DEFAULT_TRANS	VIRTIO_PCI
+
 struct spapr_phb;
 
 struct kvm_arch {
diff --git a/tools/kvm/virtio/9p.c b/tools/kvm/virtio/9p.c
index a372c22..4665876 100644
--- a/tools/kvm/virtio/9p.c
+++ b/tools/kvm/virtio/9p.c
@@ -1390,7 +1390,8 @@ int virtio_9p__init(struct kvm *kvm)
 
 	list_for_each_entry(p9dev, &devs, list) {
 		virtio_init(kvm, p9dev, &p9dev->vdev, &p9_dev_virtio_ops,
-			    VIRTIO_PCI, PCI_DEVICE_ID_VIRTIO_9P, VIRTIO_ID_9P, PCI_CLASS_9P);
+			    VIRTIO_DEFAULT_TRANS, PCI_DEVICE_ID_VIRTIO_9P,
+			    VIRTIO_ID_9P, PCI_CLASS_9P);
 	}
 
 	return 0;
diff --git a/tools/kvm/virtio/balloon.c b/tools/kvm/virtio/balloon.c
index e08f628..3965b24 100644
--- a/tools/kvm/virtio/balloon.c
+++ b/tools/kvm/virtio/balloon.c
@@ -254,7 +254,8 @@ int virtio_bln__init(struct kvm *kvm)
 	memset(&bdev.config, 0, sizeof(struct virtio_balloon_config));
 
 	virtio_init(kvm, &bdev, &bdev.vdev, &bln_dev_virtio_ops,
-		    VIRTIO_PCI, PCI_DEVICE_ID_VIRTIO_BLN, VIRTIO_ID_BALLOON, PCI_CLASS_BLN);
+		    VIRTIO_DEFAULT_TRANS, PCI_DEVICE_ID_VIRTIO_BLN,
+		    VIRTIO_ID_BALLOON, PCI_CLASS_BLN);
 
 	if (compat_id == -1)
 		compat_id = virtio_compat_add_message("virtio-balloon", "CONFIG_VIRTIO_BALLOON");
diff --git a/tools/kvm/virtio/blk.c b/tools/kvm/virtio/blk.c
index 356a240..ec57e96 100644
--- a/tools/kvm/virtio/blk.c
+++ b/tools/kvm/virtio/blk.c
@@ -259,7 +259,8 @@ static int virtio_blk__init_one(struct kvm *kvm, struct disk_image *disk)
 	};
 
 	virtio_init(kvm, bdev, &bdev->vdev, &blk_dev_virtio_ops,
-		    VIRTIO_PCI, PCI_DEVICE_ID_VIRTIO_BLK, VIRTIO_ID_BLOCK, PCI_CLASS_BLK);
+		    VIRTIO_DEFAULT_TRANS, PCI_DEVICE_ID_VIRTIO_BLK,
+		    VIRTIO_ID_BLOCK, PCI_CLASS_BLK);
 
 	list_add_tail(&bdev->list, &bdevs);
 
diff --git a/tools/kvm/virtio/console.c b/tools/kvm/virtio/console.c
index ea5d974..74b6ffd 100644
--- a/tools/kvm/virtio/console.c
+++ b/tools/kvm/virtio/console.c
@@ -195,7 +195,8 @@ int virtio_console__init(struct kvm *kvm)
 		return 0;
 
 	virtio_init(kvm, &cdev, &cdev.vdev, &con_dev_virtio_ops,
-		    VIRTIO_PCI, PCI_DEVICE_ID_VIRTIO_CONSOLE, VIRTIO_ID_CONSOLE, PCI_CLASS_CONSOLE);
+		    VIRTIO_DEFAULT_TRANS, PCI_DEVICE_ID_VIRTIO_CONSOLE,
+		    VIRTIO_ID_CONSOLE, PCI_CLASS_CONSOLE);
 	if (compat_id == -1)
 		compat_id = virtio_compat_add_message("virtio-console", "CONFIG_VIRTIO_CONSOLE");
 
diff --git a/tools/kvm/virtio/rng.c b/tools/kvm/virtio/rng.c
index e1e4fc0..1a09fdf 100644
--- a/tools/kvm/virtio/rng.c
+++ b/tools/kvm/virtio/rng.c
@@ -168,7 +168,8 @@ int virtio_rng__init(struct kvm *kvm)
 	}
 
 	r = virtio_init(kvm, rdev, &rdev->vdev, &rng_dev_virtio_ops,
-			VIRTIO_PCI, PCI_DEVICE_ID_VIRTIO_RNG, VIRTIO_ID_RNG, PCI_CLASS_RNG);
+			VIRTIO_DEFAULT_TRANS, PCI_DEVICE_ID_VIRTIO_RNG,
+			VIRTIO_ID_RNG, PCI_CLASS_RNG);
 	if (r < 0)
 		goto cleanup;
 
diff --git a/tools/kvm/virtio/scsi.c b/tools/kvm/virtio/scsi.c
index 881898b..7ba76d0 100644
--- a/tools/kvm/virtio/scsi.c
+++ b/tools/kvm/virtio/scsi.c
@@ -251,7 +251,8 @@ static int virtio_scsi_init_one(struct kvm *kvm, struct disk_image *disk)
 	sdev->target.vhost_tpgt = strtol(disk->tpgt, NULL, 0);
 
 	virtio_init(kvm, sdev, &sdev->vdev, &scsi_dev_virtio_ops,
-		    VIRTIO_PCI, PCI_DEVICE_ID_VIRTIO_SCSI, VIRTIO_ID_SCSI, PCI_CLASS_BLK);
+		    VIRTIO_DEFAULT_TRANS, PCI_DEVICE_ID_VIRTIO_SCSI,
+		    VIRTIO_ID_SCSI, PCI_CLASS_BLK);
 
 	list_add_tail(&sdev->list, &sdevs);
 
diff --git a/tools/kvm/x86/include/kvm/kvm-arch.h b/tools/kvm/x86/include/kvm/kvm-arch.h
index 30086f4..2aaedcc 100644
--- a/tools/kvm/x86/include/kvm/kvm-arch.h
+++ b/tools/kvm/x86/include/kvm/kvm-arch.h
@@ -23,6 +23,8 @@
 #define KVM_PCI_MMIO_AREA	(KVM_MMIO_START + 0x1000000)
 #define KVM_VIRTIO_MMIO_AREA	(KVM_MMIO_START + 0x2000000)
 
+#define VIRTIO_DEFAULT_TRANS	VIRTIO_PCI
+
 struct kvm_arch {
 	u16			boot_selector;
 	u16			boot_ip;
-- 
1.7.4.1

[RFC PATCH 13/16] kvm tools: keep track of registered memory banks in struct kvm

[Will Deacon]

When registering memory banks for a guest, it is useful to keep the
range information around for translating between guest and host address
spaces.

This patch adds a list of kvm_mem_bank structures to struct kvm, which
is updated when a new bank is registered.

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 tools/kvm/include/kvm/kvm.h |    8 ++++++++
 tools/kvm/kvm.c             |   23 ++++++++++++++++++++++-
 2 files changed, 30 insertions(+), 1 deletions(-)

diff --git a/tools/kvm/include/kvm/kvm.h b/tools/kvm/include/kvm/kvm.h
index cf959ea..96dd81b 100644
--- a/tools/kvm/include/kvm/kvm.h
+++ b/tools/kvm/include/kvm/kvm.h
@@ -35,6 +35,13 @@ struct kvm_ext {
 	int code;
 };
 
+struct kvm_mem_bank {
+	struct list_head	list;
+	unsigned long		guest_phys_addr;
+	void			*host_addr;
+	unsigned long		size;
+};
+
 struct kvm {
 	struct kvm_arch		arch;
 	struct kvm_config	cfg;
@@ -49,6 +56,7 @@ struct kvm {
 	u64			ram_size;
 	void			*ram_start;
 	u64			ram_pagesize;
+	struct list_head	mem_banks;
 
 	bool			nmi_disabled;
 
diff --git a/tools/kvm/kvm.c b/tools/kvm/kvm.c
index b283171..1a10ec0 100644
--- a/tools/kvm/kvm.c
+++ b/tools/kvm/kvm.c
@@ -6,7 +6,9 @@
 #include "kvm/kvm-cpu.h"
 #include "kvm/kvm-ipc.h"
 
+#include <linux/kernel.h>
 #include <linux/kvm.h>
+#include <linux/list.h>
 #include <linux/err.h>
 
 #include <sys/un.h>
@@ -133,9 +135,16 @@ struct kvm *kvm__new(void)
 
 int kvm__exit(struct kvm *kvm)
 {
+	struct kvm_mem_bank *bank, *tmp;
+
 	kvm__arch_delete_ram(kvm);
-	free(kvm);
 
+	list_for_each_entry_safe(bank, tmp, &kvm->mem_banks, list) {
+		list_del(&bank->list);
+		free(bank);
+	}
+
+	free(kvm);
 	return 0;
 }
 core_exit(kvm__exit);
@@ -148,8 +157,18 @@ core_exit(kvm__exit);
 int kvm__register_mem(struct kvm *kvm, u64 guest_phys, u64 size, void *userspace_addr)
 {
 	struct kvm_userspace_memory_region mem;
+	struct kvm_mem_bank *bank;
 	int ret;
 
+	bank = malloc(sizeof(*bank));
+	if (!bank)
+		return -ENOMEM;
+
+	INIT_LIST_HEAD(&bank->list);
+	bank->guest_phys_addr		= guest_phys;
+	bank->host_addr			= userspace_addr;
+	bank->size			= size;
+
 	mem = (struct kvm_userspace_memory_region) {
 		.slot			= kvm->mem_slots++,
 		.guest_phys_addr	= guest_phys,
@@ -161,6 +180,7 @@ int kvm__register_mem(struct kvm *kvm, u64 guest_phys, u64 size, void *userspace
 	if (ret < 0)
 		return -errno;
 
+	list_add(&bank->list, &kvm->mem_banks);
 	return 0;
 }
 
@@ -245,6 +265,7 @@ int kvm__init(struct kvm *kvm)
 
 	kvm__arch_init(kvm, kvm->cfg.hugetlbfs_path, kvm->cfg.ram_size);
 
+	INIT_LIST_HEAD(&kvm->mem_banks);
 	kvm__init_ram(kvm);
 
 	if (!kvm->cfg.firmware_filename) {
-- 
1.7.4.1

Re: [RFC PATCH 13/16] kvm tools: keep track of registered memory banks in struct kvm

[Sasha Levin]

On 11/12/2012 06:57 AM, Will Deacon wrote:
> When registering memory banks for a guest, it is useful to keep the
> range information around for translating between guest and host address
> spaces.
> 
> This patch adds a list of kvm_mem_bank structures to struct kvm, which
> is updated when a new bank is registered.
> 
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
>  tools/kvm/include/kvm/kvm.h |    8 ++++++++
>  tools/kvm/kvm.c             |   23 ++++++++++++++++++++++-
>  2 files changed, 30 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/kvm/include/kvm/kvm.h b/tools/kvm/include/kvm/kvm.h
> index cf959ea..96dd81b 100644
> --- a/tools/kvm/include/kvm/kvm.h
> +++ b/tools/kvm/include/kvm/kvm.h
> @@ -35,6 +35,13 @@ struct kvm_ext {
>  	int code;
>  };
>  
> +struct kvm_mem_bank {
> +	struct list_head	list;
> +	unsigned long		guest_phys_addr;
> +	void			*host_addr;
> +	unsigned long		size;
> +};

Can we just reuse struct kvm_userspace_memory_region here? We're also using different
data types for guest_phys_addr and size than whats in kvm_userspace_memory_region - that
can't be good.

>  struct kvm {
>  	struct kvm_arch		arch;
>  	struct kvm_config	cfg;
> @@ -49,6 +56,7 @@ struct kvm {
>  	u64			ram_size;
>  	void			*ram_start;
>  	u64			ram_pagesize;
> +	struct list_head	mem_banks;

These memory banks actually look like a perfect example to use our augmented interval rb-tree,
can we switch them to use it, or is it a list on purpose?


Thanks,
Sasha

Re: [RFC PATCH 13/16] kvm tools: keep track of registered memory banks in struct kvm

[Will Deacon]

On Tue, Nov 13, 2012 at 04:37:38AM +0000, Sasha Levin wrote:
> On 11/12/2012 06:57 AM, Will Deacon wrote:
> > +struct kvm_mem_bank {
> > +	struct list_head	list;
> > +	unsigned long		guest_phys_addr;
> > +	void			*host_addr;
> > +	unsigned long		size;
> > +};
> 
> Can we just reuse struct kvm_userspace_memory_region here? We're also using different
> data types for guest_phys_addr and size than whats in kvm_userspace_memory_region - that
> can't be good.

I looked briefly at doing that when I wrote the multi-bank stuff, but I hit
a couple of issues:

	- kvmtool itself tends to use void * for host addresses, rather than
	  the __u64 userspace_addr in kvm_userspace_memory_region

	- kvm_userspace_memory_region is a superset of what we need (not the
	  end of the world I guess)

so you end up casting address types a fair amount. Still, I'll revisit it
and see if I can come up with something cleaner.

> >  struct kvm {
> >  	struct kvm_arch		arch;
> >  	struct kvm_config	cfg;
> > @@ -49,6 +56,7 @@ struct kvm {
> >  	u64			ram_size;
> >  	void			*ram_start;
> >  	u64			ram_pagesize;
> > +	struct list_head	mem_banks;
> 
> These memory banks actually look like a perfect example to use our augmented interval rb-tree,
> can we switch them to use it, or is it a list on purpose?

Well, the usual case is one memory bank but that doesn't swing the argument
either way. I'll update to use the fancy new tree.

Thanks for the comments,

Will

Re: [RFC PATCH 13/16] kvm tools: keep track of registered memory banks in struct kvm

[Sasha Levin]

On 11/13/2012 07:16 AM, Will Deacon wrote:
> On Tue, Nov 13, 2012 at 04:37:38AM +0000, Sasha Levin wrote:
>> On 11/12/2012 06:57 AM, Will Deacon wrote:
>>> +struct kvm_mem_bank {
>>> +	struct list_head	list;
>>> +	unsigned long		guest_phys_addr;
>>> +	void			*host_addr;
>>> +	unsigned long		size;
>>> +};
>>
>> Can we just reuse struct kvm_userspace_memory_region here? We're also using different
>> data types for guest_phys_addr and size than whats in kvm_userspace_memory_region - that
>> can't be good.
> 
> I looked briefly at doing that when I wrote the multi-bank stuff, but I hit
> a couple of issues:
> 
> 	- kvmtool itself tends to use void * for host addresses, rather than
> 	  the __u64 userspace_addr in kvm_userspace_memory_region
> 
> 	- kvm_userspace_memory_region is a superset of what we need (not the
> 	  end of the world I guess)
> 
> so you end up casting address types a fair amount. Still, I'll revisit it
> and see if I can come up with something cleaner.

That's a good point. We used void* while the kernel side is using u64, which
looks odd.

In that case, let's get everything moved to u64 (obviously not in the scope of
this patch series).


Thanks,
Sasha

Re: [RFC PATCH 13/16] kvm tools: keep track of registered memory banks in struct kvm

[Will Deacon]

On Tue, Nov 13, 2012 at 04:09:05PM +0000, Sasha Levin wrote:
> On 11/13/2012 07:16 AM, Will Deacon wrote:
> > On Tue, Nov 13, 2012 at 04:37:38AM +0000, Sasha Levin wrote:
> >> On 11/12/2012 06:57 AM, Will Deacon wrote:
> >>> +struct kvm_mem_bank {
> >>> +	struct list_head	list;
> >>> +	unsigned long		guest_phys_addr;
> >>> +	void			*host_addr;
> >>> +	unsigned long		size;
> >>> +};
> >>
> >> Can we just reuse struct kvm_userspace_memory_region here? We're also using different
> >> data types for guest_phys_addr and size than whats in kvm_userspace_memory_region - that
> >> can't be good.
> > 
> > I looked briefly at doing that when I wrote the multi-bank stuff, but I hit
> > a couple of issues:
> > 
> > 	- kvmtool itself tends to use void * for host addresses, rather than
> > 	  the __u64 userspace_addr in kvm_userspace_memory_region
> > 
> > 	- kvm_userspace_memory_region is a superset of what we need (not the
> > 	  end of the world I guess)
> > 
> > so you end up casting address types a fair amount. Still, I'll revisit it
> > and see if I can come up with something cleaner.
> 
> That's a good point. We used void* while the kernel side is using u64, which
> looks odd.
> 
> In that case, let's get everything moved to u64 (obviously not in the scope of
> this patch series).

Ok, I'll update the size field to match in this patch series, then we can
tackle the address discrepancy separately.

Cheers,

Will

Re: [RFC PATCH 13/16] kvm tools: keep track of registered memory banks in struct kvm

[Will Deacon]

Hi Sasha,

On Tue, Nov 13, 2012 at 04:37:38AM +0000, Sasha Levin wrote:
> On 11/12/2012 06:57 AM, Will Deacon wrote:
> >  struct kvm {
> >  	struct kvm_arch		arch;
> >  	struct kvm_config	cfg;
> > @@ -49,6 +56,7 @@ struct kvm {
> >  	u64			ram_size;
> >  	void			*ram_start;
> >  	u64			ram_pagesize;
> > +	struct list_head	mem_banks;
> 
> These memory banks actually look like a perfect example to use our augmented interval rb-tree,
> can we switch them to use it, or is it a list on purpose?

I found some time to look at this today but unfortunately they're not as
ideally suited to the interval tree as they look: the problem being that we
need to search for banks by both host virtual address *and* guest physical
address depending on the translation that we're doing.

We could have two separate tress, but that seems like overkill given the
likely number of banks.

Will

Re: [RFC PATCH 13/16] kvm tools: keep track of registered memory banks in struct kvm

[Sasha Levin]

On 11/20/2012 12:15 PM, Will Deacon wrote:
> Hi Sasha,
> 
> On Tue, Nov 13, 2012 at 04:37:38AM +0000, Sasha Levin wrote:
>> On 11/12/2012 06:57 AM, Will Deacon wrote:
>>>  struct kvm {
>>>  	struct kvm_arch		arch;
>>>  	struct kvm_config	cfg;
>>> @@ -49,6 +56,7 @@ struct kvm {
>>>  	u64			ram_size;
>>>  	void			*ram_start;
>>>  	u64			ram_pagesize;
>>> +	struct list_head	mem_banks;
>>
>> These memory banks actually look like a perfect example to use our augmented interval rb-tree,
>> can we switch them to use it, or is it a list on purpose?
> 
> I found some time to look at this today but unfortunately they're not as
> ideally suited to the interval tree as they look: the problem being that we
> need to search for banks by both host virtual address *and* guest physical
> address depending on the translation that we're doing.
> 
> We could have two separate tress, but that seems like overkill given the
> likely number of banks.

Makes sense. We can convert it later if we need to as well.


Thanks,
Sasha

[RFC PATCH 14/16] kvm tools: teach guest_flat_to_host about memory banks starting above 0

[Will Deacon]

Running a guest with multiple banks of memory based above 0 causes the
guest_flat_to_host address conversion to fail, as it is assumed that
guest memory addresses are offset linearly from 0.

This patch changes the translation function so that the kvm_mem_bank
structures registered by kvm__register_mem are used to translate guest
addresses, rather than use an offset from the start of host memory.

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 tools/kvm/include/kvm/kvm.h          |    7 ++-----
 tools/kvm/kvm.c                      |   16 ++++++++++++++++
 tools/kvm/x86/include/kvm/kvm-arch.h |    9 ---------
 tools/kvm/x86/kvm.c                  |    7 +++++++
 4 files changed, 25 insertions(+), 14 deletions(-)

diff --git a/tools/kvm/include/kvm/kvm.h b/tools/kvm/include/kvm/kvm.h
index 96dd81b..ce09142 100644
--- a/tools/kvm/include/kvm/kvm.h
+++ b/tools/kvm/include/kvm/kvm.h
@@ -105,6 +105,8 @@ int kvm__arch_free_firmware(struct kvm *kvm);
 bool kvm__arch_cpu_supports_vm(void);
 void kvm__arch_periodic_poll(struct kvm *kvm);
 
+void *guest_flat_to_host(struct kvm *kvm, unsigned long offset);
+
 int load_flat_binary(struct kvm *kvm, int fd_kernel, int fd_initrd, const char *kernel_cmdline);
 bool load_bzimage(struct kvm *kvm, int fd_kernel, int fd_initrd, const char *kernel_cmdline, u16 vidmode);
 
@@ -120,11 +122,6 @@ static inline bool host_ptr_in_ram(struct kvm *kvm, void *p)
 	return kvm->ram_start <= p && p < (kvm->ram_start + kvm->ram_size);
 }
 
-static inline void *guest_flat_to_host(struct kvm *kvm, unsigned long offset)
-{
-	return kvm->ram_start + offset;
-}
-
 bool kvm__supports_extension(struct kvm *kvm, unsigned int extension);
 
 static inline void kvm__set_thread_name(const char *name)
diff --git a/tools/kvm/kvm.c b/tools/kvm/kvm.c
index 1a10ec0..1702533 100644
--- a/tools/kvm/kvm.c
+++ b/tools/kvm/kvm.c
@@ -184,6 +184,22 @@ int kvm__register_mem(struct kvm *kvm, u64 guest_phys, u64 size, void *userspace
 	return 0;
 }
 
+void *guest_flat_to_host(struct kvm *kvm, unsigned long offset)
+{
+	struct kvm_mem_bank *bank;
+
+	list_for_each_entry(bank, &kvm->mem_banks, list) {
+		unsigned long bank_start = bank->guest_phys_addr;
+		unsigned long bank_end = bank_start + bank->size;
+
+		if (offset >= bank_start && offset < bank_end)
+			return bank->host_addr + (offset - bank_start);
+	}
+
+	pr_warning("unable to translate guest address 0x%lx to host", offset);
+	return NULL;
+}
+
 int kvm__recommended_cpus(struct kvm *kvm)
 {
 	int ret;
diff --git a/tools/kvm/x86/include/kvm/kvm-arch.h b/tools/kvm/x86/include/kvm/kvm-arch.h
index 2aaedcc..1e0949e 100644
--- a/tools/kvm/x86/include/kvm/kvm-arch.h
+++ b/tools/kvm/x86/include/kvm/kvm-arch.h
@@ -33,13 +33,4 @@ struct kvm_arch {
 	struct interrupt_table	interrupt_table;
 };
 
-static inline void *guest_flat_to_host(struct kvm *kvm, unsigned long offset); /* In kvm.h */
-
-static inline void *guest_real_to_host(struct kvm *kvm, u16 selector, u16 offset)
-{
-	unsigned long flat = segment_to_flat(selector, offset);
-
-	return guest_flat_to_host(kvm, flat);
-}
-
 #endif /* KVM__KVM_ARCH_H */
diff --git a/tools/kvm/x86/kvm.c b/tools/kvm/x86/kvm.c
index ecada45..9971ffd 100644
--- a/tools/kvm/x86/kvm.c
+++ b/tools/kvm/x86/kvm.c
@@ -199,6 +199,13 @@ void kvm__irq_trigger(struct kvm *kvm, int irq)
 #define BOOT_PROTOCOL_REQUIRED	0x206
 #define LOAD_HIGH		0x01
 
+static inline void *guest_real_to_host(struct kvm *kvm, u16 selector, u16 offset)
+{
+	unsigned long flat = segment_to_flat(selector, offset);
+
+	return guest_flat_to_host(kvm, flat);
+}
+
 int load_flat_binary(struct kvm *kvm, int fd_kernel, int fd_initrd, const char *kernel_cmdline)
 {
 	void *p;
-- 
1.7.4.1

Re: [RFC PATCH 14/16] kvm tools: teach guest_flat_to_host about memory banks starting above 0

[Sasha Levin]

On 11/12/2012 06:57 AM, Will Deacon wrote:
> Running a guest with multiple banks of memory based above 0 causes the
> guest_flat_to_host address conversion to fail, as it is assumed that
> guest memory addresses are offset linearly from 0.
> 
> This patch changes the translation function so that the kvm_mem_bank
> structures registered by kvm__register_mem are used to translate guest
> addresses, rather than use an offset from the start of host memory.
> 
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---

Hmm... we probably need something to teach E820 about this new memory layout
thingie if we start mapping multiple memory banks.

Not urgent for now though - I guess.


Thanks,
Sasha

[RFC PATCH 15/16] kvm tools: provide a mechanism for translating host to guest addresses

[Will Deacon]

When generating a device tree for a guest, it is useful to have a helper
for converting host addresses to guest addresses in order to populate
the device nodes correctly.

This patch adds such a helper, following a similar implementation to the
reverse translation function that already exists.

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 tools/kvm/include/kvm/kvm.h |    1 +
 tools/kvm/kvm.c             |   16 ++++++++++++++++
 2 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/tools/kvm/include/kvm/kvm.h b/tools/kvm/include/kvm/kvm.h
index ce09142..3ebd229 100644
--- a/tools/kvm/include/kvm/kvm.h
+++ b/tools/kvm/include/kvm/kvm.h
@@ -106,6 +106,7 @@ bool kvm__arch_cpu_supports_vm(void);
 void kvm__arch_periodic_poll(struct kvm *kvm);
 
 void *guest_flat_to_host(struct kvm *kvm, unsigned long offset);
+unsigned long host_to_guest_flat(struct kvm *kvm, void *ptr);
 
 int load_flat_binary(struct kvm *kvm, int fd_kernel, int fd_initrd, const char *kernel_cmdline);
 bool load_bzimage(struct kvm *kvm, int fd_kernel, int fd_initrd, const char *kernel_cmdline, u16 vidmode);
diff --git a/tools/kvm/kvm.c b/tools/kvm/kvm.c
index 1702533..b876906 100644
--- a/tools/kvm/kvm.c
+++ b/tools/kvm/kvm.c
@@ -200,6 +200,22 @@ void *guest_flat_to_host(struct kvm *kvm, unsigned long offset)
 	return NULL;
 }
 
+unsigned long host_to_guest_flat(struct kvm *kvm, void *ptr)
+{
+	struct kvm_mem_bank *bank;
+
+	list_for_each_entry(bank, &kvm->mem_banks, list) {
+		void *bank_start = bank->host_addr;
+		void *bank_end = bank_start + bank->size;
+
+		if (ptr >= bank_start && ptr < bank_end)
+			return bank->guest_phys_addr + (ptr - bank_start);
+	}
+
+	pr_warning("unable to translate host address %p to guest", ptr);
+	return 0;
+}
+
 int kvm__recommended_cpus(struct kvm *kvm)
 {
 	int ret;
-- 
1.7.4.1

[RFC PATCH 16/16] kvm tools: add support for ARMv7 processors

[Will Deacon]

This patch adds initial support for ARMv7 processors (more specifically,
Cortex-A15) to kvmtool.

Everything is driven by FDT, including dynamic generation of virtio nodes
for MMIO devices (PCI is not used due to lack of a suitable host-bridge).

The virtual timers and virtual interrupt controller (VGIC) are provided
by the kernel and require very little in terms of userspace code.

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 tools/kvm/Makefile                           |   20 ++-
 tools/kvm/arm/aarch32/cortex-a15.c           |   98 ++++++++++
 tools/kvm/arm/aarch32/include/kvm/barrier.h  |   10 +
 tools/kvm/arm/aarch32/include/kvm/kvm-arch.h |   28 +++
 tools/kvm/arm/aarch32/kvm-cpu.c              |  111 +++++++++++
 tools/kvm/arm/aarch32/smp-pen.S              |   14 ++
 tools/kvm/arm/fdt.c                          |  269 ++++++++++++++++++++++++++
 tools/kvm/arm/gic.c                          |   86 ++++++++
 tools/kvm/arm/include/arm-common/gic.h       |   29 +++
 tools/kvm/arm/include/arm-common/kvm-arch.h  |   31 +++
 tools/kvm/arm/include/arm-common/smp.h       |    7 +
 tools/kvm/arm/include/kvm/kvm-cpu-arch.h     |   47 +++++
 tools/kvm/arm/ioport.c                       |    5 +
 tools/kvm/arm/irq.c                          |   25 +++
 tools/kvm/arm/kvm-cpu.c                      |  112 +++++++++++
 tools/kvm/arm/kvm.c                          |   69 +++++++
 tools/kvm/arm/smp.c                          |   13 ++
 17 files changed, 973 insertions(+), 1 deletions(-)
 create mode 100644 tools/kvm/arm/aarch32/cortex-a15.c
 create mode 100644 tools/kvm/arm/aarch32/include/kvm/barrier.h
 create mode 100644 tools/kvm/arm/aarch32/include/kvm/kvm-arch.h
 create mode 100644 tools/kvm/arm/aarch32/kvm-cpu.c
 create mode 100644 tools/kvm/arm/aarch32/smp-pen.S
 create mode 100644 tools/kvm/arm/fdt.c
 create mode 100644 tools/kvm/arm/gic.c
 create mode 100644 tools/kvm/arm/include/arm-common/gic.h
 create mode 100644 tools/kvm/arm/include/arm-common/kvm-arch.h
 create mode 100644 tools/kvm/arm/include/arm-common/smp.h
 create mode 100644 tools/kvm/arm/include/kvm/kvm-cpu-arch.h
 create mode 100644 tools/kvm/arm/ioport.c
 create mode 100644 tools/kvm/arm/irq.c
 create mode 100644 tools/kvm/arm/kvm-cpu.c
 create mode 100644 tools/kvm/arm/kvm.c
 create mode 100644 tools/kvm/arm/smp.c

diff --git a/tools/kvm/Makefile b/tools/kvm/Makefile
index 5da416f..2c9c19e 100644
--- a/tools/kvm/Makefile
+++ b/tools/kvm/Makefile
@@ -102,7 +102,8 @@ OBJS	+= builtin-sandbox.o
 OBJS	+= virtio/mmio.o
 
 # Translate uname -m into ARCH string
-ARCH ?= $(shell uname -m | sed -e s/i.86/i386/ -e s/ppc.*/powerpc/)
+ARCH ?= $(shell uname -m | sed -e s/i.86/i386/ -e s/ppc.*/powerpc/ \
+	  -e s/armv7.*/arm/)
 
 ifeq ($(ARCH),i386)
 	ARCH         := x86
@@ -157,6 +158,23 @@ ifeq ($(ARCH), powerpc)
 	CFLAGS 	+= -m64
 endif
 
+# ARM
+OBJS_ARM_COMMON		:= arm/fdt.o arm/gic.o arm/ioport.o arm/irq.o \
+			   arm/kvm.o arm/kvm-cpu.o arm/smp.o
+HDRS_ARM_COMMON		:= arm/include
+ifeq ($(ARCH), arm)
+	DEFINES		+= -DCONFIG_ARM
+	OBJS		+= $(OBJS_ARM_COMMON)
+	OBJS		+= arm/aarch32/cortex-a15.o
+	OBJS		+= arm/aarch32/kvm-cpu.o
+	OTHEROBJS       += arm/aarch32/smp-pen.o
+	ARCH_INCLUDE	:= $(HDRS_ARM_COMMON)
+	ARCH_INCLUDE	+= -Iarm/aarch32/include
+	CFLAGS		+= -march=armv7-a
+	CFLAGS		+= -I../../scripts/dtc/libfdt
+	OTHEROBJS	+= $(LIBFDT_OBJS)
+endif
+
 ###
 
 ifeq (,$(ARCH_INCLUDE))
diff --git a/tools/kvm/arm/aarch32/cortex-a15.c b/tools/kvm/arm/aarch32/cortex-a15.c
new file mode 100644
index 0000000..eac0bb9
--- /dev/null
+++ b/tools/kvm/arm/aarch32/cortex-a15.c
@@ -0,0 +1,98 @@
+#include "kvm/fdt.h"
+#include "kvm/kvm.h"
+#include "kvm/kvm-cpu.h"
+#include "kvm/util.h"
+
+#include "arm-common/gic.h"
+
+#include <linux/byteorder.h>
+#include <linux/types.h>
+
+#define CPU_NAME_MAX_LEN 8
+static void generate_cpu_nodes(void *fdt, struct kvm *kvm)
+{
+	int cpu;
+
+	_FDT(fdt_begin_node(fdt, "cpus"));
+	_FDT(fdt_property_cell(fdt, "#address-cells", 0x1));
+	_FDT(fdt_property_cell(fdt, "#size-cells", 0x0));
+
+	for (cpu = 0; cpu < kvm->nrcpus; ++cpu) {
+		char cpu_name[CPU_NAME_MAX_LEN];
+
+		if (kvm->cpus[cpu]->cpu_type != KVM_ARM_TARGET_CORTEX_A15) {
+			pr_warning("Ignoring unknown type for CPU %d\n", cpu);
+			continue;
+		}
+
+		snprintf(cpu_name, CPU_NAME_MAX_LEN, "cpu@%d", cpu);
+
+		_FDT(fdt_begin_node(fdt, cpu_name));
+		_FDT(fdt_property_string(fdt, "device_type", "cpu"));
+		_FDT(fdt_property_string(fdt, "compatible", "arm,cortex-a15"));
+
+		if (kvm->nrcpus > 1) {
+			_FDT(fdt_property_string(fdt, "enable-method",
+						 "spin-table"));
+			_FDT(fdt_property_cell(fdt, "cpu-release-addr",
+					       kvm->arch.smp_jump_guest_start));
+		}
+
+		_FDT(fdt_property_cell(fdt, "reg", cpu));
+		_FDT(fdt_end_node(fdt));
+	}
+
+	_FDT(fdt_end_node(fdt));
+}
+
+static void generate_timer_nodes(void *fdt, struct kvm *kvm)
+{
+	u32 cpu_mask = (((1 << kvm->nrcpus) - 1) << GIC_FDT_IRQ_PPI_CPU_SHIFT) \
+		       & GIC_FDT_IRQ_PPI_CPU_MASK;
+	u32 irq_prop[] = {
+		cpu_to_fdt32(GIC_FDT_IRQ_TYPE_PPI),
+		cpu_to_fdt32(13),
+		cpu_to_fdt32(cpu_mask | GIC_FDT_IRQ_FLAGS_EDGE_LO_HI),
+
+		cpu_to_fdt32(GIC_FDT_IRQ_TYPE_PPI),
+		cpu_to_fdt32(14),
+		cpu_to_fdt32(cpu_mask | GIC_FDT_IRQ_FLAGS_EDGE_LO_HI),
+
+		cpu_to_fdt32(GIC_FDT_IRQ_TYPE_PPI),
+		cpu_to_fdt32(11),
+		cpu_to_fdt32(cpu_mask | GIC_FDT_IRQ_FLAGS_EDGE_LO_HI),
+
+		cpu_to_fdt32(GIC_FDT_IRQ_TYPE_PPI),
+		cpu_to_fdt32(10),
+		cpu_to_fdt32(cpu_mask | GIC_FDT_IRQ_FLAGS_EDGE_LO_HI),
+	};
+
+	_FDT(fdt_begin_node(fdt, "timer"));
+	_FDT(fdt_property_string(fdt, "compatible", "arm,armv7-timer"));
+	_FDT(fdt_property(fdt, "interrupts", irq_prop, sizeof(irq_prop)));
+	_FDT(fdt_end_node(fdt));
+}
+
+static void generate_fdt_nodes(void *fdt, struct kvm *kvm, u32 gic_phandle)
+{
+	generate_cpu_nodes(fdt, kvm);
+	gic__generate_fdt_nodes(fdt, gic_phandle);
+	generate_timer_nodes(fdt, kvm);
+}
+
+static int cortex_a15__vcpu_init(struct kvm_cpu *vcpu)
+{
+	vcpu->generate_fdt_nodes = generate_fdt_nodes;
+	return 0;
+}
+
+static struct kvm_arm_target target_cortex_a15 = {
+	.id	= KVM_ARM_TARGET_CORTEX_A15,
+	.init	= cortex_a15__vcpu_init,
+};
+
+static int cortex_a15__core_init(struct kvm *kvm)
+{
+	return kvm_cpu__register_kvm_arm_target(&target_cortex_a15);
+}
+core_init(cortex_a15__core_init);
diff --git a/tools/kvm/arm/aarch32/include/kvm/barrier.h b/tools/kvm/arm/aarch32/include/kvm/barrier.h
new file mode 100644
index 0000000..ee8e643
--- /dev/null
+++ b/tools/kvm/arm/aarch32/include/kvm/barrier.h
@@ -0,0 +1,10 @@
+#ifndef KVM__KVM_BARRIER_H
+#define KVM__KVM_BARRIER_H
+
+#define dmb()	asm volatile ("dmb" : : : "memory")
+
+#define mb()	dmb()
+#define rmb()	dmb()
+#define wmb()	dmb()
+
+#endif
diff --git a/tools/kvm/arm/aarch32/include/kvm/kvm-arch.h b/tools/kvm/arm/aarch32/include/kvm/kvm-arch.h
new file mode 100644
index 0000000..eb51917
--- /dev/null
+++ b/tools/kvm/arm/aarch32/include/kvm/kvm-arch.h
@@ -0,0 +1,28 @@
+#ifndef KVM__KVM_ARCH_H
+#define KVM__KVM_ARCH_H
+
+#define ARM_LOMAP_MMIO_AREA	0x00000000UL
+#define ARM_LOMAP_AXI_AREA	0x40000000UL
+#define ARM_LOMAP_MEMORY_AREA	0x80000000UL
+#define ARM_LOMAP_MAX_MEMORY	0x7ffff000UL
+
+#define ARM_GIC_DIST_SIZE	0x1000
+#define ARM_GIC_DIST_BASE	(ARM_LOMAP_AXI_AREA - ARM_GIC_DIST_SIZE)
+#define ARM_GIC_CPUI_SIZE	0x2000
+#define ARM_GIC_CPUI_BASE	(ARM_GIC_DIST_BASE - ARM_GIC_CPUI_SIZE)
+
+#define ARM_KERN_OFFSET		0x8000
+
+#define ARM_SMP_PEN_SIZE	PAGE_SIZE
+#define ARM_VIRTIO_MMIO_SIZE	(ARM_GIC_DIST_BASE - ARM_LOMAP_MMIO_AREA)
+#define ARM_PCI_MMIO_SIZE	(ARM_LOMAP_MEMORY_AREA - ARM_LOMAP_AXI_AREA)
+
+#define ARM_MEMORY_AREA		ARM_LOMAP_MEMORY_AREA
+#define ARM_MAX_MEMORY		ARM_LOMAP_MAX_MEMORY
+
+#define KVM_PCI_MMIO_AREA	ARM_LOMAP_AXI_AREA
+#define KVM_VIRTIO_MMIO_AREA	ARM_LOMAP_MMIO_AREA
+
+#include "arm-common/kvm-arch.h"
+
+#endif
diff --git a/tools/kvm/arm/aarch32/kvm-cpu.c b/tools/kvm/arm/aarch32/kvm-cpu.c
new file mode 100644
index 0000000..f00a2f1
--- /dev/null
+++ b/tools/kvm/arm/aarch32/kvm-cpu.c
@@ -0,0 +1,111 @@
+#include "kvm/kvm-cpu.h"
+#include "kvm/kvm.h"
+
+#include <asm/ptrace.h>
+
+#define ARM_CORE_REG(x)	(KVM_REG_ARM | KVM_REG_SIZE_U32 | KVM_REG_ARM_CORE | \
+			 KVM_REG_ARM_CORE_REG(x))
+
+void kvm_cpu__reset_vcpu(struct kvm_cpu *vcpu)
+{
+	struct kvm *kvm	= vcpu->kvm;
+	struct kvm_one_reg reg;
+	u32 data;
+
+	/* Who said future-proofing was a good idea? */
+	reg.addr = (u64)(unsigned long)&data;
+
+	/* cpsr = IRQs/FIQs masked */
+	data	= PSR_I_BIT | PSR_F_BIT | SVC_MODE;
+	reg.id	= ARM_CORE_REG(usr_regs.ARM_cpsr);
+	if (ioctl(vcpu->vcpu_fd, KVM_SET_ONE_REG, &reg) < 0)
+		die_perror("KVM_SET_ONE_REG failed (cpsr)");
+
+	if (vcpu->cpu_id == 0) {
+		/* r0 = 0 */
+		data	= 0;
+		reg.id	= ARM_CORE_REG(usr_regs.ARM_r0);
+		if (ioctl(vcpu->vcpu_fd, KVM_SET_ONE_REG, &reg) < 0)
+			die_perror("KVM_SET_ONE_REG failed (r0)");
+
+		/* r1 = machine type (-1) */
+		data	= -1;
+		reg.id	= ARM_CORE_REG(usr_regs.ARM_r1);
+		if (ioctl(vcpu->vcpu_fd, KVM_SET_ONE_REG, &reg) < 0)
+			die_perror("KVM_SET_ONE_REG failed (r1)");
+
+		/* r2 = physical address of the device tree blob */
+		data	= kvm->arch.dtb_guest_start;
+		reg.id	= ARM_CORE_REG(usr_regs.ARM_r2);
+		if (ioctl(vcpu->vcpu_fd, KVM_SET_ONE_REG, &reg) < 0)
+			die_perror("KVM_SET_ONE_REG failed (r2)");
+
+		/* pc = start of kernel image */
+		data	= kvm->arch.kern_guest_start;
+		reg.id	= ARM_CORE_REG(usr_regs.ARM_pc);
+		if (ioctl(vcpu->vcpu_fd, KVM_SET_ONE_REG, &reg) < 0)
+			die_perror("KVM_SET_ONE_REG failed (pc)");
+
+	} else {
+		/* Simply enter the pen */
+		data	= kvm->arch.smp_pen_guest_start;
+		reg.id	= ARM_CORE_REG(usr_regs.ARM_pc);
+		if (ioctl(vcpu->vcpu_fd, KVM_SET_ONE_REG, &reg) < 0)
+			die_perror("KVM_SET_ONE_REG failed (SMP pc)");
+	}
+}
+
+void kvm_cpu__show_code(struct kvm_cpu *vcpu)
+{
+	struct kvm_one_reg reg;
+	u32 data;
+
+	reg.addr = (u64)(unsigned long)&data;
+
+	printf("*pc:\n");
+	reg.id = ARM_CORE_REG(usr_regs.ARM_pc);
+	if (ioctl(vcpu->vcpu_fd, KVM_GET_ONE_REG, &reg) < 0)
+		die("KVM_GET_ONE_REG failed (show_code @ PC)");
+
+	kvm__dump_mem(vcpu->kvm, data, 32);
+	printf("\n");
+
+	printf("*lr (svc):\n");
+	reg.id = ARM_CORE_REG(svc_regs[1]);
+	if (ioctl(vcpu->vcpu_fd, KVM_GET_ONE_REG, &reg) < 0)
+		die("KVM_GET_ONE_REG failed (show_code @ LR_svc)");
+	data &= ~0x1;
+
+	kvm__dump_mem(vcpu->kvm, data, 32);
+	printf("\n");
+}
+
+void kvm_cpu__show_registers(struct kvm_cpu *vcpu)
+{
+	struct kvm_one_reg reg;
+	u32 data;
+	int debug_fd = kvm_cpu__get_debug_fd();
+
+	reg.addr	= (u64)(unsigned long)&data;
+	dprintf(debug_fd, "\n Registers:\n");
+
+	reg.id		= ARM_CORE_REG(usr_regs.ARM_pc);
+	if (ioctl(vcpu->vcpu_fd, KVM_GET_ONE_REG, &reg) < 0)
+		die("KVM_GET_ONE_REG failed (pc)");
+	dprintf(debug_fd, " PC:    0x%x\n", data);
+
+	reg.id		= ARM_CORE_REG(usr_regs.ARM_cpsr);
+	if (ioctl(vcpu->vcpu_fd, KVM_GET_ONE_REG, &reg) < 0)
+		die("KVM_GET_ONE_REG failed (cpsr)");
+	dprintf(debug_fd, " CPSR:  0x%x\n", data);
+
+	reg.id		= ARM_CORE_REG(svc_regs[0]);
+	if (ioctl(vcpu->vcpu_fd, KVM_GET_ONE_REG, &reg) < 0)
+		die("KVM_GET_ONE_REG failed (SP_svc)");
+	dprintf(debug_fd, " SP_svc:  0x%x\n", data);
+
+	reg.id		= ARM_CORE_REG(svc_regs[1]);
+	if (ioctl(vcpu->vcpu_fd, KVM_GET_ONE_REG, &reg) < 0)
+		die("KVM_GET_ONE_REG failed (LR_svc)");
+	dprintf(debug_fd, " LR_svc:  0x%x\n", data);
+}
diff --git a/tools/kvm/arm/aarch32/smp-pen.S b/tools/kvm/arm/aarch32/smp-pen.S
new file mode 100644
index 0000000..5e25753
--- /dev/null
+++ b/tools/kvm/arm/aarch32/smp-pen.S
@@ -0,0 +1,14 @@
+	.arm
+	.globl	smp_pen_start
+	.globl	smp_pen_end
+	.globl	smp_jump_addr
+	.align
+smp_pen_start:
+	adr	r0, smp_jump_addr
+	wfi
+	ldr	r1, [r0]
+	mov	pc, r1
+	.align
+smp_jump_addr:
+	.long	0xdeadc0de
+smp_pen_end:
diff --git a/tools/kvm/arm/fdt.c b/tools/kvm/arm/fdt.c
new file mode 100644
index 0000000..97b92e0
--- /dev/null
+++ b/tools/kvm/arm/fdt.c
@@ -0,0 +1,269 @@
+#include "kvm/devices.h"
+#include "kvm/fdt.h"
+#include "kvm/kvm.h"
+#include "kvm/kvm-cpu.h"
+#include "kvm/virtio-mmio.h"
+
+#include "arm-common/gic.h"
+
+#include <stdbool.h>
+
+#include <asm/setup.h>
+#include <linux/byteorder.h>
+#include <linux/kernel.h>
+#include <linux/sizes.h>
+
+#define DEBUG			0
+#define DEBUG_FDT_DUMP_FILE	"/tmp/kvmtool.dtb"
+
+static char kern_cmdline[COMMAND_LINE_SIZE];
+
+bool kvm__load_firmware(struct kvm *kvm, const char *firmware_filename)
+{
+	return false;
+}
+
+int kvm__arch_setup_firmware(struct kvm *kvm)
+{
+	return 0;
+}
+
+#if DEBUG
+static void dump_fdt(void *fdt)
+{
+	int count, fd;
+
+	fd = open(DEBUG_FDT_DUMP_FILE, O_CREAT | O_TRUNC | O_RDWR, 0666);
+	if (fd < 0)
+		die("Failed to write dtb to %s", DEBUG_FDT_DUMP_FILE);
+
+	count = write(fd, fdt, FDT_MAX_SIZE);
+	if (count < 0)
+		die_perror("Failed to dump dtb");
+
+	pr_info("Wrote %d bytes to dtb %s\n", count, DEBUG_FDT_DUMP_FILE);
+	close(fd);
+}
+#else
+static void dump_fdt(void *fdt) { }
+#endif
+
+#define DEVICE_NAME_MAX_LEN 32
+static void generate_virtio_mmio_node(void *fdt, struct virtio_mmio *vmmio)
+{
+	char dev_name[DEVICE_NAME_MAX_LEN];
+	u64 addr = vmmio->addr;
+	u64 reg_prop[] = {
+		cpu_to_fdt64(addr),
+		cpu_to_fdt64(VIRTIO_MMIO_IO_SIZE)
+	};
+	u32 irq_prop[] = {
+		cpu_to_fdt32(GIC_FDT_IRQ_TYPE_SPI),
+		cpu_to_fdt32(vmmio->irq - GIC_SPI_IRQ_BASE),
+		cpu_to_fdt32(GIC_FDT_IRQ_FLAGS_EDGE_LO_HI),
+	};
+
+	snprintf(dev_name, DEVICE_NAME_MAX_LEN, "virtio@%llx", addr);
+
+	_FDT(fdt_begin_node(fdt, dev_name));
+	_FDT(fdt_property_string(fdt, "compatible", "virtio,mmio"));
+	_FDT(fdt_property(fdt, "reg", reg_prop, sizeof(reg_prop)));
+	_FDT(fdt_property(fdt, "interrupts", irq_prop, sizeof(irq_prop)));
+	_FDT(fdt_end_node(fdt));
+}
+
+static int setup_fdt(struct kvm *kvm)
+{
+	int devid;
+	u8 staging_fdt[FDT_MAX_SIZE];
+	u32 gic_phandle		= fdt__alloc_phandle();
+	u64 mem_reg_prop[]	= {
+		cpu_to_fdt64(kvm->arch.memory_guest_start),
+		cpu_to_fdt64(kvm->ram_size),
+	};
+	void *fdt		= staging_fdt;
+	void *fdt_dest		= guest_flat_to_host(kvm,
+						     kvm->arch.dtb_guest_start);
+	void (*generate_cpu_nodes)(void *, struct kvm *, u32)
+				= kvm->cpus[0]->generate_fdt_nodes;
+
+	/* Create new tree without a reserve map */
+	_FDT(fdt_create(fdt, FDT_MAX_SIZE));
+	if (kvm->nrcpus > 1)
+		_FDT(fdt_add_reservemap_entry(fdt,
+					      kvm->arch.smp_pen_guest_start,
+					      ARM_SMP_PEN_SIZE));
+	_FDT(fdt_finish_reservemap(fdt));
+
+	/* Header */
+	_FDT(fdt_begin_node(fdt, ""));
+	_FDT(fdt_property_cell(fdt, "interrupt-parent", gic_phandle));
+	_FDT(fdt_property_string(fdt, "compatible", "linux,dummy-virt"));
+	_FDT(fdt_property_cell(fdt, "#address-cells", 0x2));
+	_FDT(fdt_property_cell(fdt, "#size-cells", 0x2));
+
+	/* /chosen */
+	_FDT(fdt_begin_node(fdt, "chosen"));
+	_FDT(fdt_property_string(fdt, "bootargs", kern_cmdline));
+
+	/* Initrd */
+	if (kvm->arch.initrd_size != 0) {
+		u32 ird_st_prop = cpu_to_fdt64(kvm->arch.initrd_guest_start);
+		u32 ird_end_prop = cpu_to_fdt64(kvm->arch.initrd_guest_start +
+					       kvm->arch.initrd_size);
+
+		_FDT(fdt_property(fdt, "linux,initrd-start",
+				   &ird_st_prop, sizeof(ird_st_prop)));
+		_FDT(fdt_property(fdt, "linux,initrd-end",
+				   &ird_end_prop, sizeof(ird_end_prop)));
+	}
+	_FDT(fdt_end_node(fdt));
+
+	/* Memory */
+	_FDT(fdt_begin_node(fdt, "memory"));
+	_FDT(fdt_property_string(fdt, "device_type", "memory"));
+	_FDT(fdt_property(fdt, "reg", mem_reg_prop, sizeof(mem_reg_prop)));
+	_FDT(fdt_end_node(fdt));
+
+	/* CPU and peripherals (interrupt controller, timers, etc) */
+	if (generate_cpu_nodes)
+		generate_cpu_nodes(fdt, kvm, gic_phandle);
+
+	/* Virtio MMIO devices */
+	for (devid = 0; devid < KVM_MAX_DEVICES; ++devid) {
+		struct device_header *dev_hdr = device__find_dev(devid);
+
+		if (!dev_hdr || dev_hdr->bus_type != DEVICE_BUS_MMIO)
+			continue;
+
+		generate_virtio_mmio_node(fdt, dev_hdr->data);
+	}
+
+	/* Finalise. */
+	_FDT(fdt_end_node(fdt));
+	_FDT(fdt_finish(fdt));
+
+	_FDT(fdt_open_into(fdt, fdt_dest, FDT_MAX_SIZE));
+	_FDT(fdt_pack(fdt_dest));
+
+	dump_fdt(fdt_dest);
+	return 0;
+}
+firmware_init(setup_fdt);
+
+static int read_image(int fd, void **pos, void *limit)
+{
+	int count;
+
+	while (((count = read(fd, *pos, SZ_64K)) > 0) && *pos <= limit)
+		*pos += count;
+
+	if (pos < 0)
+		die_perror("read");
+
+	return *pos < limit ? 0 : -ENOMEM;
+}
+
+#define FDT_ALIGN	SZ_2M
+#define INITRD_ALIGN	4
+#define SMP_PEN_ALIGN	PAGE_SIZE
+int load_flat_binary(struct kvm *kvm, int fd_kernel, int fd_initrd,
+		     const char *kernel_cmdline)
+{
+	void *pos, *kernel_end, *limit;
+	unsigned long guest_addr;
+
+	if (lseek(fd_kernel, 0, SEEK_SET) < 0)
+		die_perror("lseek");
+
+	/*
+	 * Linux requires the initrd, pen and dtb to be mapped inside
+	 * lowmem, so we can't just place them at the top of memory.
+	 */
+	limit = kvm->ram_start + min(kvm->ram_size, (u64)SZ_256M) - 1;
+
+	pos = kvm->ram_start + ARM_KERN_OFFSET;
+	kvm->arch.kern_guest_start = host_to_guest_flat(kvm, pos);
+	if (read_image(fd_kernel, &pos, limit) == -ENOMEM)
+		die("kernel image too big to contain in guest memory.");
+
+	kernel_end = pos;
+	pr_info("Loaded kernel to 0x%lx (%ld bytes)",
+		kvm->arch.kern_guest_start,
+		host_to_guest_flat(kvm, pos) - kvm->arch.kern_guest_start);
+
+	/*
+	 * Now load backwards from the end of memory so the kernel
+	 * decompressor has plenty of space to work with. First up is
+	 * the SMP pen if we have more than one virtual CPU...
+	 */
+	pos = limit;
+	if (kvm->cfg.nrcpus > 1) {
+		pos -= (ARM_SMP_PEN_SIZE + SMP_PEN_ALIGN);
+		guest_addr = ALIGN(host_to_guest_flat(kvm, pos), SMP_PEN_ALIGN);
+		pos = guest_flat_to_host(kvm, guest_addr);
+		if (pos < kernel_end)
+			die("SMP pen overlaps with kernel image.");
+
+		kvm->arch.smp_pen_guest_start = guest_addr;
+		pr_info("Placing SMP pen at 0x%lx - 0x%lx",
+			kvm->arch.smp_pen_guest_start,
+			host_to_guest_flat(kvm, limit));
+		limit = pos;
+	}
+
+	/* ...now the device tree blob... */
+	pos -= (FDT_MAX_SIZE + FDT_ALIGN);
+	guest_addr = ALIGN(host_to_guest_flat(kvm, pos), FDT_ALIGN);
+	pos = guest_flat_to_host(kvm, guest_addr);
+	if (pos < kernel_end)
+		die("fdt overlaps with kernel image.");
+
+	kvm->arch.dtb_guest_start = guest_addr;
+	pr_info("Placing fdt at 0x%lx - 0x%lx",
+		kvm->arch.dtb_guest_start,
+		host_to_guest_flat(kvm, limit));
+	limit = pos;
+
+	/* ... and finally the initrd, if we have one. */
+	if (fd_initrd != -1) {
+		struct stat sb;
+		unsigned long initrd_start;
+
+		if (lseek(fd_initrd, 0, SEEK_SET) < 0)
+			die_perror("lseek");
+
+		if (fstat(fd_initrd, &sb))
+			die_perror("fstat");
+
+		pos -= (sb.st_size + INITRD_ALIGN);
+		guest_addr = ALIGN(host_to_guest_flat(kvm, pos), INITRD_ALIGN);
+		pos = guest_flat_to_host(kvm, guest_addr);
+		if (pos < kernel_end)
+			die("initrd overlaps with kernel image.");
+
+		initrd_start = guest_addr;
+		if (read_image(fd_initrd, &pos, limit) == -ENOMEM)
+			die("initrd too big to contain in guest memory.");
+
+		kvm->arch.initrd_guest_start = initrd_start;
+		kvm->arch.initrd_size = host_to_guest_flat(kvm, pos) - initrd_start;
+		pr_info("Loaded initrd to 0x%lx (%ld bytes)",
+			kvm->arch.initrd_guest_start,
+			kvm->arch.initrd_size);
+	} else {
+		kvm->arch.initrd_size = 0;
+	}
+
+	strncpy(kern_cmdline, kernel_cmdline, COMMAND_LINE_SIZE);
+	kern_cmdline[COMMAND_LINE_SIZE - 1] = '\0';
+
+	return true;
+}
+
+bool load_bzimage(struct kvm *kvm, int fd_kernel,
+		  int fd_initrd, const char *kernel_cmdline, u16 vidmode)
+{
+	/* To b or not to b? That is the zImage. */
+	return false;
+}
diff --git a/tools/kvm/arm/gic.c b/tools/kvm/arm/gic.c
new file mode 100644
index 0000000..f5fa7c7
--- /dev/null
+++ b/tools/kvm/arm/gic.c
@@ -0,0 +1,86 @@
+#include "kvm/fdt.h"
+#include "kvm/kvm.h"
+#include "kvm/virtio.h"
+
+#include "arm-common/gic.h"
+
+#include <linux/byteorder.h>
+#include <linux/kvm.h>
+
+static int irq_ids;
+
+int gic__alloc_irqnum(void)
+{
+	int irq = GIC_SPI_IRQ_BASE + irq_ids++;
+
+	if (irq > KVM_MAX_IRQ)
+		die("IRQ limit %d reached!", KVM_MAX_IRQ);
+
+	return irq;
+}
+
+int gic__init_irqchip(struct kvm *kvm)
+{
+	int err;
+	struct kvm_device_address gic_addr[] = {
+		[0] = {
+			.id = (KVM_ARM_DEVICE_VGIC_V2 << KVM_DEVICE_ID_SHIFT) |\
+			       KVM_VGIC_V2_ADDR_TYPE_DIST,
+			.addr = ARM_GIC_DIST_BASE,
+		},
+		[1] = {
+			.id = (KVM_ARM_DEVICE_VGIC_V2 << KVM_DEVICE_ID_SHIFT) |\
+			       KVM_VGIC_V2_ADDR_TYPE_CPU,
+			.addr = ARM_GIC_CPUI_BASE,
+		}
+	};
+
+	err = ioctl(kvm->vm_fd, KVM_CREATE_IRQCHIP);
+	if (err)
+		return err;
+
+	err = ioctl(kvm->vm_fd, KVM_SET_DEVICE_ADDRESS, &gic_addr[0]);
+	if (err)
+		return err;
+
+	err = ioctl(kvm->vm_fd, KVM_SET_DEVICE_ADDRESS, &gic_addr[1]);
+	return err;
+}
+
+void gic__generate_fdt_nodes(void *fdt, u32 phandle)
+{
+	u64 reg_prop[] = {
+		cpu_to_fdt64(ARM_GIC_DIST_BASE), cpu_to_fdt64(ARM_GIC_DIST_SIZE),
+		cpu_to_fdt64(ARM_GIC_CPUI_BASE), cpu_to_fdt64(ARM_GIC_CPUI_SIZE),
+	};
+
+	_FDT(fdt_begin_node(fdt, "intc"));
+	_FDT(fdt_property_string(fdt, "compatible", "arm,cortex-a15-gic"));
+	_FDT(fdt_property_cell(fdt, "#interrupt-cells", GIC_FDT_IRQ_NUM_CELLS));
+	_FDT(fdt_property(fdt, "interrupt-controller", NULL, 0));
+	_FDT(fdt_property(fdt, "reg", reg_prop, sizeof(reg_prop)));
+	_FDT(fdt_property_cell(fdt, "phandle", phandle));
+	_FDT(fdt_end_node(fdt));
+}
+
+#define KVM_IRQCHIP_IRQ(x) (KVM_ARM_IRQ_TYPE_SPI << KVM_ARM_IRQ_TYPE_SHIFT) |\
+			   ((x) & KVM_ARM_IRQ_NUM_MASK)
+
+void kvm__irq_line(struct kvm *kvm, int irq, int level)
+{
+	struct kvm_irq_level irq_level = {
+		.irq	= KVM_IRQCHIP_IRQ(irq),
+		.level	= !!level,
+	};
+
+	if (irq < GIC_SPI_IRQ_BASE || irq > KVM_MAX_IRQ)
+		pr_warning("Ignoring invalid GIC IRQ %d", irq);
+	else if (ioctl(kvm->vm_fd, KVM_IRQ_LINE, &irq_level) < 0)
+		pr_warning("Could not KVM_IRQ_LINE for irq %d", irq);
+}
+
+void kvm__irq_trigger(struct kvm *kvm, int irq)
+{
+	kvm__irq_line(kvm, irq, VIRTIO_IRQ_HIGH);
+	kvm__irq_line(kvm, irq, VIRTIO_IRQ_LOW);
+}
diff --git a/tools/kvm/arm/include/arm-common/gic.h b/tools/kvm/arm/include/arm-common/gic.h
new file mode 100644
index 0000000..4d85dd9
--- /dev/null
+++ b/tools/kvm/arm/include/arm-common/gic.h
@@ -0,0 +1,29 @@
+#ifndef ARM_COMMON__GIC_H
+#define ARM_COMMON__GIC_H
+
+#define GIC_SGI_IRQ_BASE		0
+#define GIC_PPI_IRQ_BASE		16
+#define GIC_SPI_IRQ_BASE		32
+
+#define GIC_FDT_IRQ_NUM_CELLS		3
+
+#define GIC_FDT_IRQ_TYPE_SPI		0
+#define GIC_FDT_IRQ_TYPE_PPI		1
+
+#define GIC_FDT_IRQ_FLAGS_EDGE_LO_HI	1
+#define GIC_FDT_IRQ_FLAGS_EDGE_HI_LO	2
+#define GIC_FDT_IRQ_FLAGS_LEVEL_HI	4
+#define GIC_FDT_IRQ_FLAGS_LEVEL_LO	8
+
+#define GIC_FDT_IRQ_PPI_CPU_SHIFT	8
+#define GIC_FDT_IRQ_PPI_CPU_MASK	(0xff << GIC_FDT_IRQ_PPI_CPU_SHIFT)
+
+#define KVM_MAX_IRQ			255
+
+struct kvm;
+
+int gic__alloc_irqnum(void);
+int gic__init_irqchip(struct kvm *kvm);
+void gic__generate_fdt_nodes(void *fdt, u32 phandle);
+
+#endif /* ARM_COMMON__GIC_H */
diff --git a/tools/kvm/arm/include/arm-common/kvm-arch.h b/tools/kvm/arm/include/arm-common/kvm-arch.h
new file mode 100644
index 0000000..0b20437
--- /dev/null
+++ b/tools/kvm/arm/include/arm-common/kvm-arch.h
@@ -0,0 +1,31 @@
+#ifndef ARM_COMMON__KVM_ARCH_H
+#define ARM_COMMON__KVM_ARCH_H
+
+#include <stdbool.h>
+#include <linux/types.h>
+
+#define VIRTIO_DEFAULT_TRANS	VIRTIO_MMIO
+
+static inline bool arm_addr_in_virtio_mmio_region(u64 phys_addr)
+{
+	u64 limit = KVM_VIRTIO_MMIO_AREA + ARM_VIRTIO_MMIO_SIZE;
+	return phys_addr >= KVM_VIRTIO_MMIO_AREA && phys_addr < limit;
+}
+
+static inline bool arm_addr_in_pci_mmio_region(u64 phys_addr)
+{
+	u64 limit = KVM_PCI_MMIO_AREA + ARM_PCI_MMIO_SIZE;
+	return phys_addr >= KVM_PCI_MMIO_AREA && phys_addr < limit;
+}
+
+struct kvm_arch {
+	unsigned long	memory_guest_start;
+	unsigned long	kern_guest_start;
+	unsigned long	initrd_guest_start;
+	unsigned long	initrd_size;
+	unsigned long	dtb_guest_start;
+	unsigned long	smp_pen_guest_start;
+	unsigned long	smp_jump_guest_start;
+};
+
+#endif /* ARM_COMMON__KVM_ARCH_H */
diff --git a/tools/kvm/arm/include/arm-common/smp.h b/tools/kvm/arm/include/arm-common/smp.h
new file mode 100644
index 0000000..993a3e6
--- /dev/null
+++ b/tools/kvm/arm/include/arm-common/smp.h
@@ -0,0 +1,7 @@
+#ifndef ARM_COMMON__SMP_H
+#define ARM_COMMON__SMP_H
+
+extern u8 smp_pen_start, smp_pen_end, smp_jump_addr;
+void smp_pen_init(struct kvm *kvm);
+
+#endif /* ARM_COMMON__SMP_H */
diff --git a/tools/kvm/arm/include/kvm/kvm-cpu-arch.h b/tools/kvm/arm/include/kvm/kvm-cpu-arch.h
new file mode 100644
index 0000000..d4618e9
--- /dev/null
+++ b/tools/kvm/arm/include/kvm/kvm-cpu-arch.h
@@ -0,0 +1,47 @@
+#ifndef ARM_COMMON__KVM_CPU_ARCH_H
+#define ARM_COMMON__KVM_CPU_ARCH_H
+
+#include <linux/kvm.h>
+#include <pthread.h>
+#include <stdbool.h>
+
+struct kvm;
+
+struct kvm_cpu {
+	pthread_t	thread;
+
+	unsigned long	cpu_id;
+	unsigned long	cpu_type;
+
+	struct kvm	*kvm;
+	int		vcpu_fd;
+	struct kvm_run	*kvm_run;
+
+	u8		is_running;
+	u8		paused;
+	u8		needs_nmi;
+
+	struct kvm_coalesced_mmio_ring	*ring;
+
+	void		(*generate_fdt_nodes)(void *fdt, struct kvm* kvm,
+					      u32 gic_phandle);
+};
+
+struct kvm_arm_target {
+	u32	id;
+	int	(*init)(struct kvm_cpu *vcpu);
+};
+
+int kvm_cpu__register_kvm_arm_target(struct kvm_arm_target *target);
+
+static inline bool kvm_cpu__emulate_io(struct kvm *kvm, u16 port, void *data,
+				       int direction, int size, u32 count)
+{
+	return false;
+}
+
+bool kvm_cpu__emulate_mmio(struct kvm *kvm, u64 phys_addr, u8 *data, u32 len,
+			   u8 is_write);
+
+#endif /* ARM_COMMON__KVM_CPU_ARCH_H */
+
diff --git a/tools/kvm/arm/ioport.c b/tools/kvm/arm/ioport.c
new file mode 100644
index 0000000..3c03fa0
--- /dev/null
+++ b/tools/kvm/arm/ioport.c
@@ -0,0 +1,5 @@
+#include "kvm/ioport.h"
+
+void ioport__setup_arch(struct kvm *kvm)
+{
+}
diff --git a/tools/kvm/arm/irq.c b/tools/kvm/arm/irq.c
new file mode 100644
index 0000000..a17c722
--- /dev/null
+++ b/tools/kvm/arm/irq.c
@@ -0,0 +1,25 @@
+#include "kvm/devices.h"
+#include "kvm/irq.h"
+#include "kvm/kvm.h"
+#include "kvm/util.h"
+
+#include "arm-common/gic.h"
+
+static int device_ids;
+
+int irq__register_device(u32 dev, u8 *num, u8 *pin, u8 *line)
+{
+	if (device_ids >= KVM_MAX_DEVICES)
+		die("Device limit %d reached!", KVM_MAX_DEVICES);
+
+	*num	= device_ids++;
+	*line	= gic__alloc_irqnum();
+
+	return 0;
+}
+
+int irq__add_msix_route(struct kvm *kvm, struct msi_msg *msg)
+{
+	die(__FUNCTION__);
+	return 0;
+}
diff --git a/tools/kvm/arm/kvm-cpu.c b/tools/kvm/arm/kvm-cpu.c
new file mode 100644
index 0000000..f659118
--- /dev/null
+++ b/tools/kvm/arm/kvm-cpu.c
@@ -0,0 +1,112 @@
+#include "kvm/kvm.h"
+#include "kvm/kvm-cpu.h"
+
+#include "arm-common/smp.h"
+
+static int debug_fd;
+
+void kvm_cpu__set_debug_fd(int fd)
+{
+	debug_fd = fd;
+}
+
+int kvm_cpu__get_debug_fd(void)
+{
+	return debug_fd;
+}
+
+static struct kvm_arm_target *kvm_arm_targets[KVM_ARM_NUM_TARGETS];
+int kvm_cpu__register_kvm_arm_target(struct kvm_arm_target *target)
+{
+	unsigned int i = 0;
+
+	for (i = 0; i < ARRAY_SIZE(kvm_arm_targets); ++i) {
+		if (!kvm_arm_targets[i]) {
+			kvm_arm_targets[i] = target;
+			return 0;
+		}
+	}
+
+	return -ENOSPC;
+}
+
+struct kvm_cpu *kvm_cpu__arch_init(struct kvm *kvm, unsigned long cpu_id)
+{
+	struct kvm_cpu *vcpu;
+	int coalesced_offset, mmap_size, err = -1;
+	unsigned int i;
+	struct kvm_vcpu_init vcpu_init = { };
+
+	vcpu = calloc(1, sizeof(struct kvm_cpu));
+	if (!vcpu)
+		return NULL;
+
+	vcpu->vcpu_fd = ioctl(kvm->vm_fd, KVM_CREATE_VCPU, cpu_id);
+	if (vcpu->vcpu_fd < 0)
+		die_perror("KVM_CREATE_VCPU ioctl");
+
+	mmap_size = ioctl(kvm->sys_fd, KVM_GET_VCPU_MMAP_SIZE, 0);
+	if (mmap_size < 0)
+		die_perror("KVM_GET_VCPU_MMAP_SIZE ioctl");
+
+	vcpu->kvm_run = mmap(NULL, mmap_size, PROT_RW, MAP_SHARED,
+			     vcpu->vcpu_fd, 0);
+	if (vcpu->kvm_run == MAP_FAILED)
+		die("unable to mmap vcpu fd");
+
+	/* Find an appropriate target CPU type. */
+	for (i = 0; i < ARRAY_SIZE(kvm_arm_targets); ++i) {
+		vcpu_init.target = kvm_arm_targets[i]->id;
+		err = ioctl(vcpu->vcpu_fd, KVM_ARM_VCPU_INIT, &vcpu_init);
+		if (!err)
+			break;
+	}
+
+	if (err || kvm_arm_targets[i]->init(vcpu))
+		die("Unable to initialise ARM vcpu");
+
+	coalesced_offset = ioctl(kvm->sys_fd, KVM_CHECK_EXTENSION,
+				 KVM_CAP_COALESCED_MMIO);
+	if (coalesced_offset)
+		vcpu->ring = (void *)vcpu->kvm_run +
+			     (coalesced_offset * PAGE_SIZE);
+
+	if (cpu_id != 0)
+		smp_pen_init(kvm);
+
+	/* Populate the vcpu structure. */
+	vcpu->kvm		= kvm;
+	vcpu->cpu_id		= cpu_id;
+	vcpu->cpu_type		= vcpu_init.target;
+	vcpu->is_running	= true;
+	return vcpu;
+}
+
+void kvm_cpu__arch_nmi(struct kvm_cpu *cpu)
+{
+}
+
+void kvm_cpu__delete(struct kvm_cpu *vcpu)
+{
+	free(vcpu);
+}
+
+bool kvm_cpu__handle_exit(struct kvm_cpu *vcpu)
+{
+	return false;
+}
+
+bool kvm_cpu__emulate_mmio(struct kvm *kvm, u64 phys_addr, u8 *data, u32 len,
+			   u8 is_write)
+{
+	if (arm_addr_in_virtio_mmio_region(phys_addr))
+		return kvm__emulate_mmio(kvm, phys_addr, data, len, is_write);
+	else if (arm_addr_in_pci_mmio_region(phys_addr))
+		die("PCI emulation not supported on ARM!");
+
+	return false;
+}
+
+void kvm_cpu__show_page_tables(struct kvm_cpu *vcpu)
+{
+}
diff --git a/tools/kvm/arm/kvm.c b/tools/kvm/arm/kvm.c
new file mode 100644
index 0000000..aa2673a
--- /dev/null
+++ b/tools/kvm/arm/kvm.c
@@ -0,0 +1,69 @@
+#include "kvm/kvm.h"
+#include "kvm/term.h"
+#include "kvm/util.h"
+#include "kvm/virtio-console.h"
+
+#include "arm-common/gic.h"
+
+#include <linux/kernel.h>
+#include <linux/kvm.h>
+
+struct kvm_ext kvm_req_ext[] = {
+	{ DEFINE_KVM_EXT(KVM_CAP_IRQCHIP) },
+	{ DEFINE_KVM_EXT(KVM_CAP_ONE_REG) },
+	{ 0, 0 },
+};
+
+bool kvm__arch_cpu_supports_vm(void)
+{
+	/* The KVM capability check is enough. */
+	return true;
+}
+
+void kvm__init_ram(struct kvm *kvm)
+{
+	int err;
+	u64 phys_start, phys_size;
+	void *host_mem;
+
+	phys_start	= ARM_MEMORY_AREA;
+	phys_size	= kvm->ram_size;
+	host_mem	= kvm->ram_start;
+
+	err = kvm__register_mem(kvm, phys_start, phys_size, host_mem);
+	if (err)
+		die("Failed to register %lld bytes of memory at physical "
+		    "address 0x%llx [err %d]", phys_size, phys_start, err);
+
+	kvm->arch.memory_guest_start = phys_start;
+}
+
+void kvm__arch_delete_ram(struct kvm *kvm)
+{
+	munmap(kvm->ram_start, kvm->ram_size);
+}
+
+void kvm__arch_periodic_poll(struct kvm *kvm)
+{
+	if (term_readable(0))
+		virtio_console__inject_interrupt(kvm);
+}
+
+void kvm__arch_set_cmdline(char *cmdline, bool video)
+{
+}
+
+void kvm__arch_init(struct kvm *kvm, const char *hugetlbfs_path, u64 ram_size)
+{
+	/* Allocate guest memory. */
+	kvm->ram_size = min(ram_size, (u64)ARM_MAX_MEMORY);
+	kvm->ram_start = mmap_anon_or_hugetlbfs(kvm, NULL, kvm->ram_size);
+	if (kvm->ram_start == MAP_FAILED)
+		die("Failed to map %lld bytes for guest memory (%d)",
+		    kvm->ram_size, errno);
+	madvise(kvm->ram_start, kvm->ram_size, MADV_MERGEABLE);
+
+	/* Initialise the virtual GIC. */
+	if (gic__init_irqchip(kvm))
+		die("Failed to initialise virtual GIC");
+}
diff --git a/tools/kvm/arm/smp.c b/tools/kvm/arm/smp.c
new file mode 100644
index 0000000..73e58bd
--- /dev/null
+++ b/tools/kvm/arm/smp.c
@@ -0,0 +1,13 @@
+#include "kvm/kvm.h"
+
+#include "arm-common/smp.h"
+
+void smp_pen_init(struct kvm *kvm)
+{
+	unsigned long pen_size = &smp_pen_end - &smp_pen_start;
+	unsigned long pen_start = kvm->arch.smp_pen_guest_start;
+	unsigned long jump_offset = &smp_jump_addr - &smp_pen_start;
+
+	kvm->arch.smp_jump_guest_start = pen_start + jump_offset;
+	memcpy(guest_flat_to_host(kvm, pen_start), &smp_pen_start, pen_size);
+}
-- 
1.7.4.1

Re: [RFC PATCH 16/16] kvm tools: add support for ARMv7 processors

[Pekka Enberg]

On Mon, 12 Nov 2012, Will Deacon wrote:
> This patch adds initial support for ARMv7 processors (more specifically,
> Cortex-A15) to kvmtool.
> 
> Everything is driven by FDT, including dynamic generation of virtio nodes
> for MMIO devices (PCI is not used due to lack of a suitable host-bridge).
> 
> The virtual timers and virtual interrupt controller (VGIC) are provided
> by the kernel and require very little in terms of userspace code.
> 
> Signed-off-by: Will Deacon <will.deacon@arm.com>

I'm happy with this but I'm not really an ARM guy. Is there anyone in the 
ARM/KVM community who is interested in reviewing this?

			Pekka

RE: [RFC PATCH 16/16] kvm tools: add support for ARMv7 processors

[Matt Evans]

Hi Pekka,

On 13 November 2012 07:40 Pekka Enberg wrote:

> On Mon, 12 Nov 2012, Will Deacon wrote:
> > This patch adds initial support for ARMv7 processors (more
> specifically,
> > Cortex-A15) to kvmtool.
> >
> > Everything is driven by FDT, including dynamic generation of virtio
> nodes
> > for MMIO devices (PCI is not used due to lack of a suitable host-
> bridge).
> >
> > The virtual timers and virtual interrupt controller (VGIC) are
> provided
> > by the kernel and require very little in terms of userspace code.
> >
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
>
> I'm happy with this but I'm not really an ARM guy. Is there anyone in
> the
> ARM/KVM community who is interested in reviewing this?

For the sake of transparency, I sent some minor feedback to Will off-list so that my (Outlook >:( ) broken linewraps & legal autoappend signature (see above and below) wouldn't pollute the thread on-list.  He'll use my IMAP address next time. ;-)

I *think* Will was going to make some small changes, if you've already merged it then a follow-up set perhaps?

(Modulo minor changes,
Acked-By: Matt Evans <matt@ozlabs.org>
)

Cheers,


Matt


-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

Re: [RFC PATCH 16/16] kvm tools: add support for ARMv7 processors

[Pekka Enberg]

On Tue, Nov 13, 2012 at 12:21 PM, Matt Evans <Matt.Evans@arm.com> wrote:
> I *think* Will was going to make some small changes, if you've already merged it then a follow-up set perhaps?

I only merged the non-ARM specific changes which looked good to me.
But sure, please send an incremental patch if you need to fix them up,
Will.

Re: [RFC PATCH 16/16] kvm tools: add support for ARMv7 processors

[Will Deacon]

On Tue, Nov 13, 2012 at 10:28:20AM +0000, Pekka Enberg wrote:
> On Tue, Nov 13, 2012 at 12:21 PM, Matt Evans <Matt.Evans@arm.com> wrote:
> > I *think* Will was going to make some small changes, if you've already merged it then a follow-up set perhaps?
> 
> I only merged the non-ARM specific changes which looked good to me.
> But sure, please send an incremental patch if you need to fix them up,
> Will.

Thanks Pekka! The patches you merged are all fine, so I'll send a v2 against
kvmtool master when I've updated the remaining patches to incorporate
comments from Sasha and Matt. I also need to investigate the build failure
you saw, because I've not managed to reproduce it myself.

Will

Re: [RFC PATCH 00/16] kvm tools: add support for ARMv7 processors

[Christoffer Dall]

On Mon, Nov 12, 2012 at 6:57 AM, Will Deacon <will.deacon@arm.com> wrote:
> Hello,
>
> This patch series adds support for ARMv7 processors (Cortex-A15) to kvm
> tool. The majority of the series consists of small changes in
> preparation for ARM support, which is added by the final patch. I can
> try to split this up further, but given that there is no current support
> for ARM, the sub-patches wouldn't be especially meaningful.

Very cool, looking forward to trying it out!

Would have been very nice if you had sent it to
kvmarm@lists.cs.columbia.edu as well.

>
> To boot a guest, you will need:
>
>   - A Cortex-A15 platform with a kvm-capable bootloader
>   - The latest kvm-arm patches:
>     git://github.com/virtualopensystems/linux-kvm-arm.git kvm-arm-master
>   - A guest kernel configured for our virtual target:
>     git://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git kvm/mach-virt

newest as in v4 from this weekend or before the weekend? There were
some (hopefully final) API breakage in there.

>
> I'm also working on an ARMv8 (AArch64) port which fits neatly into the
> code presented here.
>
> All feedback welcome,
>
> Will
>
>
> Will Deacon (16):
>   kvm tools: include arch uapi/asm directories in include path
>   kvm tools: only enable LTO if supported by GCC
>   kvm tools: avoid linking dynamically against libbfd
>   kvm tools: specify compiler by name when overriding make default
>   kvm tools: don't bother including linux/compiler.h
>   kvm tools: don't pass -Wcast-align to the compiler
>   kvm tools: die if init_list__init returns failure
>   kvm tools: add generic device registration mechanism
>   kvm tools: make _FDT macro usable by other architectures
>   kvm tools: virtio-mmio: use subsys_id instead of pci device ID
>   kvm tools: virtio: add dummy set_size_vq implementations
>   kvm tools: allow arch to specify default virtio transport
>   kvm tools: keep track of registered memory banks in struct kvm
>   kvm tools: teach guest_flat_to_host about memory banks starting above
>     0
>   kvm tools: provide a mechanism for translating host to guest
>     addresses
>   kvm tools: add support for ARMv7 processors
>
>  tools/kvm/Makefile                           |   38 +++-
>  tools/kvm/arm/aarch32/cortex-a15.c           |   98 ++++++++++
>  tools/kvm/arm/aarch32/include/kvm/barrier.h  |   10 +
>  tools/kvm/arm/aarch32/include/kvm/kvm-arch.h |   28 +++
>  tools/kvm/arm/aarch32/kvm-cpu.c              |  111 +++++++++++
>  tools/kvm/arm/aarch32/smp-pen.S              |   14 ++
>  tools/kvm/arm/fdt.c                          |  269 ++++++++++++++++++++++++++
>  tools/kvm/arm/gic.c                          |   86 ++++++++
>  tools/kvm/arm/include/arm-common/gic.h       |   29 +++
>  tools/kvm/arm/include/arm-common/kvm-arch.h  |   31 +++
>  tools/kvm/arm/include/arm-common/smp.h       |    7 +
>  tools/kvm/arm/include/kvm/kvm-cpu-arch.h     |   47 +++++
>  tools/kvm/arm/ioport.c                       |    5 +
>  tools/kvm/arm/irq.c                          |   25 +++
>  tools/kvm/arm/kvm-cpu.c                      |  112 +++++++++++
>  tools/kvm/arm/kvm.c                          |   69 +++++++
>  tools/kvm/arm/smp.c                          |   13 ++
>  tools/kvm/builtin-run.c                      |    3 +-
>  tools/kvm/devices.c                          |   24 +++
>  tools/kvm/hw/pci-shmem.c                     |    8 +-
>  tools/kvm/hw/vesa.c                          |    8 +-
>  tools/kvm/include/kvm/devices.h              |   21 ++
>  tools/kvm/include/kvm/fdt.h                  |   26 +++
>  tools/kvm/include/kvm/kvm.h                  |   16 +-
>  tools/kvm/include/kvm/pci.h                  |    2 -
>  tools/kvm/include/kvm/virtio-mmio.h          |    1 +
>  tools/kvm/include/kvm/virtio-pci.h           |    2 +
>  tools/kvm/include/linux/stddef.h             |    6 -
>  tools/kvm/kvm.c                              |   55 +++++-
>  tools/kvm/pci.c                              |   40 ++---
>  tools/kvm/powerpc/include/kvm/kvm-arch.h     |   13 +-
>  tools/kvm/powerpc/irq.c                      |    3 +-
>  tools/kvm/powerpc/kvm.c                      |    2 +-
>  tools/kvm/powerpc/spapr_pci.c                |    4 +-
>  tools/kvm/virtio/9p.c                        |   10 +-
>  tools/kvm/virtio/balloon.c                   |    3 +-
>  tools/kvm/virtio/blk.c                       |    3 +-
>  tools/kvm/virtio/console.c                   |   10 +-
>  tools/kvm/virtio/mmio.c                      |    9 +-
>  tools/kvm/virtio/pci.c                       |    7 +-
>  tools/kvm/virtio/rng.c                       |   10 +-
>  tools/kvm/virtio/scsi.c                      |    3 +-
>  tools/kvm/x86/include/kvm/kvm-arch.h         |   11 +-
>  tools/kvm/x86/kvm.c                          |    7 +
>  44 files changed, 1214 insertions(+), 85 deletions(-)
>  create mode 100644 tools/kvm/arm/aarch32/cortex-a15.c
>  create mode 100644 tools/kvm/arm/aarch32/include/kvm/barrier.h
>  create mode 100644 tools/kvm/arm/aarch32/include/kvm/kvm-arch.h
>  create mode 100644 tools/kvm/arm/aarch32/kvm-cpu.c
>  create mode 100644 tools/kvm/arm/aarch32/smp-pen.S
>  create mode 100644 tools/kvm/arm/fdt.c
>  create mode 100644 tools/kvm/arm/gic.c
>  create mode 100644 tools/kvm/arm/include/arm-common/gic.h
>  create mode 100644 tools/kvm/arm/include/arm-common/kvm-arch.h
>  create mode 100644 tools/kvm/arm/include/arm-common/smp.h
>  create mode 100644 tools/kvm/arm/include/kvm/kvm-cpu-arch.h
>  create mode 100644 tools/kvm/arm/ioport.c
>  create mode 100644 tools/kvm/arm/irq.c
>  create mode 100644 tools/kvm/arm/kvm-cpu.c
>  create mode 100644 tools/kvm/arm/kvm.c
>  create mode 100644 tools/kvm/arm/smp.c
>  create mode 100644 tools/kvm/devices.c
>  create mode 100644 tools/kvm/include/kvm/devices.h
>  create mode 100644 tools/kvm/include/kvm/fdt.h
>
> --
> 1.7.4.1
>

Re: [RFC PATCH 00/16] kvm tools: add support for ARMv7 processors

[Will Deacon]

Hi Christoffer,

On Mon, Nov 12, 2012 at 12:18:57PM +0000, Christoffer Dall wrote:
> On Mon, Nov 12, 2012 at 6:57 AM, Will Deacon <will.deacon@arm.com> wrote:
> > Hello,
> >
> > This patch series adds support for ARMv7 processors (Cortex-A15) to kvm
> > tool. The majority of the series consists of small changes in
> > preparation for ARM support, which is added by the final patch. I can
> > try to split this up further, but given that there is no current support
> > for ARM, the sub-patches wouldn't be especially meaningful.
> 
> Very cool, looking forward to trying it out!

Great -- please let me know if/when it explodes...

> Would have been very nice if you had sent it to
> kvmarm@lists.cs.columbia.edu as well.

Sorry, will include that on CC for future submissions (obviously didn't
appear in the get_maintainers.pl output).

> >
> > To boot a guest, you will need:
> >
> >   - A Cortex-A15 platform with a kvm-capable bootloader
> >   - The latest kvm-arm patches:
> >     git://github.com/virtualopensystems/linux-kvm-arm.git kvm-arm-master
> >   - A guest kernel configured for our virtual target:
> >     git://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git kvm/mach-virt
> 
> newest as in v4 from this weekend or before the weekend? There were
> some (hopefully final) API breakage in there.

That's the GIC device ID type change right? I think that just requires a
recompile on my part, with no changes to the code. I've been working off
kvm-arm-master and updating fairly frequently (current HEAD a73616f165).

I see you posted v14 of the kernel patches too, so I'll try and get round
to looking at those this week.

Cheers,

Will

Re: [RFC PATCH 00/16] kvm tools: add support for ARMv7 processors

[Christoffer Dall]

On Mon, Nov 12, 2012 at 7:27 AM, Will Deacon <will.deacon@arm.com> wrote:
> Hi Christoffer,
>
> On Mon, Nov 12, 2012 at 12:18:57PM +0000, Christoffer Dall wrote:
>> On Mon, Nov 12, 2012 at 6:57 AM, Will Deacon <will.deacon@arm.com> wrote:
>> > Hello,
>> >
>> > This patch series adds support for ARMv7 processors (Cortex-A15) to kvm
>> > tool. The majority of the series consists of small changes in
>> > preparation for ARM support, which is added by the final patch. I can
>> > try to split this up further, but given that there is no current support
>> > for ARM, the sub-patches wouldn't be especially meaningful.
>>
>> Very cool, looking forward to trying it out!
>
> Great -- please let me know if/when it explodes...
>
>> Would have been very nice if you had sent it to
>> kvmarm@lists.cs.columbia.edu as well.
>
> Sorry, will include that on CC for future submissions (obviously didn't
> appear in the get_maintainers.pl output).
>
>> >
>> > To boot a guest, you will need:
>> >
>> >   - A Cortex-A15 platform with a kvm-capable bootloader
>> >   - The latest kvm-arm patches:
>> >     git://github.com/virtualopensystems/linux-kvm-arm.git kvm-arm-master
>> >   - A guest kernel configured for our virtual target:
>> >     git://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git kvm/mach-virt
>>
>> newest as in v4 from this weekend or before the weekend? There were
>> some (hopefully final) API breakage in there.
>
> That's the GIC device ID type change right? I think that just requires a
> recompile on my part, with no changes to the code. I've been working off
> kvm-arm-master and updating fairly frequently (current HEAD a73616f165).
>

between v3 and v4 we also changed the struct kvm_regs to use pt_regs,
but that's all included in a73616f165.

thanks

Re: [RFC PATCH 00/16] kvm tools: add support for ARMv7 processors

[Christoffer Dall]

On Mon, Nov 12, 2012 at 7:52 AM, Christoffer Dall
<c.dall@virtualopensystems.com> wrote:
> On Mon, Nov 12, 2012 at 7:27 AM, Will Deacon <will.deacon@arm.com> wrote:
>> Hi Christoffer,
>>
>> On Mon, Nov 12, 2012 at 12:18:57PM +0000, Christoffer Dall wrote:
>>> On Mon, Nov 12, 2012 at 6:57 AM, Will Deacon <will.deacon@arm.com> wrote:
>>> > Hello,
>>> >
>>> > This patch series adds support for ARMv7 processors (Cortex-A15) to kvm
>>> > tool. The majority of the series consists of small changes in
>>> > preparation for ARM support, which is added by the final patch. I can
>>> > try to split this up further, but given that there is no current support
>>> > for ARM, the sub-patches wouldn't be especially meaningful.
>>>
>>> Very cool, looking forward to trying it out!
>>
>> Great -- please let me know if/when it explodes...
>>
just to make sure, this patch series is also the one that can be found
here (HEAD~1):
git://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git kvmtool/arm

???
-Christoffer

Re: [RFC PATCH 00/16] kvm tools: add support for ARMv7 processors

[Will Deacon]

On Mon, Nov 12, 2012 at 10:40:33PM +0000, Christoffer Dall wrote:
> On Mon, Nov 12, 2012 at 7:52 AM, Christoffer Dall
> <c.dall@virtualopensystems.com> wrote:
> > On Mon, Nov 12, 2012 at 7:27 AM, Will Deacon <will.deacon@arm.com> wrote:
> >> Hi Christoffer,
> >>
> >> On Mon, Nov 12, 2012 at 12:18:57PM +0000, Christoffer Dall wrote:
> >>> On Mon, Nov 12, 2012 at 6:57 AM, Will Deacon <will.deacon@arm.com> wrote:
> >>> > Hello,
> >>> >
> >>> > This patch series adds support for ARMv7 processors (Cortex-A15) to kvm
> >>> > tool. The majority of the series consists of small changes in
> >>> > preparation for ARM support, which is added by the final patch. I can
> >>> > try to split this up further, but given that there is no current support
> >>> > for ARM, the sub-patches wouldn't be especially meaningful.
> >>>
> >>> Very cool, looking forward to trying it out!
> >>
> >> Great -- please let me know if/when it explodes...
> >>
> just to make sure, this patch series is also the one that can be found
> here (HEAD~1):
> git://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git kvmtool/arm

Currently, yes, but that is my development branch and will rebase as and
when I make changes in preparation for v2. There's also a patch there for
AArch64 support, but the kernel side needs to settle down before that's
ready for posting.

Cheers,

Will

Re: [RFC PATCH 00/16] kvm tools: add support for ARMv7 processors

[Pekka Enberg]

On Mon, 12 Nov 2012, Will Deacon wrote:
> This patch series adds support for ARMv7 processors (Cortex-A15) to kvm
> tool. The majority of the series consists of small changes in
> preparation for ARM support, which is added by the final patch. I can
> try to split this up further, but given that there is no current support
> for ARM, the sub-patches wouldn't be especially meaningful.

I cherry-picked the easy ones from this series and merged them. Thanks a 
lot, Will!

			Pekka