[RFC PATCH 00/11] kvm tools: allow ioport emulation to be used on ARM

[RFC PATCH 00/11] kvm tools: allow ioport emulation to be used on ARM

[Will Deacon]

Hi guys,

This RFC series does a number of things, but the main goal is to allow
re-use of the emulation code under hw/ on architectures other than x86.
It also comes about after discussions concerning virtio-console for
earlyprintk:

  http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/165605.html

The first 5 patches in this series allow the 8250 emulation to be used
for earlyprintk (i.e. output only) on aarch64 platforms. The remaining 7
patches generalise this to potentially any ioport devices, with DT node
generation and interrupt routing.

All comments welcome,

Will


Marc Zyngier (2):
  kvm tools: console: unconditionally output to any console
  kvm tools: 8250: add address qualifier to uart name in fdt node

Will Deacon (9):
  kvm tools: makefile: factor out libfdt inclusion
  kvm tools: virtio: move fdt node generation into core mmio code
  kvm tools: arm: add ioport window to virtual memory map
  kvm tools: allow ioports to be offset from 0
  kvm tools: ioport: add arch callback to remap IRQ lines for ioport
    devices
  kvm tools: ioport: allow ioport devices to generate fdt nodes
  kvm tools: 8250: add fdt node generation
  kvm tools: ARM: generate fdt nodes for ioport devices
  kvm tools: ARM: add 8250 console callback to periodic poll

 tools/kvm/Makefile                          | 31 ++++++++------
 tools/kvm/arm/fdt.c                         | 38 ++++++++---------
 tools/kvm/arm/include/arm-common/kvm-arch.h | 13 +++++-
 tools/kvm/arm/ioport.c                      |  7 ++++
 tools/kvm/arm/kvm-cpu.c                     |  9 +++-
 tools/kvm/arm/kvm.c                         |  5 ++-
 tools/kvm/devices.c                         |  6 +++
 tools/kvm/hw/serial.c                       | 64 ++++++++++++++++-------------
 tools/kvm/include/kvm/devices.h             |  2 +
 tools/kvm/include/kvm/ioport.h              |  5 +++
 tools/kvm/ioport.c                          | 34 +++++++++++++--
 tools/kvm/powerpc/include/kvm/kvm-arch.h    |  1 +
 tools/kvm/powerpc/ioport.c                  |  4 ++
 tools/kvm/powerpc/spapr_hvcons.c            |  5 +--
 tools/kvm/powerpc/spapr_rtas.c              |  3 +-
 tools/kvm/virtio/console.c                  |  5 +--
 tools/kvm/virtio/mmio.c                     | 38 ++++++++++++++++-
 tools/kvm/x86/include/kvm/kvm-arch.h        |  1 +
 tools/kvm/x86/ioport.c                      |  4 ++
 19 files changed, 196 insertions(+), 79 deletions(-)

-- 
1.8.0

[RFC PATCH 01/11] kvm tools: makefile: factor out libfdt inclusion

[Will Deacon]

libfdt is used by powerpc, arm and arm64.

This patch factors out the Makefile parts including it and defines a
CONFIG_HAS_LIBFDT, so architecture-portable code can make use of fdt
if it is available.

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

diff --git a/tools/kvm/Makefile b/tools/kvm/Makefile
index a0a0a9b..cb1a9b4 100644
--- a/tools/kvm/Makefile
+++ b/tools/kvm/Makefile
@@ -114,9 +114,6 @@ ifeq ($(ARCH),x86_64)
 	DEFINES      += -DCONFIG_X86_64
 endif
 
-LIBFDT_SRC = fdt.o fdt_ro.o fdt_wip.o fdt_sw.o fdt_rw.o fdt_strerror.o
-LIBFDT_OBJS = $(patsubst %,../../scripts/dtc/libfdt/%,$(LIBFDT_SRC))
-
 ### Arch-specific stuff
 
 #x86
@@ -150,12 +147,10 @@ ifeq ($(ARCH), powerpc)
 	OBJS	+= powerpc/spapr_hvcons.o
 	OBJS	+= powerpc/spapr_pci.o
 	OBJS	+= powerpc/xics.o
-# We use libfdt, but it's sometimes not packaged 64bit.  It's small too,
-# so just build it in:
-	CFLAGS 	+= -I../../scripts/dtc/libfdt
-	OTHEROBJS	+= $(LIBFDT_OBJS)
 	ARCH_INCLUDE := powerpc/include
 	CFLAGS 	+= -m64
+
+	ARCH_WANT_LIBFDT := y
 endif
 
 # ARM
@@ -170,8 +165,8 @@ ifeq ($(ARCH), arm)
 	ARCH_INCLUDE	:= $(HDRS_ARM_COMMON)
 	ARCH_INCLUDE	+= -Iarm/aarch32/include
 	CFLAGS		+= -march=armv7-a
-	CFLAGS		+= -I../../scripts/dtc/libfdt
-	OTHEROBJS	+= $(LIBFDT_OBJS)
+
+	ARCH_WANT_LIBFDT := y
 endif
 
 # ARM64
@@ -182,8 +177,8 @@ ifeq ($(ARCH), arm64)
 	OBJS		+= arm/aarch64/kvm-cpu.o
 	ARCH_INCLUDE	:= $(HDRS_ARM_COMMON)
 	ARCH_INCLUDE	+= -Iarm/aarch64/include
-	CFLAGS		+= -I../../scripts/dtc/libfdt
-	OTHEROBJS	+= $(LIBFDT_OBJS)
+
+	ARCH_WANT_LIBFDT := y
 endif
 
 ###
@@ -196,6 +191,18 @@ endif
 
 ###
 
+# libfdt support
+
+LIBFDT_SRC = fdt.o fdt_ro.o fdt_wip.o fdt_sw.o fdt_rw.o fdt_strerror.o
+LIBFDT_OBJS = $(patsubst %,../../scripts/dtc/libfdt/%,$(LIBFDT_SRC))
+
+ifeq (y,$(ARCH_WANT_LIBFDT))
+	DEFINES		+= -DCONFIG_HAS_LIBFDT
+	OTHEROBJS	+= $(LIBFDT_OBJS)
+endif
+
+###
+
 # Detect optional features.
 # On a given system, some libs may link statically, some may not; so, check
 # both and only build those that link!
@@ -285,7 +292,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
+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/ -I$(KINCL_PATH)/scripts/dtc/libfdt -O2 -fno-strict-aliasing -g
 
 WARNINGS += -Wall
 WARNINGS += -Wformat=2
-- 
1.8.0

[RFC PATCH 02/11] kvm tools: virtio: move fdt node generation into core mmio code

[Will Deacon]

Generating fdt nodes for virtio-mmio devices should be in the core code,
not hidden inside the architecture code for ARM.

This patch reworks the .data field of struct device_header for
virtio-mmio devices, so that it contains a function pointer which can
be called to generate the FDT node for each device.

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

diff --git a/tools/kvm/arm/fdt.c b/tools/kvm/arm/fdt.c
index c61bf58..7198fe8 100644
--- a/tools/kvm/arm/fdt.c
+++ b/tools/kvm/arm/fdt.c
@@ -69,28 +69,15 @@ static void generate_cpu_nodes(void *fdt, struct kvm *kvm)
 	_FDT(fdt_end_node(fdt));
 }
 
-#define DEVICE_NAME_MAX_LEN 32
-static void generate_virtio_mmio_node(void *fdt, struct virtio_mmio *vmmio)
+static void generate_irq_prop(void *fdt, u8 irq)
 {
-	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(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)
@@ -105,8 +92,10 @@ static int setup_fdt(struct kvm *kvm)
 	void *fdt		= staging_fdt;
 	void *fdt_dest		= guest_flat_to_host(kvm,
 						     kvm->arch.dtb_guest_start);
-	void (*generate_fdt_nodes)(void *, struct kvm *, u32)
-				= kvm->cpus[0]->generate_fdt_nodes;
+	void (*generate_mmio_fdt_nodes)(void *, struct device_header *,
+					void (*)(void *, u8));
+	void (*generate_cpu_peripheral_fdt_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));
@@ -144,13 +133,14 @@ static int setup_fdt(struct kvm *kvm)
 
 	/* CPU and peripherals (interrupt controller, timers, etc) */
 	generate_cpu_nodes(fdt, kvm);
-	if (generate_fdt_nodes)
-		generate_fdt_nodes(fdt, kvm, gic_phandle);
+	if (generate_cpu_peripheral_fdt_nodes)
+		generate_cpu_peripheral_fdt_nodes(fdt, kvm, gic_phandle);
 
 	/* Virtio MMIO devices */
 	dev_hdr = device__first_dev(DEVICE_BUS_MMIO);
 	while (dev_hdr) {
-		generate_virtio_mmio_node(fdt, dev_hdr->data);
+		generate_mmio_fdt_nodes = dev_hdr->data;
+		generate_mmio_fdt_nodes(fdt, dev_hdr, generate_irq_prop);
 		dev_hdr = device__next_dev(dev_hdr);
 	}
 
diff --git a/tools/kvm/virtio/mmio.c b/tools/kvm/virtio/mmio.c
index bd30f37..a4e4855 100644
--- a/tools/kvm/virtio/mmio.c
+++ b/tools/kvm/virtio/mmio.c
@@ -5,6 +5,7 @@
 #include "kvm/virtio.h"
 #include "kvm/kvm.h"
 #include "kvm/irq.h"
+#include "kvm/fdt.h"
 
 #include <linux/virtio_mmio.h>
 #include <string.h>
@@ -215,6 +216,41 @@ static void virtio_mmio_mmio_callback(u64 addr, u8 *data, u32 len,
 		virtio_mmio_config_in(offset, data, len, ptr);
 }
 
+#ifdef CONFIG_HAS_LIBFDT
+#define DEVICE_NAME_MAX_LEN 32
+static void generate_virtio_mmio_fdt_node(void *fdt,
+					  struct device_header *dev_hdr,
+					  void (*generate_irq_prop)(void *fdt,
+								    u8 irq))
+{
+	char dev_name[DEVICE_NAME_MAX_LEN];
+	struct virtio_mmio *vmmio = container_of(dev_hdr,
+						 struct virtio_mmio,
+						 dev_hdr);
+	u64 addr = vmmio->addr;
+	u64 reg_prop[] = {
+		cpu_to_fdt64(addr),
+		cpu_to_fdt64(VIRTIO_MMIO_IO_SIZE),
+	};
+
+	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)));
+	generate_irq_prop(fdt, vmmio->irq);
+	_FDT(fdt_end_node(fdt));
+}
+#else
+static void generate_virtio_mmio_fdt_node(void *fdt,
+					  struct device_header *dev_hdr,
+					  void (*generate_irq_prop)(void *fdt,
+								    u8 irq))
+{
+	die("Unable to generate device tree nodes without libfdt\n");
+}
+#endif
+
 int virtio_mmio_init(struct kvm *kvm, void *dev, struct virtio_device *vdev,
 		     int device_id, int subsys_id, int class)
 {
@@ -241,7 +277,7 @@ int virtio_mmio_init(struct kvm *kvm, void *dev, struct virtio_device *vdev,
 	vmmio->irq = line;
 	vmmio->dev_hdr = (struct device_header) {
 		.bus_type	= DEVICE_BUS_MMIO,
-		.data		= vmmio,
+		.data		= generate_virtio_mmio_fdt_node,
 	};
 
 	device__register(&vmmio->dev_hdr);
-- 
1.8.0

[RFC PATCH 03/11] kvm tools: arm: add ioport window to virtual memory map

[Will Deacon]

Whilst ARM neither needs or wants a complete x86 legacy ioport emulation,
the 8250 is a useful alternative to virtio-console, so carve out 64k at the
bottom of our virtual memory map where we can add ioports if we choose.

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 tools/kvm/arm/include/arm-common/kvm-arch.h | 12 ++++++++++--
 tools/kvm/arm/kvm-cpu.c                     |  9 +++++++--
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/tools/kvm/arm/include/arm-common/kvm-arch.h b/tools/kvm/arm/include/arm-common/kvm-arch.h
index 7860e17..03ead5b 100644
--- a/tools/kvm/arm/include/arm-common/kvm-arch.h
+++ b/tools/kvm/arm/include/arm-common/kvm-arch.h
@@ -5,7 +5,8 @@
 #include <linux/const.h>
 #include <linux/types.h>
 
-#define ARM_MMIO_AREA		_AC(0x0000000000000000, UL)
+#define ARM_IOPORT_AREA		_AC(0x0000000000000000, UL)
+#define ARM_MMIO_AREA		_AC(0x0000000000010000, UL)
 #define ARM_AXI_AREA		_AC(0x0000000040000000, UL)
 #define ARM_MEMORY_AREA		_AC(0x0000000080000000, UL)
 
@@ -16,7 +17,8 @@
 #define ARM_GIC_CPUI_BASE	(ARM_GIC_DIST_BASE - ARM_GIC_CPUI_SIZE)
 #define ARM_GIC_SIZE		(ARM_GIC_DIST_SIZE + ARM_GIC_CPUI_SIZE)
 
-#define ARM_VIRTIO_MMIO_SIZE	(ARM_AXI_AREA - ARM_GIC_SIZE)
+#define ARM_IOPORT_SIZE		(ARM_MMIO_AREA - ARM_IOPORT_AREA)
+#define ARM_VIRTIO_MMIO_SIZE	(ARM_AXI_AREA - (ARM_MMIO_AREA + ARM_GIC_SIZE))
 #define ARM_PCI_MMIO_SIZE	(ARM_MEMORY_AREA - ARM_AXI_AREA)
 
 #define KVM_PCI_MMIO_AREA	ARM_AXI_AREA
@@ -24,6 +26,12 @@
 
 #define VIRTIO_DEFAULT_TRANS	VIRTIO_MMIO
 
+static inline bool arm_addr_in_ioport_region(u64 phys_addr)
+{
+	u64 limit = ARM_IOPORT_AREA + ARM_IOPORT_SIZE;
+	return phys_addr >= ARM_IOPORT_AREA && phys_addr < limit;
+}
+
 static inline bool arm_addr_in_virtio_mmio_region(u64 phys_addr)
 {
 	u64 limit = KVM_VIRTIO_MMIO_AREA + ARM_VIRTIO_MMIO_SIZE;
diff --git a/tools/kvm/arm/kvm-cpu.c b/tools/kvm/arm/kvm-cpu.c
index 6d4f306..d31e7b1 100644
--- a/tools/kvm/arm/kvm-cpu.c
+++ b/tools/kvm/arm/kvm-cpu.c
@@ -101,10 +101,15 @@ bool kvm_cpu__handle_exit(struct kvm_cpu *vcpu)
 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))
+	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))
+	} else if (arm_addr_in_ioport_region(phys_addr)) {
+		int direction = is_write ? KVM_EXIT_IO_OUT : KVM_EXIT_IO_IN;
+		u16 port = phys_addr & USHRT_MAX;
+		return kvm__emulate_io(kvm, port, data, direction, len, 1);
+	} else if (arm_addr_in_pci_mmio_region(phys_addr)) {
 		die("PCI emulation not supported on ARM!");
+	}
 
 	return false;
 }
-- 
1.8.0

[RFC PATCH 04/11] kvm tools: console: unconditionally output to any console

[Will Deacon]

From: Marc Zyngier <Marc.Zyngier@arm.com>

Kvmtool suppresses any output to a console that has not been elected
as *the* console.

While this makes sense on the input side (we want the input to be sent
to one console driver only), it seems to be the wrong thing to do on
the output side, as it effectively prevents the guest from switching
from one console to another (think earlyprintk using 8250 to virtio
console).

After all, the guest *does* poke this device and outputs something
there.

Just remove the kvm->cfg.active_console test from the output paths.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 tools/kvm/hw/serial.c            | 3 +--
 tools/kvm/powerpc/spapr_hvcons.c | 5 +----
 tools/kvm/powerpc/spapr_rtas.c   | 3 +--
 tools/kvm/virtio/console.c       | 5 +----
 4 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/tools/kvm/hw/serial.c b/tools/kvm/hw/serial.c
index 53b684a..18bf569 100644
--- a/tools/kvm/hw/serial.c
+++ b/tools/kvm/hw/serial.c
@@ -100,8 +100,7 @@ static void serial8250_flush_tx(struct kvm *kvm, struct serial8250_device *dev)
 	dev->lsr |= UART_LSR_TEMT | UART_LSR_THRE;
 
 	if (dev->txcnt) {
-		if (kvm->cfg.active_console == CONSOLE_8250)
-			term_putc(dev->txbuf, dev->txcnt, dev->id);
+		term_putc(dev->txbuf, dev->txcnt, dev->id);
 		dev->txcnt = 0;
 	}
 }
diff --git a/tools/kvm/powerpc/spapr_hvcons.c b/tools/kvm/powerpc/spapr_hvcons.c
index 0bdf75b..605367b 100644
--- a/tools/kvm/powerpc/spapr_hvcons.c
+++ b/tools/kvm/powerpc/spapr_hvcons.c
@@ -50,10 +50,7 @@ static unsigned long h_put_term_char(struct kvm_cpu *vcpu, unsigned long opcode,
 	do {
 		int ret;
 
-		if (vcpu->kvm->cfg.active_console == CONSOLE_HV)
-			ret = term_putc_iov(&iov, 1, 0);
-		else
-			ret = 0;
+		ret = term_putc_iov(&iov, 1, 0);
 		if (ret < 0) {
 			die("term_putc_iov error %d!\n", errno);
 		}
diff --git a/tools/kvm/powerpc/spapr_rtas.c b/tools/kvm/powerpc/spapr_rtas.c
index c81d82b..f3c8fa3 100644
--- a/tools/kvm/powerpc/spapr_rtas.c
+++ b/tools/kvm/powerpc/spapr_rtas.c
@@ -53,8 +53,7 @@ static void rtas_put_term_char(struct kvm_cpu *vcpu,
 {
 	char c = rtas_ld(vcpu->kvm, args, 0);
 
-	if (vcpu->kvm->cfg.active_console == CONSOLE_HV)
-		term_putc(&c, 1, 0);
+	term_putc(&c, 1, 0);
 
 	rtas_st(vcpu->kvm, rets, 0, 0);
 }
diff --git a/tools/kvm/virtio/console.c b/tools/kvm/virtio/console.c
index b18d3a9..1f88a4b 100644
--- a/tools/kvm/virtio/console.c
+++ b/tools/kvm/virtio/console.c
@@ -102,10 +102,7 @@ static void virtio_console_handle_callback(struct kvm *kvm, void *param)
 
 	while (virt_queue__available(vq)) {
 		head = virt_queue__get_iov(vq, iov, &out, &in, kvm);
-		if (kvm->cfg.active_console == CONSOLE_VIRTIO)
-			len = term_putc_iov(iov, out, 0);
-		else
-			len = 0;
+		len = term_putc_iov(iov, out, 0);
 		virt_queue__set_used_elem(vq, head, len);
 	}
 
-- 
1.8.0

[RFC PATCH 05/11] kvm tools: allow ioports to be offset from 0

[Will Deacon]

Architectures without a legacy ioport may wish to emulate one, but not
at address 0x0.

This patch introduces KVM_IOPORT_AREA, which each architecture defines
to be the start of the ioport region (i.e. where port addresses are
offset from).

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 tools/kvm/arm/include/arm-common/kvm-arch.h | 5 +++--
 tools/kvm/powerpc/include/kvm/kvm-arch.h    | 1 +
 tools/kvm/x86/include/kvm/kvm-arch.h        | 1 +
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/tools/kvm/arm/include/arm-common/kvm-arch.h b/tools/kvm/arm/include/arm-common/kvm-arch.h
index 03ead5b..72b204f 100644
--- a/tools/kvm/arm/include/arm-common/kvm-arch.h
+++ b/tools/kvm/arm/include/arm-common/kvm-arch.h
@@ -21,6 +21,7 @@
 #define ARM_VIRTIO_MMIO_SIZE	(ARM_AXI_AREA - (ARM_MMIO_AREA + ARM_GIC_SIZE))
 #define ARM_PCI_MMIO_SIZE	(ARM_MEMORY_AREA - ARM_AXI_AREA)
 
+#define KVM_IOPORT_AREA		ARM_IOPORT_AREA
 #define KVM_PCI_MMIO_AREA	ARM_AXI_AREA
 #define KVM_VIRTIO_MMIO_AREA	ARM_MMIO_AREA
 
@@ -28,8 +29,8 @@
 
 static inline bool arm_addr_in_ioport_region(u64 phys_addr)
 {
-	u64 limit = ARM_IOPORT_AREA + ARM_IOPORT_SIZE;
-	return phys_addr >= ARM_IOPORT_AREA && phys_addr < limit;
+	u64 limit = KVM_IOPORT_AREA + ARM_IOPORT_SIZE;
+	return phys_addr >= KVM_IOPORT_AREA && phys_addr < limit;
 }
 
 static inline bool arm_addr_in_virtio_mmio_region(u64 phys_addr)
diff --git a/tools/kvm/powerpc/include/kvm/kvm-arch.h b/tools/kvm/powerpc/include/kvm/kvm-arch.h
index d93e142..96dea91 100644
--- a/tools/kvm/powerpc/include/kvm/kvm-arch.h
+++ b/tools/kvm/powerpc/include/kvm/kvm-arch.h
@@ -37,6 +37,7 @@
  * This is the address that pci_get_io_space_block() starts allocating
  * from.  Note that this is a PCI bus address.
  */
+#define KVM_IOPORT_AREA			0x0
 #define KVM_PCI_MMIO_AREA		0x1000000
 #define KVM_VIRTIO_MMIO_AREA		0x2000000
 
diff --git a/tools/kvm/x86/include/kvm/kvm-arch.h b/tools/kvm/x86/include/kvm/kvm-arch.h
index 1e0949e..6d59c8e5 100644
--- a/tools/kvm/x86/include/kvm/kvm-arch.h
+++ b/tools/kvm/x86/include/kvm/kvm-arch.h
@@ -20,6 +20,7 @@
 /* This is the address that pci_get_io_space_block() starts allocating
  * from.  Note that this is a PCI bus address (though same on x86).
  */
+#define KVM_IOPORT_AREA		0x0
 #define KVM_PCI_MMIO_AREA	(KVM_MMIO_START + 0x1000000)
 #define KVM_VIRTIO_MMIO_AREA	(KVM_MMIO_START + 0x2000000)
 
-- 
1.8.0

[RFC PATCH 06/11] kvm tools: ioport: add arch callback to remap IRQ lines for ioport devices

[Will Deacon]

If an architecture other than x86 wants to make use of ioport devices, the
interrupt lines will likely need remapping from their fixed values.

This patch allows an architecture callback, ioport__map_irq, to map
interrupts as appropriate.

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 tools/kvm/arm/ioport.c         | 7 +++++++
 tools/kvm/hw/serial.c          | 1 +
 tools/kvm/include/kvm/ioport.h | 1 +
 tools/kvm/powerpc/ioport.c     | 4 ++++
 tools/kvm/x86/ioport.c         | 4 ++++
 5 files changed, 17 insertions(+)

diff --git a/tools/kvm/arm/ioport.c b/tools/kvm/arm/ioport.c
index 3c03fa0..74ee10e 100644
--- a/tools/kvm/arm/ioport.c
+++ b/tools/kvm/arm/ioport.c
@@ -1,5 +1,12 @@
 #include "kvm/ioport.h"
 
+#include "arm-common/gic.h"
+
 void ioport__setup_arch(struct kvm *kvm)
 {
 }
+
+void ioport__map_irq(u8 *irq)
+{
+	*irq = gic__alloc_irqnum();
+}
diff --git a/tools/kvm/hw/serial.c b/tools/kvm/hw/serial.c
index 18bf569..384ee37 100644
--- a/tools/kvm/hw/serial.c
+++ b/tools/kvm/hw/serial.c
@@ -402,6 +402,7 @@ static int serial8250__device_init(struct kvm *kvm, struct serial8250_device *de
 {
 	int r;
 
+	ioport__map_irq(&dev->irq);
 	r = ioport__register(kvm, dev->iobase, &serial8250_ops, 8, NULL);
 	kvm__irq_line(kvm, dev->irq, 0);
 
diff --git a/tools/kvm/include/kvm/ioport.h b/tools/kvm/include/kvm/ioport.h
index 6660acb..1556dd3 100644
--- a/tools/kvm/include/kvm/ioport.h
+++ b/tools/kvm/include/kvm/ioport.h
@@ -30,6 +30,7 @@ struct ioport_operations {
 };
 
 void ioport__setup_arch(struct kvm *kvm);
+void ioport__map_irq(u8 *irq);
 
 int ioport__register(struct kvm *kvm, u16 port, struct ioport_operations *ops,
 			int count, void *param);
diff --git a/tools/kvm/powerpc/ioport.c b/tools/kvm/powerpc/ioport.c
index 264fb7e..58dc625 100644
--- a/tools/kvm/powerpc/ioport.c
+++ b/tools/kvm/powerpc/ioport.c
@@ -16,3 +16,7 @@ void ioport__setup_arch(struct kvm *kvm)
 {
 	/* PPC has no legacy ioports to set up */
 }
+
+void ioport__map_irq(u8 *irq)
+{
+}
diff --git a/tools/kvm/x86/ioport.c b/tools/kvm/x86/ioport.c
index 824ef25..03a1286 100644
--- a/tools/kvm/x86/ioport.c
+++ b/tools/kvm/x86/ioport.c
@@ -65,6 +65,10 @@ static struct ioport_operations ps2_control_a_ops = {
 	.io_out		= dummy_io_out,
 };
 
+void ioport__map_irq(u8 *irq)
+{
+}
+
 void ioport__setup_arch(struct kvm *kvm)
 {
 	/* Legacy ioport setup */
-- 
1.8.0

[RFC PATCH 07/11] kvm tools: ioport: allow ioport devices to generate fdt nodes

[Will Deacon]

Devices in the ioport space may have fdt bindings (e.g. 8250, rtc) and
on architectures where a fixed ioport is not defined, it is necessary
to generate fdt nodes for them.

This patch creates a new virtual bus (tree of device_headers) for ioport
devices, allowing architecture code to callback to the emulation code
when generating fdt nodes, as we do for virtio-mmio devices.

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 tools/kvm/devices.c             |  6 ++++++
 tools/kvm/include/kvm/devices.h |  2 ++
 tools/kvm/include/kvm/ioport.h  |  4 ++++
 tools/kvm/ioport.c              | 34 +++++++++++++++++++++++++++++++---
 4 files changed, 43 insertions(+), 3 deletions(-)

diff --git a/tools/kvm/devices.c b/tools/kvm/devices.c
index 9f1941d..5b627e9 100644
--- a/tools/kvm/devices.c
+++ b/tools/kvm/devices.c
@@ -45,6 +45,12 @@ int device__register(struct device_header *dev)
 	return 0;
 }
 
+void device__unregister(struct device_header *dev)
+{
+	struct device_bus *bus = &device_trees[dev->bus_type];
+	rb_erase(&dev->node, &bus->root);
+}
+
 struct device_header *device__find_dev(enum device_bus_type bus_type, u8 dev_num)
 {
 	struct rb_node *node;
diff --git a/tools/kvm/include/kvm/devices.h b/tools/kvm/include/kvm/devices.h
index c5de3de..405f195 100644
--- a/tools/kvm/include/kvm/devices.h
+++ b/tools/kvm/include/kvm/devices.h
@@ -7,6 +7,7 @@
 enum device_bus_type {
 	DEVICE_BUS_PCI,
 	DEVICE_BUS_MMIO,
+	DEVICE_BUS_IOPORT,
 	DEVICE_BUS_MAX,
 };
 
@@ -18,6 +19,7 @@ struct device_header {
 };
 
 int device__register(struct device_header *dev);
+void device__unregister(struct device_header *dev);
 struct device_header *device__find_dev(enum device_bus_type bus_type,
 				       u8 dev_num);
 
diff --git a/tools/kvm/include/kvm/ioport.h b/tools/kvm/include/kvm/ioport.h
index 1556dd3..f639c2e 100644
--- a/tools/kvm/include/kvm/ioport.h
+++ b/tools/kvm/include/kvm/ioport.h
@@ -1,6 +1,7 @@
 #ifndef KVM__IOPORT_H
 #define KVM__IOPORT_H
 
+#include "kvm/devices.h"
 #include "kvm/rbtree-interval.h"
 
 #include <stdbool.h>
@@ -22,11 +23,14 @@ struct ioport {
 	struct rb_int_node		node;
 	struct ioport_operations	*ops;
 	void				*priv;
+	struct device_header		dev_hdr;
 };
 
 struct ioport_operations {
 	bool (*io_in)(struct ioport *ioport, struct kvm *kvm, u16 port, void *data, int size);
 	bool (*io_out)(struct ioport *ioport, struct kvm *kvm, u16 port, void *data, int size);
+	void (*generate_fdt_node)(struct ioport *ioport, void *fdt,
+				  void (*generate_irq_prop)(void *fdt, u8 irq));
 };
 
 void ioport__setup_arch(struct kvm *kvm);
diff --git a/tools/kvm/ioport.c b/tools/kvm/ioport.c
index a4f1582..be95e49 100644
--- a/tools/kvm/ioport.c
+++ b/tools/kvm/ioport.c
@@ -55,6 +55,28 @@ static void ioport_remove(struct rb_root *root, struct ioport *data)
 	rb_int_erase(root, &data->node);
 }
 
+#ifdef CONFIG_HAS_LIBFDT
+static void generate_ioport_fdt_node(void *fdt,
+				     struct device_header *dev_hdr,
+				     void (*generate_irq_prop)(void *fdt,
+							       u8 irq))
+{
+	struct ioport *ioport = container_of(dev_hdr, struct ioport, dev_hdr);
+	struct ioport_operations *ops = ioport->ops;
+
+	if (ops->generate_fdt_node)
+		ops->generate_fdt_node(ioport, fdt, generate_irq_prop);
+}
+#else
+static void generate_ioport_fdt_node(void *fdt,
+				     struct device_header *dev_hdr,
+				     void (*generate_irq_prop)(void *fdt,
+							       u8 irq))
+{
+	die("Unable to generate device tree nodes without libfdt\n");
+}
+#endif
+
 int ioport__register(struct kvm *kvm, u16 port, struct ioport_operations *ops, int count, void *param)
 {
 	struct ioport *entry;
@@ -75,9 +97,13 @@ int ioport__register(struct kvm *kvm, u16 port, struct ioport_operations *ops, i
 		return -ENOMEM;
 
 	*entry = (struct ioport) {
-		.node	= RB_INT_INIT(port, port + count),
-		.ops	= ops,
-		.priv	= param,
+		.node		= RB_INT_INIT(port, port + count),
+		.ops		= ops,
+		.priv		= param,
+		.dev_hdr	= (struct device_header) {
+			.bus_type	= DEVICE_BUS_IOPORT,
+			.data		= generate_ioport_fdt_node,
+		},
 	};
 
 	r = ioport_insert(&ioport_tree, entry);
@@ -86,6 +112,8 @@ int ioport__register(struct kvm *kvm, u16 port, struct ioport_operations *ops, i
 		br_write_unlock(kvm);
 		return r;
 	}
+
+	device__register(&entry->dev_hdr);
 	br_write_unlock(kvm);
 
 	return port;
-- 
1.8.0

[RFC PATCH 08/11] kvm tools: 8250: add fdt node generation

[Will Deacon]

This patch adds fdt node generation to the 8250 emulation. The
serial8250_device is now stashed inside the ioport priv field, so that
it can be retrieved from the ioport passed back to the generation code.

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 tools/kvm/hw/serial.c | 55 +++++++++++++++++++++++++++------------------------
 1 file changed, 29 insertions(+), 26 deletions(-)

diff --git a/tools/kvm/hw/serial.c b/tools/kvm/hw/serial.c
index 384ee37..523a767 100644
--- a/tools/kvm/hw/serial.c
+++ b/tools/kvm/hw/serial.c
@@ -6,6 +6,7 @@
 #include "kvm/util.h"
 #include "kvm/term.h"
 #include "kvm/kvm.h"
+#include "kvm/fdt.h"
 
 #include <linux/types.h>
 #include <linux/serial_reg.h>
@@ -226,31 +227,14 @@ void serial8250__inject_sysrq(struct kvm *kvm, char sysrq)
 	sysrq_pending = sysrq;
 }
 
-static struct serial8250_device *find_device(u16 port)
-{
-	unsigned int i;
-
-	for (i = 0; i < ARRAY_SIZE(devices); i++) {
-		struct serial8250_device *dev = &devices[i];
-
-		if (dev->iobase == (port & ~0x7))
-			return dev;
-	}
-	return NULL;
-}
-
 static bool serial8250_out(struct ioport *ioport, struct kvm *kvm, u16 port,
 			   void *data, int size)
 {
-	struct serial8250_device *dev;
+	struct serial8250_device *dev = ioport->priv;
 	u16 offset;
 	bool ret = true;
 	char *addr = data;
 
-	dev = find_device(port);
-	if (!dev)
-		return false;
-
 	mutex_lock(&dev->mutex);
 
 	offset = port - dev->iobase;
@@ -338,14 +322,10 @@ static void serial8250_rx(struct serial8250_device *dev, void *data)
 
 static bool serial8250_in(struct ioport *ioport, struct kvm *kvm, u16 port, void *data, int size)
 {
-	struct serial8250_device *dev;
+	struct serial8250_device *dev = ioport->priv;
 	u16 offset;
 	bool ret = true;
 
-	dev = find_device(port);
-	if (!dev)
-		return false;
-
 	mutex_lock(&dev->mutex);
 
 	offset = port - dev->iobase;
@@ -393,9 +373,32 @@ static bool serial8250_in(struct ioport *ioport, struct kvm *kvm, u16 port, void
 	return ret;
 }
 
+#ifdef CONFIG_HAS_LIBFDT
+static void serial8250_generate_fdt_node(struct ioport *ioport, void *fdt,
+					 void (*generate_irq_prop)(void *fdt,
+								   u8 irq))
+{
+	struct serial8250_device *dev = ioport->priv;
+	u64 reg_prop[] = {
+		cpu_to_fdt64(KVM_IOPORT_AREA + dev->iobase),
+		cpu_to_fdt64(8),
+	};
+
+	_FDT(fdt_begin_node(fdt, "U6_16550A"));
+	_FDT(fdt_property_string(fdt, "compatible", "ns16550a"));
+	_FDT(fdt_property(fdt, "reg", reg_prop, sizeof(reg_prop)));
+	generate_irq_prop(fdt, dev->irq);
+	_FDT(fdt_property_cell(fdt, "clock-frequency", 1843200));
+	_FDT(fdt_end_node(fdt));
+}
+#else
+#define serial8250_generate_fdt_node	NULL
+#endif
+
 static struct ioport_operations serial8250_ops = {
-	.io_in		= serial8250_in,
-	.io_out		= serial8250_out,
+	.io_in			= serial8250_in,
+	.io_out			= serial8250_out,
+	.generate_fdt_node	= serial8250_generate_fdt_node,
 };
 
 static int serial8250__device_init(struct kvm *kvm, struct serial8250_device *dev)
@@ -403,7 +406,7 @@ static int serial8250__device_init(struct kvm *kvm, struct serial8250_device *de
 	int r;
 
 	ioport__map_irq(&dev->irq);
-	r = ioport__register(kvm, dev->iobase, &serial8250_ops, 8, NULL);
+	r = ioport__register(kvm, dev->iobase, &serial8250_ops, 8, dev);
 	kvm__irq_line(kvm, dev->irq, 0);
 
 	return r;
-- 
1.8.0

[RFC PATCH 09/11] kvm tools: 8250: add address qualifier to uart name in fdt node

[Will Deacon]

From: Marc Zyngier <Marc.Zyngier@arm.com>

Having several uarts with the same name makes the kernel (and dtc)
choke. Add the base address as a qualifier so we get unique names.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 tools/kvm/hw/serial.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/kvm/hw/serial.c b/tools/kvm/hw/serial.c
index 523a767..931067f 100644
--- a/tools/kvm/hw/serial.c
+++ b/tools/kvm/hw/serial.c
@@ -374,17 +374,22 @@ static bool serial8250_in(struct ioport *ioport, struct kvm *kvm, u16 port, void
 }
 
 #ifdef CONFIG_HAS_LIBFDT
+#define DEVICE_NAME_MAX_LEN 32
 static void serial8250_generate_fdt_node(struct ioport *ioport, void *fdt,
 					 void (*generate_irq_prop)(void *fdt,
 								   u8 irq))
 {
+	char dev_name[DEVICE_NAME_MAX_LEN];
 	struct serial8250_device *dev = ioport->priv;
+	u64 addr = KVM_IOPORT_AREA + dev->iobase;
 	u64 reg_prop[] = {
-		cpu_to_fdt64(KVM_IOPORT_AREA + dev->iobase),
+		cpu_to_fdt64(addr),
 		cpu_to_fdt64(8),
 	};
 
-	_FDT(fdt_begin_node(fdt, "U6_16550A"));
+	snprintf(dev_name, DEVICE_NAME_MAX_LEN, "U6_16550A@%llx", addr);
+
+	_FDT(fdt_begin_node(fdt, dev_name));
 	_FDT(fdt_property_string(fdt, "compatible", "ns16550a"));
 	_FDT(fdt_property(fdt, "reg", reg_prop, sizeof(reg_prop)));
 	generate_irq_prop(fdt, dev->irq);
-- 
1.8.0

[RFC PATCH 10/11] kvm tools: ARM: generate fdt nodes for ioport devices

[Will Deacon]

Now that ioport devices can generate fdt nodes, iterate over the ioport
bus when generating our fdt.

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 tools/kvm/arm/fdt.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/tools/kvm/arm/fdt.c b/tools/kvm/arm/fdt.c
index 7198fe8..5e18c11 100644
--- a/tools/kvm/arm/fdt.c
+++ b/tools/kvm/arm/fdt.c
@@ -144,6 +144,14 @@ static int setup_fdt(struct kvm *kvm)
 		dev_hdr = device__next_dev(dev_hdr);
 	}
 
+	/* IOPORT devices (!) */
+	dev_hdr = device__first_dev(DEVICE_BUS_IOPORT);
+	while (dev_hdr) {
+		generate_mmio_fdt_nodes = dev_hdr->data;
+		generate_mmio_fdt_nodes(fdt, dev_hdr, generate_irq_prop);
+		dev_hdr = device__next_dev(dev_hdr);
+	}
+
 	/* PSCI firmware */
 	_FDT(fdt_begin_node(fdt, "psci"));
 	_FDT(fdt_property_string(fdt, "compatible", "arm,psci"));
-- 
1.8.0

[RFC PATCH 11/11] kvm tools: ARM: add 8250 console callback to periodic poll

[Will Deacon]

If we're using the 8250 as a fully-fledged console (i.e. not early
console), then we need to allow input as well as output.

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 tools/kvm/arm/kvm.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/kvm/arm/kvm.c b/tools/kvm/arm/kvm.c
index 1bcfce3..27e6cf4 100644
--- a/tools/kvm/arm/kvm.c
+++ b/tools/kvm/arm/kvm.c
@@ -1,6 +1,7 @@
 #include "kvm/kvm.h"
 #include "kvm/term.h"
 #include "kvm/util.h"
+#include "kvm/8250-serial.h"
 #include "kvm/virtio-console.h"
 
 #include "arm-common/gic.h"
@@ -47,8 +48,10 @@ void kvm__arch_delete_ram(struct kvm *kvm)
 
 void kvm__arch_periodic_poll(struct kvm *kvm)
 {
-	if (term_readable(0))
+	if (term_readable(0)) {
+		serial8250__update_consoles(kvm);
 		virtio_console__inject_interrupt(kvm);
+	}
 }
 
 void kvm__arch_set_cmdline(char *cmdline, bool video)
-- 
1.8.0

Re: [RFC PATCH 00/11] kvm tools: allow ioport emulation to be used on ARM

[Michael Ellerman]

On Wed, 2013-05-01 at 16:50 +0100, Will Deacon wrote:
> Hi guys,
> 
> This RFC series does a number of things, but the main goal is to allow
> re-use of the emulation code under hw/ on architectures other than x86.
> It also comes about after discussions concerning virtio-console for
> earlyprintk:
> 
>   http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/165605.html
> 
> The first 5 patches in this series allow the 8250 emulation to be used
> for earlyprintk (i.e. output only) on aarch64 platforms. The remaining 7
> patches generalise this to potentially any ioport devices, with DT node
> generation and interrupt routing.
> 
> All comments welcome,

I have nothing to add on the content, but they build on powerpc so I'm
happy :)

cheers

Re: [RFC PATCH 04/11] kvm tools: console: unconditionally output to any console

[Pekka Enberg]

On Wed, May 1, 2013 at 6:50 PM, Will Deacon <will.deacon@arm.com> wrote:
> From: Marc Zyngier <Marc.Zyngier@arm.com>
>
> Kvmtool suppresses any output to a console that has not been elected
> as *the* console.
>
> While this makes sense on the input side (we want the input to be sent
> to one console driver only), it seems to be the wrong thing to do on
> the output side, as it effectively prevents the guest from switching
> from one console to another (think earlyprintk using 8250 to virtio
> console).
>
> After all, the guest *does* poke this device and outputs something
> there.
>
> Just remove the kvm->cfg.active_console test from the output paths.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>

Seems reasonable. Asias, Sasha?

Re: [RFC PATCH 04/11] kvm tools: console: unconditionally output to any console

[Sasha Levin]

On 05/03/2013 05:19 AM, Pekka Enberg wrote:
> On Wed, May 1, 2013 at 6:50 PM, Will Deacon <will.deacon@arm.com> wrote:
>> From: Marc Zyngier <Marc.Zyngier@arm.com>
>>
>> Kvmtool suppresses any output to a console that has not been elected
>> as *the* console.
>>
>> While this makes sense on the input side (we want the input to be sent
>> to one console driver only), it seems to be the wrong thing to do on
>> the output side, as it effectively prevents the guest from switching
>> from one console to another (think earlyprintk using 8250 to virtio
>> console).
>>
>> After all, the guest *does* poke this device and outputs something
>> there.
>>
>> Just remove the kvm->cfg.active_console test from the output paths.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> Signed-off-by: Will Deacon <will.deacon@arm.com>
> 
> Seems reasonable. Asias, Sasha?
> 

I remember at trying it some time ago but dropped it for a reason I don't
remember at the moment.

Can I have the weekend to play with it to try and figure out why?


Thanks,
Sasha

Re: [RFC PATCH 04/11] kvm tools: console: unconditionally output to any console

[Will Deacon]

On Fri, May 03, 2013 at 05:02:14PM +0100, Sasha Levin wrote:
> On 05/03/2013 05:19 AM, Pekka Enberg wrote:
> > On Wed, May 1, 2013 at 6:50 PM, Will Deacon <will.deacon@arm.com> wrote:
> >> From: Marc Zyngier <Marc.Zyngier@arm.com>
> >>
> >> Kvmtool suppresses any output to a console that has not been elected
> >> as *the* console.
> >>
> >> While this makes sense on the input side (we want the input to be sent
> >> to one console driver only), it seems to be the wrong thing to do on
> >> the output side, as it effectively prevents the guest from switching
> >> from one console to another (think earlyprintk using 8250 to virtio
> >> console).
> >>
> >> After all, the guest *does* poke this device and outputs something
> >> there.
> >>
> >> Just remove the kvm->cfg.active_console test from the output paths.
> >>
> >> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> >> Signed-off-by: Will Deacon <will.deacon@arm.com>
> > 
> > Seems reasonable. Asias, Sasha?
> > 
> 
> I remember at trying it some time ago but dropped it for a reason I don't
> remember at the moment.
> 
> Can I have the weekend to play with it to try and figure out why?

There's no rush from my point of view (hence the RFC) so take as long as you
need!

Will

Re: [RFC PATCH 04/11] kvm tools: console: unconditionally output to any console

[Asias He]

On Fri, May 3, 2013 at 5:19 PM, Pekka Enberg <penberg@kernel.org> wrote:
> On Wed, May 1, 2013 at 6:50 PM, Will Deacon <will.deacon@arm.com> wrote:
>> From: Marc Zyngier <Marc.Zyngier@arm.com>
>>
>> Kvmtool suppresses any output to a console that has not been elected
>> as *the* console.
>>
>> While this makes sense on the input side (we want the input to be sent
>> to one console driver only), it seems to be the wrong thing to do on
>> the output side, as it effectively prevents the guest from switching
>> from one console to another (think earlyprintk using 8250 to virtio
>> console).
>>
>> After all, the guest *does* poke this device and outputs something
>> there.
>>
>> Just remove the kvm->cfg.active_console test from the output paths.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> Signed-off-by: Will Deacon <will.deacon@arm.com>
>
> Seems reasonable. Asias, Sasha?

This patch itself looks good to me.

But we have more issues for the console devices and termials with
regard to multiple console support:

1) All the console outputs (spapr_hvcons.c, spapr_rtas.c
virtio/console.c) are redirected to term 0.
2) With multiple console support, the cfg.active_console logic is not
very useful at all.
3) Four serial devices ttyS0-3 are initialized unconditionally and
mapped to term 0-3.
4) Using --tty option, we can map a term to /dev/pts/N on host. I
think we can merge --tty option to --console option.

I have something like this in my mind:

--console type=serial,backend=stdio
--console type=virtio,backend=pts
--console type=hv,backend=pts

e.g to add two serial consoles ttyS0 and ttyS1 and one virtio console
hvc0, ttyS0 is mapped the stdio and ttyS1 and hvc0 are mapped to pts,
we use this:

--console type=serial,backend=stdio  --console type=serial,backend=pts
 --console type=virtio,backend=pts


> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
Asias

Re: [RFC PATCH 04/11] kvm tools: console: unconditionally output to any console

[Sasha Levin]

On 05/03/2013 12:09 PM, Will Deacon wrote:
> On Fri, May 03, 2013 at 05:02:14PM +0100, Sasha Levin wrote:
>> On 05/03/2013 05:19 AM, Pekka Enberg wrote:
>>> On Wed, May 1, 2013 at 6:50 PM, Will Deacon <will.deacon@arm.com> wrote:
>>>> From: Marc Zyngier <Marc.Zyngier@arm.com>
>>>>
>>>> Kvmtool suppresses any output to a console that has not been elected
>>>> as *the* console.
>>>>
>>>> While this makes sense on the input side (we want the input to be sent
>>>> to one console driver only), it seems to be the wrong thing to do on
>>>> the output side, as it effectively prevents the guest from switching
>>>> from one console to another (think earlyprintk using 8250 to virtio
>>>> console).
>>>>
>>>> After all, the guest *does* poke this device and outputs something
>>>> there.
>>>>
>>>> Just remove the kvm->cfg.active_console test from the output paths.
>>>>
>>>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>>>> Signed-off-by: Will Deacon <will.deacon@arm.com>
>>>
>>> Seems reasonable. Asias, Sasha?
>>>
>>
>> I remember at trying it some time ago but dropped it for a reason I don't
>> remember at the moment.
>>
>> Can I have the weekend to play with it to try and figure out why?
> 
> There's no rush from my point of view (hence the RFC) so take as long as you
> need!

Looks good to me!


Thanks,
Sasha

Re: [RFC PATCH 04/11] kvm tools: console: unconditionally output to any console

[Anup Patel]

On Tue, May 7, 2013 at 2:34 AM, Sasha Levin <sasha.levin@oracle.com> wrote:
> On 05/03/2013 12:09 PM, Will Deacon wrote:
>> On Fri, May 03, 2013 at 05:02:14PM +0100, Sasha Levin wrote:
>>> On 05/03/2013 05:19 AM, Pekka Enberg wrote:
>>>> On Wed, May 1, 2013 at 6:50 PM, Will Deacon <will.deacon@arm.com> wrote:
>>>>> From: Marc Zyngier <Marc.Zyngier@arm.com>
>>>>>
>>>>> Kvmtool suppresses any output to a console that has not been elected
>>>>> as *the* console.
>>>>>
>>>>> While this makes sense on the input side (we want the input to be sent
>>>>> to one console driver only), it seems to be the wrong thing to do on
>>>>> the output side, as it effectively prevents the guest from switching
>>>>> from one console to another (think earlyprintk using 8250 to virtio
>>>>> console).
>>>>>
>>>>> After all, the guest *does* poke this device and outputs something
>>>>> there.
>>>>>
>>>>> Just remove the kvm->cfg.active_console test from the output paths.
>>>>>
>>>>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>>>>> Signed-off-by: Will Deacon <will.deacon@arm.com>
>>>>
>>>> Seems reasonable. Asias, Sasha?
>>>>
>>>
>>> I remember at trying it some time ago but dropped it for a reason I don't
>>> remember at the moment.
>>>
>>> Can I have the weekend to play with it to try and figure out why?
>>
>> There's no rush from my point of view (hence the RFC) so take as long as you
>> need!
>
> Looks good to me!
>
>
> Thanks,
> Sasha
>

I am fine with having 8250 emulated by KVMTOOL, but I am more inclined towards
having a full para-virtualized (PV) machine emulated by KVMTOOL.

Best Regards,
Anup

Re: [RFC PATCH 00/11] kvm tools: allow ioport emulation to be used on ARM

[Pekka Enberg]

On Fri, May 3, 2013 at 9:53 AM, Michael Ellerman <michael@ellerman.id.au> wrote:
> On Wed, 2013-05-01 at 16:50 +0100, Will Deacon wrote:
>> Hi guys,
>>
>> This RFC series does a number of things, but the main goal is to allow
>> re-use of the emulation code under hw/ on architectures other than x86.
>> It also comes about after discussions concerning virtio-console for
>> earlyprintk:
>>
>>   http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/165605.html
>>
>> The first 5 patches in this series allow the 8250 emulation to be used
>> for earlyprintk (i.e. output only) on aarch64 platforms. The remaining 7
>> patches generalise this to potentially any ioport devices, with DT node
>> generation and interrupt routing.
>>
>> All comments welcome,
>
> I have nothing to add on the content, but they build on powerpc so I'm
> happy :)

I applied the series. Thanks guys!