Re: [Qemu-devel] [PATCH v1 3/3] raspi: Add "raspi3" machine type

[Pekka Enberg]

Hi,

On 02/15/2018 02:39 PM, Peter Maydell wrote:

On 8 February 2018 at 05:50, Pekka Enberg <penb...@iki.fi> wrote:

This patch adds a "raspi3" machine type, which can now be selected as
the machine to run on by users via the "-M" command line option to QEMU.

The machine type does *not* ignore memory transaction failures so we
likely need to add some dummy devices later when people run something
more complicated than what I'm using for testing.

Signed-off-by: Pekka Enberg <penb...@iki.fi>
---
  hw/arm/raspi.c | 21 +
  1 file changed, 21 insertions(+)

diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index 66fe10e376..048ff23a51 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -187,3 +187,24 @@ static void raspi2_machine_init(MachineClass *mc)
  mc->ignore_memory_transaction_failures = true;
  };
  DEFINE_MACHINE("raspi2", raspi2_machine_init)
+
+static void raspi3_init(MachineState *machine)
+{
+raspi_init(machine, 3);
+}
+
+static void raspi3_machine_init(MachineClass *mc)
+{
+mc->desc = "Raspberry Pi 3";
+mc->init = raspi3_init;
+mc->block_default_type = IF_SD;
+mc->no_parallel = 1;
+mc->no_floppy = 1;
+mc->no_cdrom = 1;
+mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-a53");
+mc->max_cpus = BCM2836_NCPUS;
+mc->min_cpus = BCM2836_NCPUS;
+mc->default_cpus = BCM2836_NCPUS;
+mc->default_ram_size = 1024 * 1024 * 1024;
+}
+DEFINE_MACHINE("raspi3", raspi3_machine_init)


Hi. This patch breaks "make check", because it adds the raspi3
to the arm-softmmu (32-bit guest CPUs only) build, where the
cortex-a53 CPU doesn't exist:

e104462:xenial:qemu$ ./build/x86/arm-softmmu/qemu-system-arm -M raspi3
**
ERROR:/home/petmay01/linaro/qemu-from-laptop/qemu/qom/object.c:372:object_initialize_with_type:
assertion failed: (type != NULL)
Aborted (core dumped)

The usual way we avoid this is that 64-bit only boards are
in their own source file, which is only compiled if the right
CONFIG_FOO is set by default-configs/aarch64-softmmu.mak.
In this case splitting the 64-bit board into its own source
file would be weird and awkward, so the simple thing is to
guard the raspi3 bits with #ifdef TARGET_AARCH64.

(You might think we could define a CONFIG_RASPI3 in
aarch64-softmmu.mak and #ifdef on it, but for some reason
we don't expose those CONFIG_* to C code, possibly just because
we've never needed to in the past...)

Since this was the only code change needed, I'm just going to make
it and apply the patchset to target-arm.next, rather than ask
you to do a respin. (There was also a stray space-at-end-of-line
in patch 2 which checkpatch grumbles about; I'll fix that up too.)


Oh, it would have helped if I had actually read the whole thread before 
sending out v2. If I understood correctly, you only applied the first 
two patches (sorry about that trailing whitespace!). You therefore can 
just pick patch 3 from the v2 as the first two patches are unchanged.


Regards,

- Pekka

Re: [Qemu-devel] [PATCH v1 1/3] bcm2836: Make CPU type configurable

[Pekka Enberg]

On 02/15/2018 01:48 PM, Peter Maydell wrote:

On 8 February 2018 at 05:50, Pekka Enberg <penb...@iki.fi> wrote:

This patch adds a "cpu-type" property to BCM2836 SoC in preparation for
reusing the code for the Raspberry Pi 3, which has a different processor
model.

Signed-off-by: Pekka Enberg <penb...@iki.fi>



--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -135,6 +135,8 @@ static void raspi2_init(MachineState *machine)
  /* Setup the SOC */
  object_property_add_const_link(OBJECT(>soc), "ram", OBJECT(>ram),
 _abort);
+object_property_set_str(OBJECT(>soc), machine->cpu_type, "cpu-type",
+_abort);
  object_property_set_int(OBJECT(>soc), smp_cpus, "enabled-cpus",
  _abort);
  object_property_set_int(OBJECT(>soc), 0xa21041, "board-rev",
@@ -166,6 +168,7 @@ static void raspi2_machine_init(MachineClass *mc)
  mc->no_parallel = 1;
  mc->no_floppy = 1;
  mc->no_cdrom = 1;
+mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-a15");
  mc->max_cpus = BCM2836_NCPUS;
  mc->min_cpus = BCM2836_NCPUS;
  mc->default_cpus = BCM2836_NCPUS;


This change means that instead of ignoring the user's -cpu argument
we'll now unconditionally accept it even if it's nonsense for this
board. Neither behaviour is great. However, the patchset to allow
boards to easily specify the valid set of CPU types is still in
code review:
https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg00308.html

so I'm happy to take this as-is, and we'll add the validity check
when that patchset goes in.


I wondered about that too, but I applied the "monkey see, monkey do" 
approach to your review comments of the previous attempt. :-) But 
indeed, I also think we can fix this later in the tree.


- Pekka

[Qemu-devel] [PATCH v2 2/3] raspi: Raspberry Pi 3 support

[Pekka Enberg]

This patch adds Raspberry Pi 3 support to hw/arm/raspi.c. The
differences to Pi 2 are:

 - Firmware address
 - Board ID
 - Board revision

The CPU is different too, but that's going to be configured as part of
the machine default CPU when we introduce a new machine type.

The patch was written from scratch by me but the logic is similar to
Zoltán Baldaszti's previous work, which I used as a reference (with
permission from the author):

  https://github.com/bztsrc/qemu-raspi3

Signed-off-by: Pekka Enberg <penb...@iki.fi>
---
 hw/arm/raspi.c | 31 +--
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index c24a4a1b14..66fe10e376 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -5,6 +5,9 @@
  * Rasperry Pi 2 emulation Copyright (c) 2015, Microsoft
  * Written by Andrew Baumann
  *
+ * Raspberry Pi 3 emulation Copyright (c) 2018 Zoltán Baldaszti
+ * Upstream code cleanup (c) 2018 Pekka Enberg 
+ *
  * This code is licensed under the GNU GPLv2 and later.
  */
 
@@ -22,10 +25,11 @@
 #define SMPBOOT_ADDR0x300 /* this should leave enough space for ATAGS */
 #define MVBAR_ADDR  0x400 /* secure vectors */
 #define BOARDSETUP_ADDR (MVBAR_ADDR + 0x20) /* board setup code */
-#define FIRMWARE_ADDR   0x8000 /* Pi loads kernel.img here by default */
+#define FIRMWARE_ADDR_2 0x8000 /* Pi 2 loads kernel.img here by default */
+#define FIRMWARE_ADDR_3 0x8 /* Pi 3 loads kernel.img here by default */
 
 /* Table of Linux board IDs for different Pi versions */
-static const int raspi_boardid[] = {[1] = 0xc42, [2] = 0xc43};
+static const int raspi_boardid[] = {[1] = 0xc42, [2] = 0xc43, [3] = 0xc44};
 
 typedef struct RasPiState {
 BCM2836State soc;
@@ -83,8 +87,8 @@ static void setup_boot(MachineState *machine, int version, 
size_t ram_size)
 binfo.secure_board_setup = true;
 binfo.secure_boot = true;
 
-/* Pi2 requires SMP setup */
-if (version == 2) {
+/* Pi2 and Pi3 requires SMP setup */
+if (version >= 2) {
 binfo.smp_loader_start = SMPBOOT_ADDR;
 binfo.write_secondary_boot = write_smpboot;
 binfo.secondary_cpu_reset_hook = reset_secondary;
@@ -94,15 +98,16 @@ static void setup_boot(MachineState *machine, int version, 
size_t ram_size)
  * the normal Linux boot process
  */
 if (machine->firmware) {
+hwaddr firmware_addr = version == 3 ? FIRMWARE_ADDR_3 : 
FIRMWARE_ADDR_2;
 /* load the firmware image (typically kernel.img) */
-r = load_image_targphys(machine->firmware, FIRMWARE_ADDR,
-ram_size - FIRMWARE_ADDR);
+r = load_image_targphys(machine->firmware, firmware_addr,
+ram_size - firmware_addr);
 if (r < 0) {
 error_report("Failed to load firmware from %s", machine->firmware);
 exit(1);
 }
 
-binfo.entry = FIRMWARE_ADDR;
+binfo.entry = firmware_addr;
 binfo.firmware_loaded = true;
 } else {
 binfo.kernel_filename = machine->kernel_filename;
@@ -113,7 +118,7 @@ static void setup_boot(MachineState *machine, int version, 
size_t ram_size)
 arm_load_kernel(ARM_CPU(first_cpu), );
 }
 
-static void raspi2_init(MachineState *machine)
+static void raspi_init(MachineState *machine, int version)
 {
 RasPiState *s = g_new0(RasPiState, 1);
 uint32_t vcram_size;
@@ -139,7 +144,8 @@ static void raspi2_init(MachineState *machine)
 _abort);
 object_property_set_int(OBJECT(>soc), smp_cpus, "enabled-cpus",
 _abort);
-object_property_set_int(OBJECT(>soc), 0xa21041, "board-rev",
+int board_rev = version == 3 ? 0xa02082 : 0xa21041;
+object_property_set_int(OBJECT(>soc), board_rev, "board-rev",
 _abort);
 object_property_set_bool(OBJECT(>soc), true, "realized", _abort);
 
@@ -157,7 +163,12 @@ static void raspi2_init(MachineState *machine)
 
 vcram_size = object_property_get_uint(OBJECT(>soc), "vcram-size",
   _abort);
-setup_boot(machine, 2, machine->ram_size - vcram_size);
+setup_boot(machine, version, machine->ram_size - vcram_size);
+}
+
+static void raspi2_init(MachineState *machine)
+{
+raspi_init(machine, 2);
 }
 
 static void raspi2_machine_init(MachineClass *mc)
-- 
2.14.3

[Qemu-devel] [PATCH v2 3/3] raspi: Add "raspi3" machine type

[Pekka Enberg]

This patch adds a "raspi3" machine type, which can now be selected as
the machine to run on by users via the "-M" command line option to QEMU.

The machine type does *not* ignore memory transaction failures so we
likely need to add some dummy devices later when people run something
more complicated than what I'm using for testing.

Signed-off-by: Pekka Enberg <penb...@iki.fi>
---
 hw/arm/raspi.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index 66fe10e376..ff54f45e3e 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -187,3 +187,26 @@ static void raspi2_machine_init(MachineClass *mc)
 mc->ignore_memory_transaction_failures = true;
 };
 DEFINE_MACHINE("raspi2", raspi2_machine_init)
+
+#ifdef TARGET_AARCH64
+static void raspi3_init(MachineState *machine)
+{
+raspi_init(machine, 3);
+}
+
+static void raspi3_machine_init(MachineClass *mc)
+{
+mc->desc = "Raspberry Pi 3";
+mc->init = raspi3_init;
+mc->block_default_type = IF_SD;
+mc->no_parallel = 1;
+mc->no_floppy = 1;
+mc->no_cdrom = 1;
+mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-a53");
+mc->max_cpus = BCM2836_NCPUS;
+mc->min_cpus = BCM2836_NCPUS;
+mc->default_cpus = BCM2836_NCPUS;
+mc->default_ram_size = 1024 * 1024 * 1024;
+}
+DEFINE_MACHINE("raspi3", raspi3_machine_init)
+#endif
-- 
2.14.3

[Qemu-devel] [PATCH v2 1/3] bcm2836: Make CPU type configurable

[Pekka Enberg]

This patch adds a "cpu-type" property to BCM2836 SoC in preparation for
reusing the code for the Raspberry Pi 3, which has a different processor
model.

Signed-off-by: Pekka Enberg <penb...@iki.fi>
---
 hw/arm/bcm2836.c | 17 +
 hw/arm/raspi.c   |  3 +++
 include/hw/arm/bcm2836.h |  1 +
 3 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/hw/arm/bcm2836.c b/hw/arm/bcm2836.c
index 8c43291112..40e8b25a46 100644
--- a/hw/arm/bcm2836.c
+++ b/hw/arm/bcm2836.c
@@ -26,14 +26,6 @@
 static void bcm2836_init(Object *obj)
 {
 BCM2836State *s = BCM2836(obj);
-int n;
-
-for (n = 0; n < BCM2836_NCPUS; n++) {
-object_initialize(>cpus[n], sizeof(s->cpus[n]),
-  "cortex-a15-" TYPE_ARM_CPU);
-object_property_add_child(obj, "cpu[*]", OBJECT(>cpus[n]),
-  _abort);
-}
 
 object_initialize(>control, sizeof(s->control), TYPE_BCM2836_CONTROL);
 object_property_add_child(obj, "control", OBJECT(>control), NULL);
@@ -59,6 +51,14 @@ static void bcm2836_realize(DeviceState *dev, Error **errp)
 
 /* common peripherals from bcm2835 */
 
+obj = OBJECT(dev);
+for (n = 0; n < BCM2836_NCPUS; n++) {
+object_initialize(>cpus[n], sizeof(s->cpus[n]),
+  s->cpu_type);
+object_property_add_child(obj, "cpu[*]", OBJECT(>cpus[n]),
+  _abort);
+}
+
 obj = object_property_get_link(OBJECT(dev), "ram", );
 if (obj == NULL) {
 error_setg(errp, "%s: required ram link not found: %s",
@@ -150,6 +150,7 @@ static void bcm2836_realize(DeviceState *dev, Error **errp)
 }
 
 static Property bcm2836_props[] = {
+DEFINE_PROP_STRING("cpu-type", BCM2836State, cpu_type),
 DEFINE_PROP_UINT32("enabled-cpus", BCM2836State, enabled_cpus, 
BCM2836_NCPUS),
 DEFINE_PROP_END_OF_LIST()
 };
diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index cd5fa8c3dc..c24a4a1b14 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -135,6 +135,8 @@ static void raspi2_init(MachineState *machine)
 /* Setup the SOC */
 object_property_add_const_link(OBJECT(>soc), "ram", OBJECT(>ram),
_abort);
+object_property_set_str(OBJECT(>soc), machine->cpu_type, "cpu-type",
+_abort);
 object_property_set_int(OBJECT(>soc), smp_cpus, "enabled-cpus",
 _abort);
 object_property_set_int(OBJECT(>soc), 0xa21041, "board-rev",
@@ -166,6 +168,7 @@ static void raspi2_machine_init(MachineClass *mc)
 mc->no_parallel = 1;
 mc->no_floppy = 1;
 mc->no_cdrom = 1;
+mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-a15");
 mc->max_cpus = BCM2836_NCPUS;
 mc->min_cpus = BCM2836_NCPUS;
 mc->default_cpus = BCM2836_NCPUS;
diff --git a/include/hw/arm/bcm2836.h b/include/hw/arm/bcm2836.h
index 76de1996af..4758b4ae54 100644
--- a/include/hw/arm/bcm2836.h
+++ b/include/hw/arm/bcm2836.h
@@ -25,6 +25,7 @@ typedef struct BCM2836State {
 DeviceState parent_obj;
 /*< public >*/
 
+char *cpu_type;
 uint32_t enabled_cpus;
 
 ARMCPU cpus[BCM2836_NCPUS];
-- 
2.14.3

[Qemu-devel] [PATCH v2 0/3] Raspberry Pi 3 support

[Pekka Enberg]

This patch series adds support for Raspberry Pi 3 as a new machine model
"raspi3", which is an extension of the "raspi2" model with the following
differences:

  - Default CPU type is "cortex-a53"
  - Firmware is at address 0x8
  - Board ID is 0xc44 and board revision is 0xa02082

The patches were written by me but I used Zoltán Baldaszti's previous
work as a reference (with permission from the author):

  https://github.com/bztsrc/qemu-raspi3

Also available from:

  g...@github.com:penberg/qemu.git raspi3/v2

Changes from v1 to v2:

- Wrap Raspberry Pi 3 machine definition with TARGET_AARCH64 (Peter
  Maydell)

Pekka Enberg (3):
  bcm2836: Make CPU type configurable
  raspi: Raspberry Pi 3 support
  raspi: Add "raspi3" machine type

 hw/arm/bcm2836.c | 17 ---
 hw/arm/raspi.c   | 57 +++-
 include/hw/arm/bcm2836.h |  1 +
 3 files changed, 57 insertions(+), 18 deletions(-)

-- 
2.14.3

[Qemu-devel] [PATCH v1 2/3] raspi: Raspberry Pi 3 support

[Pekka Enberg]

This patch adds Raspberry Pi 3 support to hw/arm/raspi.c. The
differences to Pi 2 are:

 - Firmware address
 - Board ID
 - Board revision

The CPU is different too, but that's going to be configured as part of
the machine default CPU when we introduce a new machine type.

The patch was written from scratch by me but the logic is similar to
Zoltán Baldaszti's previous work, which I used as a reference (with
permission from the author):

  https://github.com/bztsrc/qemu-raspi3

Signed-off-by: Pekka Enberg <penb...@iki.fi>
---
 hw/arm/raspi.c | 31 +--
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index c24a4a1b14..66fe10e376 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -5,6 +5,9 @@
  * Rasperry Pi 2 emulation Copyright (c) 2015, Microsoft
  * Written by Andrew Baumann
  *
+ * Raspberry Pi 3 emulation Copyright (c) 2018 Zoltán Baldaszti
+ * Upstream code cleanup (c) 2018 Pekka Enberg 
+ *
  * This code is licensed under the GNU GPLv2 and later.
  */
 
@@ -22,10 +25,11 @@
 #define SMPBOOT_ADDR0x300 /* this should leave enough space for ATAGS */
 #define MVBAR_ADDR  0x400 /* secure vectors */
 #define BOARDSETUP_ADDR (MVBAR_ADDR + 0x20) /* board setup code */
-#define FIRMWARE_ADDR   0x8000 /* Pi loads kernel.img here by default */
+#define FIRMWARE_ADDR_2 0x8000 /* Pi 2 loads kernel.img here by default */
+#define FIRMWARE_ADDR_3 0x8 /* Pi 3 loads kernel.img here by default */
 
 /* Table of Linux board IDs for different Pi versions */
-static const int raspi_boardid[] = {[1] = 0xc42, [2] = 0xc43};
+static const int raspi_boardid[] = {[1] = 0xc42, [2] = 0xc43, [3] = 0xc44};
 
 typedef struct RasPiState {
 BCM2836State soc;
@@ -83,8 +87,8 @@ static void setup_boot(MachineState *machine, int version, 
size_t ram_size)
 binfo.secure_board_setup = true;
 binfo.secure_boot = true;
 
-/* Pi2 requires SMP setup */
-if (version == 2) {
+/* Pi2 and Pi3 requires SMP setup */
+if (version >= 2) {
 binfo.smp_loader_start = SMPBOOT_ADDR;
 binfo.write_secondary_boot = write_smpboot;
 binfo.secondary_cpu_reset_hook = reset_secondary;
@@ -94,15 +98,16 @@ static void setup_boot(MachineState *machine, int version, 
size_t ram_size)
  * the normal Linux boot process
  */
 if (machine->firmware) {
+hwaddr firmware_addr = version == 3 ? FIRMWARE_ADDR_3 : 
FIRMWARE_ADDR_2;
 /* load the firmware image (typically kernel.img) */
-r = load_image_targphys(machine->firmware, FIRMWARE_ADDR,
-ram_size - FIRMWARE_ADDR);
+r = load_image_targphys(machine->firmware, firmware_addr,
+ram_size - firmware_addr);
 if (r < 0) {
 error_report("Failed to load firmware from %s", machine->firmware);
 exit(1);
 }
 
-binfo.entry = FIRMWARE_ADDR;
+binfo.entry = firmware_addr;
 binfo.firmware_loaded = true;
 } else {
 binfo.kernel_filename = machine->kernel_filename;
@@ -113,7 +118,7 @@ static void setup_boot(MachineState *machine, int version, 
size_t ram_size)
 arm_load_kernel(ARM_CPU(first_cpu), );
 }
 
-static void raspi2_init(MachineState *machine)
+static void raspi_init(MachineState *machine, int version)
 {
 RasPiState *s = g_new0(RasPiState, 1);
 uint32_t vcram_size;
@@ -139,7 +144,8 @@ static void raspi2_init(MachineState *machine)
 _abort);
 object_property_set_int(OBJECT(>soc), smp_cpus, "enabled-cpus",
 _abort);
-object_property_set_int(OBJECT(>soc), 0xa21041, "board-rev",
+int board_rev = version == 3 ? 0xa02082 : 0xa21041;
+object_property_set_int(OBJECT(>soc), board_rev, "board-rev",
 _abort);
 object_property_set_bool(OBJECT(>soc), true, "realized", _abort);
 
@@ -157,7 +163,12 @@ static void raspi2_init(MachineState *machine)
 
 vcram_size = object_property_get_uint(OBJECT(>soc), "vcram-size",
   _abort);
-setup_boot(machine, 2, machine->ram_size - vcram_size);
+setup_boot(machine, version, machine->ram_size - vcram_size);
+}
+
+static void raspi2_init(MachineState *machine)
+{
+raspi_init(machine, 2);
 }
 
 static void raspi2_machine_init(MachineClass *mc)
-- 
2.14.3

[Qemu-devel] [PATCH v1 3/3] raspi: Add "raspi3" machine type

[Pekka Enberg]

This patch adds a "raspi3" machine type, which can now be selected as
the machine to run on by users via the "-M" command line option to QEMU.

The machine type does *not* ignore memory transaction failures so we
likely need to add some dummy devices later when people run something
more complicated than what I'm using for testing.

Signed-off-by: Pekka Enberg <penb...@iki.fi>
---
 hw/arm/raspi.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index 66fe10e376..048ff23a51 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -187,3 +187,24 @@ static void raspi2_machine_init(MachineClass *mc)
 mc->ignore_memory_transaction_failures = true;
 };
 DEFINE_MACHINE("raspi2", raspi2_machine_init)
+
+static void raspi3_init(MachineState *machine)
+{
+raspi_init(machine, 3);
+}
+
+static void raspi3_machine_init(MachineClass *mc)
+{
+mc->desc = "Raspberry Pi 3";
+mc->init = raspi3_init;
+mc->block_default_type = IF_SD;
+mc->no_parallel = 1;
+mc->no_floppy = 1;
+mc->no_cdrom = 1;
+mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-a53");
+mc->max_cpus = BCM2836_NCPUS;
+mc->min_cpus = BCM2836_NCPUS;
+mc->default_cpus = BCM2836_NCPUS;
+mc->default_ram_size = 1024 * 1024 * 1024;
+}
+DEFINE_MACHINE("raspi3", raspi3_machine_init)
-- 
2.14.3

[Qemu-devel] [PATCH v1 0/3] Raspberry Pi 3 support

[Pekka Enberg]

This patch series adds support for Raspberry Pi 3 as a new machine model
"raspi3", which is an extension of the "raspi2" model with the following
differences:

  - Default CPU type is "cortex-a53"
  - Firmware is at address 0x8
  - Board ID is 0xc44 and board revision is 0xa02082

The patches were written by me but I used Zoltán Baldaszti's previous
work as a reference (with permission from the author):

  https://github.com/bztsrc/qemu-raspi3

Also available from:

  g...@github.com:penberg/qemu.git raspi3/v1

Pekka Enberg (3):
  bcm2836: Make CPU type configurable
  raspi: Raspberry Pi 3 support
  raspi: Add "raspi3" machine type

 hw/arm/bcm2836.c | 17 ---
 hw/arm/raspi.c   | 55 +++-
 include/hw/arm/bcm2836.h |  1 +
 3 files changed, 55 insertions(+), 18 deletions(-)

-- 
2.14.3

Re: [Qemu-devel] KVM/QEMU on Raspberry Pi 3

[Pekka Enberg]

Hi,

On 02/02/2017 19.48, Ard Biesheuvel wrote:

$ git grep -C5 -ni 0x1DE7EC7EDBADC0DE
arch/arm64/kvm/sys_regs.h-105-static inline void reset_unknown(struct
kvm_vcpu *vcpu,
arch/arm64/kvm/sys_regs.h-106-   const struct
sys_reg_desc *r)
arch/arm64/kvm/sys_regs.h-107-{
arch/arm64/kvm/sys_regs.h-108-  BUG_ON(!r->reg);
arch/arm64/kvm/sys_regs.h-109-  BUG_ON(r->reg >= NR_SYS_REGS);
arch/arm64/kvm/sys_regs.h:110:  vcpu_sys_reg(vcpu, r->reg) =
0x1de7ec7edbadc0deULL;
arch/arm64/kvm/sys_regs.h-111-}
arch/arm64/kvm/sys_regs.h-112-

In other words (or rather, in words), KVM is triggering this exception
in the guest deliberately, which I suspect has something to do with
the lack of a GIC? Are you using these patches Peter mentions?


No, I'm not using Peter's patches. It's mainline Fedora 24 and rawhide QEMU.

- Pekka

[Qemu-devel] KVM/QEMU on Raspberry Pi 3

[Pekka Enberg]

Hi,

Has anyone been able to successfully run QEMU/KVM under Raspberry Pi 3?

I have installed 64-bit Fedora 24 by Gerd Hoffmann on the hardware:

  https://www.kraxel.org/blog/2016/04/fedora-on-raspberry-pi-updates/

and built a VM image using virt-builder:

  virt-builder --root-password password:root --arch aarch64 fedora-24

I also built the latest UEFI for QEMU from sources:

  https://wiki.linaro.org/LEG/UEFIforQEMU

and updated to QEMU 2.8.0 from rawhide:

  [root@fedora-rpi2 ~]# qemu-system-aarch64 -version
  QEMU emulator version 2.8.0(qemu-2.8.0-1.fc26)
  Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers

The VM image should be fine because I’m able to boot to it under CPU 
emulation:


qemu-system-aarch64 \
  -nographic \
  -M virt \
  -cpu cortex-a57 \
  -smp 1 \
  -m 512 \
  -bios QEMU_EFI.fd \
  -device virtio-blk-device,drive=image -drive 
if=none,id=image,file=fedora-24.img \
  -netdev bridge,id=hn0,br=virbr0 -device 
virtio-net-pci,netdev=hn0,romfile= \

  -device virtio-rng-pci

However, when I enable KVM, keyboard stops working (interrupt delivery 
issue?) and Fedora boot process hangs at random places before reaching 
login:


qemu-system-aarch64 \
-nographic \
-M virt \
-cpu host \
-enable-kvm \
-smp 1 \
-m 512 \
-bios QEMU_EFI.fd \
-device virtio-blk-device,drive=image -drive 
if=none,id=image,file=$IMAGE \
	-netdev bridge,id=hn0,br=virbr0 -device 
virtio-net-pci,netdev=hn0,romfile= \

-device virtio-rng-pci

EFI stub: Booting Linux Kernel...
ConvertPages: Incompatible memory types
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.9.5-100.fc24.aarch64 
(mockbu...@aarch64-06a.arm.fedoraproject.org) (gcc version 6.3.1 
20161221 (Red Hat 6.3.1-1) (GCC) ) #1 SMP Tue Jan 24 21:12:07 UTC 2017

[0.00] Boot CPU: AArch64 Processor [410fd034]
[0.00] debug: ignoring loglevel setting.
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: EFI v2.60 by EDK II
[0.00] efi:  SMBIOS 3.0=0x5871  ACPI 2.0=0x589b 
MEMATTR=0x59c03218

[0.00] cma: Failed to reserve 512 MiB
[0.00] NUMA: No NUMA configuration found
[0.00] NUMA: Faking a node at [mem 
0x-0x5fff]

[0.00] NUMA: Adding memblock [0x4000 - 0x585b] on node 0
[0.00] NUMA: Adding memblock [0x585c - 0x5861] on node 0
[0.00] NUMA: Adding memblock [0x5862 - 0x586f] on node 0
[0.00] NUMA: Adding memblock [0x5870 - 0x58b6] on node 0
[0.00] NUMA: Adding memblock [0x58b7 - 0x5be3] on node 0
[0.00] NUMA: Adding memblock [0x5be4 - 0x5bec] on node 0
[0.00] NUMA: Adding memblock [0x5bed - 0x5bed] on node 0
[0.00] NUMA: Adding memblock [0x5bee - 0x5bff] on node 0
[0.00] NUMA: Adding memblock [0x5c00 - 0x5fff] on node 0
[0.00] NUMA: Initmem setup node 0 [mem 0x4000-0x5fff]
[0.00] NUMA: NODE_DATA [mem 0x5ff62680-0x5ff6]
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x4000-0x5fff]
[0.00]   Normal   empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x4000-0x585b]
[0.00]   node   0: [mem 0x585c-0x5861]
[0.00]   node   0: [mem 0x5862-0x586f]
[0.00]   node   0: [mem 0x5870-0x58b6]
[0.00]   node   0: [mem 0x58b7-0x5be3]
[0.00]   node   0: [mem 0x5be4-0x5bec]
[0.00]   node   0: [mem 0x5bed-0x5bed]
[0.00]   node   0: [mem 0x5bee-0x5bff]
[0.00]   node   0: [mem 0x5c00-0x5fff]
[0.00] Initmem setup node 0 [mem 
0x4000-0x5fff]

[0.00] On node 0 totalpages: 8192
[0.00]   DMA zone: 8 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 8192 pages, LIFO batch:0
[0.00] psci: probing for conduit method from DT.
[0.00] psci: PSCIv0.2 detected in firmware.
[0.00] psci: Using standard PSCI v0.2 function IDs
[0.00] psci: Trusted OS migration not required
[0.00] percpu: Embedded 3 pages/cpu @80001ff0 s114840 
r8192 d73576 u196608

[0.00] pcpu-alloc: s114840 r8192 d73576 u196608 alloc=3*65536
[0.00] pcpu-alloc: [0] 0
[0.00] Detected VIPT I-cache on CPU0
[0.00] Built 1 zonelists in Node order, mobility grouping off. 
Total pages: 8184

[0.00] 

[Qemu-devel] [ANNOUNCE] OSv, an new operating system for the cloud, v0.01

[Pekka Enberg]

Hello,

We're proud to announce release 0.01 of OSv, a new operating system
for running applications on virtual machines. OSv is free software,
released under the BSD license, and you can find it in
https://github.com/cloudius-systems/osv and http://www.osv.io.

To build and run OSv under KVM/QEMU, first grab the latest source code
from Github:

  git clone g...@github.com:cloudius-systems/osv.git

Then install prerequisite packages:

   On Fedora:
 yum install ant autoconf automake boost-static gcc-c++ genromfs \
libvirt libtool zfs-fuse flex bison

   On Debian:
 apt-get install libboost-all-dev genromfs zfs-fuse autoconf

Make sure the zfs-fuse daemon is running:

   On Fedora:
 sudo systemctl start zfs-fuse.service
 sudo systemctl enable zfs-fuse.service # to have it start on reboot

   On Debian the daemon should be started automatically.

Fetch git submodules:

git submodule update --init

Finally, build OSv:

  make external all

You can then start a OSv guest under KVM/QEMU:

  sudo ./scripts/run.py -nv -m 2G

You can SSH into the guest with:

  ssh admin@192.168.122.89 # password: admin

The management web UI is at address:

  http://192.168.122.89:8080/

Alternatively, you can use prebuilt QEMU QCOW2 images of the release.
Instructions how to do that are on our Wiki:

https://github.com/cloudius-systems/osv/wiki/Running-OSv-under-KVM-QEMU

That's it!

Pekka

Re: [Qemu-devel] [F.A.Q.] perf ABI backwards and forwards compatibility

[Pekka Enberg]

On Tue, 8 Nov 2011, Theodore Tso wrote:
It's great to hear that!   But in that case, there's an experiment we 
can't really run, which is if perf had been developed in a separate 
tree, would it have been just as successful?


Experiment, eh?

We have the staging tree because it's a widely acknowledged belief that 
kernel code in the tree tends to improve over time compared to code that's 
sitting out of the tree. Are you disputing that belief?


If you don't dispute that, what makes you think the same effect 
doesn't apply to code that looks like Linux code and is developed the same 
way but runs in userspace?


Pekka

Re: [Qemu-devel] [F.A.Q.] perf ABI backwards and forwards compatibility

[Pekka Enberg]

On Tue, 8 Nov 2011, Theodore Tso wrote:
We have the staging tree because it's a widely acknowledged belief that 
kernel code in the tree tends to improve over time compared to code 
that's sitting out of the tree. Are you disputing that belief?


Kernel code in the kernel source tree improves; because that's where it 
will eventually end up --- linked against the kernel.


There are all sorts of dynamics in play that don't necessarily apply to 
userspace code.


Otherwise we could just link in all of the userspace code in a Linux 
distribution and magically expect it will get better, eh?   Not!


You just yourself said it's about the people. Why do you now think it's 
about linking against the kernel? I know I have hacked on various parts of 
the kernel that I have never linked to my kernel.


Pekka

Re: [Qemu-devel] [F.A.Q.] perf ABI backwards and forwards compatibility

[Pekka Enberg]

On Tue, 8 Nov 2011, Frank Ch. Eigler wrote:

Almost: they demonstrate that those parts of the ABI that these
particular perf commands rely on have been impressively compatible.
Do you have any sort of ABI coverage measurement, to see what
parts of the ABI these perf commands do not use?


It's pretty obvious that perf ABI is lacking on that department based on 
Vince's comments, isn't it?  There's an easy fix for this too: improve 
perf test to cover the cases you're intested in.  While ABI spec would 
be a nice addition, it's not going to make compatibility problems 
magically go away.


Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Tue, Nov 8, 2011 at 3:29 PM, Karel Zak k...@redhat.com wrote:
 I don't know if it makes sense to merge the tools you've mentioned above.
 My gut feeling is that it's probably not reasonable - there's already a
 community working on it with their own development process and coding
 style. I don't think there's a simple answer to this but I don't agree with
 your rather extreme position that all userspace tools should be kept out
 of the kernel tree.

 Ted's position is not extreme. He follows the simple and exactly defined
 border between userspace and kernel. The native userspace feature is
 variability and substitutability.

It's an extreme position because he's arguing that we should only have
kernel code in the tree or we need open up to all userspace code.

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Tue, Nov 8, 2011 at 4:52 PM, Christoph Hellwig h...@infradead.org wrote:
 Nevermind that running virtfs as a rootfs is a really dumb idea.  You
 do now want to run a VM that has a rootfs that gets changed all the
 time behind your back.

It's rootfs binaries that are shared, not configuration. It's
unfortunate but works OK for the single user use case it's meant for.
It's obviously not a proper solution for the generic case. We were
hoping that we could use something like overlayfs to hide the issue
under the rug. Do you think that's also a really dumb thing to do?

Using block device snapshotting would be interesting and we should
definitely look into that.

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Mon, Nov 7, 2011 at 10:00 AM, Paolo Bonzini pbonz...@redhat.com wrote:
 No, having the source code in Linux kernel tree is perfectly useless for the
 exceptional case, and forces you to go through extra hoops to build only one
 component.  Small hoops such as adding -- tools/kvm to git bisect start
 perhaps, but still hoops that aren't traded for a practical advantage.  You
 keep saying oh things have been so much better because it's so close to
 the kernel and it worked so great for perf, but you haven't brought any
 practical example that we can stare at in admiration.

The _practical example_ is the working software in tools/kvm!

 I have no idea why you're trying to convince me that it doesn't matter.

 I'm not trying to convince you that it doesn't matter, I'm trying to
 convince you that it doesn't *make sense*.

 It's a hypervisor that implements virtio drivers, serial
 emulation, and mini-BIOS.

 ... all of which have a spec against which you should be working.  Save
 perhaps for the mini-BIOS, if you develop against the kernel source rather
 than the spec you're doing it *wrong*.  Very wrong.  But you've been told
 this many times already.

I have zero interest in arguing with you about something you have no
practical experience on. I've tried both out-of-tree and in-tree
development for the KVM tool and I can tell you the latter is much
more productive environment.

We are obviously also using specifications but as you damn well should
know, specifications don't matter nearly as much as working code.
That's why it's important to have easy access to both.

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Mon, Nov 7, 2011 at 10:00 AM, Paolo Bonzini pbonz...@redhat.com wrote:
 (BTW, I'm also convinced like Ted that not having a defined perf ABI might
 have made sense in the beginning, but it has now devolved into bad software
 engineering practice).

I'm not a perf maintainer so I don't know what the situation with wrt.
ABI breakage is. Your or Ted's comments don't match my assumptions or
experience, though.

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On 11/07/2011 09:09 AM, Pekka Enberg wrote:

We are obviously also using specifications but as you damn well should
know, specifications don't matter nearly as much as working code.


On Mon, 7 Nov 2011, Paolo Bonzini wrote:
Specifications matter much more than working code.  Quirks are a fact of life 
but should always come second.


To quote Linus:

  And I have seen _lots_ of total crap work that was based on specs. It's
  _the_ single worst way to write software, because it by definition means
  that the software was written to match theory, not reality.

[ http://kerneltrap.org/node/5725 ]

So no, I don't agree with you at all.

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On 11/07/2011 09:45 AM, Pekka Enberg wrote:
 Specifications matter much more than working code.  Quirks are a fact
 of life but should always come second.

 To quote Linus:

   And I have seen _lots_ of total crap work that was based on specs. It's
 _the_ single worst way to write software, because it by definition means
   that the software was written to match theory, not reality.

On Mon, Nov 7, 2011 at 10:52 AM, Paolo Bonzini pbonz...@redhat.com wrote:
 All generalizations are false.

What is that supposed to mean? You claimed we're doing it wrong and
I explained you why we are doing it the way we are.

Really, the way we do things in the KVM tool is not a bug, it's a feature.

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Mon, Nov 7, 2011 at 12:11 PM, Gerd Hoffmann kra...@redhat.com wrote:
 No support for booting from CDROM.
 No support for booting from Network.
 Thus no way to install a new guest image.

Sure. It's a pain point which we need to fix.

On Mon, Nov 7, 2011 at 12:11 PM, Gerd Hoffmann kra...@redhat.com wrote:
 Booting an existing qcow2 guest image failed, the guest started throwing
 I/O errors.  And even to try that I had to manually extract the kernel
 and initrd images from the guest.  Maybe you should check with the Xen
 guys, they have a funky 'pygrub' which sort-of automates the
 copy-kernel-from-guest-image process.

QCOW2 support is experimental. The I/O errors are caused by forced
read-only mode.

On Mon, Nov 7, 2011 at 12:11 PM, Gerd Hoffmann kra...@redhat.com wrote:
 Booting the host kernel failed too.  Standard distro kernel.  The virtio
 bits are modular, not statically compiled into the kernel.  kvm tool
 can't handle that.

I think we have some support for booting modular distro kernels too if
you tell KVM tool where to find initrd. It sucks out-of-the-box though
because nobody seems to be using it.

On Mon, Nov 7, 2011 at 12:11 PM, Gerd Hoffmann kra...@redhat.com wrote:
 You have to build your own kernel and make sure you flip the correct
 config bits, then you can boot it to a shell prompt.  Trying anything
 else just doesn't work today ...

What can I say? Patches welcome? :-)

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Mon, 7 Nov 2011, Gerd Hoffmann wrote:

It's not just about code, it's as much about culture and development process.


Indeed.  The BSDs have both kernel and the base system in a single
repository.  There are probably good reasons for (and against) it.

In Linux we don't have that culture.  No tool (except perf) lives in the
kernel repo.  I fail to see why kvm-tool is that much different from
udev, util-linux, iproute, filesystem tools, that it should be included.


You seem to think perf is an exception - I think it's going to be the 
future norm for userspace components that are very close to the kernel. 
That's in fact what Ingo was arguing for when he suggested QEMU to be 
merged to the kernel tree.


Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Mon, 7 Nov 2011, Kevin Wolf wrote:

Makes it a lot less hackable for me unless you want to restrict the set
of potential developers to Linux kernel developers...


We're not restricting potential developers to Linux kernel folks. We're 
making it easy for them because we believe that the KVM tool is a 
userspace component that requires the kind of low-level knowledge Linux 
kernel developers have.


I think you're looking at the KVM tool with your QEMU glasses on without 
realizing that there's no point in comparing the two: we only support 
Linux on Linux and we avoid hardware emulation as much as possible. So 
what makes sense for QEMU, doesn't necessarily translate to the KVM tool 
project.


Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Mon, Nov 7, 2011 at 1:02 PM, Paolo Bonzini pbonz...@redhat.com wrote:
 Indeed I do not see any advantage, since all the interfaces they use are
 stable anyway (sysfs, msr.ko).

 If they had gone in x86info, for example, my distro (F16, not exactly
 conservative) would have likely picked those tools up already, but it
 didn't.

Distributing userspace tools in the kernel tree is a relatively new
concept so it's not at all surprising distributions don't pick them up
as quickly. That doesn't mean it's a fundamentally flawed approach,
though.

Also, I'm mostly interested in defending the KVM tool, so I'd prefer
not to argue whether or not carrying userspace code in the kernel tree
makes sense or not. The fact is that Linux is already doing it and I
think the only relevant question is whether or not the KVM tool
qualifies. I obviously think the answer is yes.

   Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Mon, Nov 7, 2011 at 2:18 PM, Gerd Hoffmann kra...@redhat.com wrote:
 tools/ lacks a separation into kernel hacker's testing+debugging
 toolbox and userspace tools.  It lacks proper buildsystem integration
 for the userspace tools, there is no make tools and also no make
 tools_install.  Silently dropping new stuff into tools/ and expecting
 the world magically noticing isn't going to work.

No disagreement here.

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

Hi Avi,

On Mon, Nov 7, 2011 at 2:26 PM, Avi Kivity a...@redhat.com wrote:
 tools/power was merged in just 2 versions ago, do you think that
 merging that was a mistake?

 Things like tools/power may make sense, most of the code is tied to the
 kernel interfaces.  tools/kvm is 20k lines and is likely to be 40k+
 lines or more before it is generally usable.  The proportion of the code
 that talks to the kernel is quite small.

So what do you think about perf then? The amount of code that talks to
the kernel is much smaller than that of the KVM tool.

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

Hi Ted,

On Mon, Nov 7, 2011 at 2:29 PM, Ted Ts'o ty...@mit.edu wrote:
 And the same problems will exist with kvm-tool.  What if you need to
 release a new version of kvm-tool?  Does that mean that you have to
 release a new set of kernel binaries?  It's a mess, and there's a
 reason why we don't have glibc, e2fsprogs, xfsprogs, util-linux-ng,
 etc., all packaged into the kernel sources.

If we need to release a new version, patches would go through the
-stable tree just like with any other subsystem.

On Mon, Nov 7, 2011 at 2:29 PM, Ted Ts'o ty...@mit.edu wrote:
 Because it's a stupid, idiotic thing to do.

The discussion is turning into whether or not linux/tools makes sense
or not. I wish you guys would have had it before perf was merged to
the tree.

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Mon, Nov 7, 2011 at 2:47 PM, Ted Ts'o ty...@mit.edu wrote:
 Perf was IMHO an overreaction caused by the fact that systemtap and
 oprofile people packaged and released the sources in a way that kernel
 developers didn't like.

 I don't think perf should be used as a precendent that now argues that
 any new kernel utility should be moved into the kernel sources.  Does
 it make sense to move all of mount, fsck, login, etc., into the kernel
 sources?  There are far more kernel tools outside of the kernel
 sources than inside the kernel sources.

There's two overlapping questions here:

  (1) Does it make sense to merge the KVM tool to Linux kernel tree?

  (2) Does it make sense to merge userspace tools to the kernel tree?

I'm not trying to use perf to justify merging the KVM tool. However, you
seem to be arguing that it shouldn't be merged because merging
userspace tools in general doesn't make sense. That's why I brought up
the situation with perf.

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Mon, Nov 7, 2011 at 2:47 PM, Ted Ts'o ty...@mit.edu wrote:
 I don't think perf should be used as a precendent that now argues that
 any new kernel utility should be moved into the kernel sources.  Does
 it make sense to move all of mount, fsck, login, etc., into the kernel
 sources?  There are far more kernel tools outside of the kernel
 sources than inside the kernel sources.

You seem to think that the KVM tool was developed in isolation and we
simply copied the code to tools/kvm for the pull request. That's simply
not true. We've done a lot of work to make the code feel like kernel code
from locking primitive APIs to serial console emulation register names.
We really consider KVM tool to be a new Linux subsystem. It's the long
lost cousin or bastard child of KVM, depending on who you ask.

I don't know if it makes sense to merge the tools you've mentioned above.
My gut feeling is that it's probably not reasonable - there's already a
community working on it with their own development process and coding
style. I don't think there's a simple answer to this but I don't agree with
your rather extreme position that all userspace tools should be kept out
of the kernel tree.

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Mon, 7 Nov 2011, Pekka Enberg wrote:
 I've never heard ABI incompatibility used as an argument for perf. Ingo?

On Mon, Nov 7, 2011 at 7:03 PM, Vince Weaver vi...@deater.net wrote:
 Never overtly.  They're too clever for that.

If you want me to take you seriously, spare me from the conspiracy theories, OK?

I'm sure perf developers break the ABI sometimes - that happens
elsewhere in the kernel as well. However, Ted claimed that perf
developers use tools/perf as an excuse to break the ABI _on purpose_
which is something I have hard time believing.

Your snarky remarks doesn't really help this discussion either. It's
apparent from the LKML discussions that you're more interested in
arguing with the perf developers rather than helping them.

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Mon, 7 Nov 2011, Frank Ch. Eigler wrote:

The ABI design allows for that kind of flexible extensibility, and
it's one of its major advantages.

What we *cannot* protect against is you relying on obscure details of
the ABI [...]


Is there some documentation that clearly spells out which parts of the
perf syscall userspace ABI are obscure and thus presumably
changeable?


That's actually something the KVM and virtio folks have done a great job 
with IMHO. Both ABIs are documented pretty extensively and the specs are 
kept up to date.


I guess for perf ABI, perf test is the closest thing to a specification 
so if your application is using something that's not covered by it, you 
might be in trouble.


Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

Hi Ted,

On Mon, Nov 7, 2011 at 10:32 PM, Ted Ts'o ty...@mit.edu wrote:
 Personally, I consider code that runs in userspace as a pretty bright
 line, as being not kernel code, and while perhaps things like
 initramfs and the crazy ideas people have had in the past of moving
 stuff out of kernel/init.c into userspace might have qualified as
 stuff really close to the kernel, something like kvm-tool that runs
 way after boot, doesn't even come close.  Wine is another example of
 another package that has lots of close kernel ties, but was also not
 bundled into the kernel.

It's not as clear line as you make it out to be.

KVM tool also has mini-BIOS code that runs in guest space. It has a
code that runs in userspace but is effectively a simple bootloader. So
it definitely doesn't fit the simple definition of running way after
boot (we're _booting_ the kernel too).

Linsched fits your definition but is clearly worth integrating to the
kernel tree. While you are suggesting that maybe we should move Perf
out of the tree now that it's mature, I'm pretty sure you'd agree that
it probably would not have happened if the userspace parts were
developed out of tree.

There's also spectacular failures in the kernel history where the
userspace split was enforced. For example, userspace suspend didn't
turn out the way people envisioned it at the time. We don't know how
it would have worked out if the userspace components would have been
in the tree but it certainly would have solved many if the early ABI
issues.

I guess I'm trying to argue here that there's a middle ground. I'm
willing to bet projects like klibc and unified initramfs will
eventually make it to the kernel tree because they simply make so much
sense. I'm also willing to be that the costs of moving Perf out of the
tree are simply too high to make it worthwhile.

Does that mean KVM tool should get a free pass in merging? Absolutely
not. But I do think your position is too extreme and ignores the
benefits of developing userspace tools in the kernel ecosystem which
was summed up by Anthony rather well in this thread:

https://lkml.org/lkml/2011/11/7/169

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

Hi Alexander,

On Sun, Nov 6, 2011 at 3:35 AM, Alexander Graf ag...@suse.de wrote:
 On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
 would be doing and what he expects from it. Basically he wants a
 small and simple tool he and other developers can run to try out and
 see if the kernel they just built actually works.

 Fortunately, QEMU can do that today already! The only piece that was
 missing was the simple piece of the equation, so here is a script
 that wraps around QEMU and executes a kernel you just built.

I'm happy to see some real competition for the KVM tool in usability. ;-)

That said, while the script looks really useful for developers,
wouldn't it make more sense to put it in QEMU to make sure it's kept
up-to-date and distributions can pick it up too? (And yes, I realize
the irony here.)

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Sun, Nov 6, 2011 at 12:07 PM, Avi Kivity a...@redhat.com wrote:
 I'm happy to see some real competition for the KVM tool in usability. ;-)

 That said, while the script looks really useful for developers,
 wouldn't it make more sense to put it in QEMU to make sure it's kept
 up-to-date and distributions can pick it up too? (And yes, I realize
 the irony here.)

 Why would distributions want it?  It's only useful for kernel developers.

It's useful for kernel testers too.

If this is a serious attempt in making QEMU command line suck less on
Linux, I think it makes sense to do this properly instead of adding a
niche script to the kernel tree that's simply going to bit rot over
time.

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

Hi Avi,

On Sun, 2011-11-06 at 12:23 +0200, Avi Kivity wrote:
  If this is a serious attempt in making QEMU command line suck less on
  Linux, I think it makes sense to do this properly instead of adding a
  niche script to the kernel tree that's simply going to bit rot over
  time.
 
 You misunderstand.  This is an attempt to address the requirements of a
 niche population, kernel developers and testers, not to improve the qemu
 command line.  For the majority of qemu installations, this script is
 useless.

Right.

On Sun, 2011-11-06 at 12:23 +0200, Avi Kivity wrote:
 In most installations, qemu is driven by other programs, so any changes
 to the command line would be invisible, except insofar as they break things.
 
 For the occasional direct user of qemu, something like 'qemu-kvm -m 1G
 /images/blah.img' is enough to boot an image.  This script doesn't help
 in any way.
 
 This script is for kernel developers who don't want to bother with
 setting up a disk image (which, btw, many are still required to do - I'm
 guessing most kernel developers who use qemu are cross-arch).  It has
 limited scope and works mostly by hiding qemu features.  As such it
 doesn't belong in qemu.

I'm certainly not against merging the script if people are actually
using it and it solves their problem.

I personally find the whole exercise pointless because it's not
attempting to solve any of the fundamental issues QEMU command line
interface has nor does it try to make Linux on Linux virtualization
simpler and more integrated.

People seem to think the KVM tool is only about solving a specific
problem to kernel developers. That's certainly never been my goal as I
do lots of userspace programming as well. The end game for me is to
replace QEMU/VirtualBox for Linux on Linux virtualization for my day to
day purposes.

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Sun, Nov 6, 2011 at 1:50 PM, Avi Kivity a...@redhat.com wrote:
 People seem to think the KVM tool is only about solving a specific
 problem to kernel developers. That's certainly never been my goal as I
 do lots of userspace programming as well. The end game for me is to
 replace QEMU/VirtualBox for Linux on Linux virtualization for my day to
 day purposes.

 Maybe it should be in tools/pekka then.  Usually subsystems that want to
 be merged into Linux have broaded audiences though.

I think you completely missed my point.

I'm simply saying that KVM tool was never about solving a narrow
problem Alexander's script is trying to solve. That's why I feel it's
such a pointless exercise.

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Sun, Nov 6, 2011 at 1:50 PM, Avi Kivity a...@redhat.com wrote:
 So far, kvm-tool capabilities are a subset of qemu's.  Does it add
 anything beyond a different command-line?

I think different command line is a big thing which is why we've
spent so much time on it. But if you mean other end user features, no,
we don't add anything new on the table right now. I think our
userspace networking implementation is better than QEMU's slirp but
that's purely technical thing.

I also don't think we should add new features for their own sake.
Linux virtualization isn't a terribly difficult thing to do thanks to
KVM and virtio drivers. I think most of the big ticket items will be
doing things like improving guest isolation and making guests more
accessible to the host.

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Sun, Nov 6, 2011 at 2:27 PM, Avi Kivity a...@redhat.com wrote:
 But from your description, you're trying to solve just another narrow
 problem:

 The end game for me is to replace QEMU/VirtualBox for Linux on Linux
 virtualization for my day to day purposes. 

 We rarely merge a subsystem to solve one person's problem (esp. when it
 is defined as replace another freely available project, even if you
 dislike its command line syntax).

I really don't understand your point. Other people are using the KVM
tool for other purposes. For example, the (crazy) simulation guys are
using the tool to launch even more guests on a single host and Ingo
seems to be using the tool to test kernels.

I'm not suggesting we should merge the tool because of my particular
use case. I'm simply saying the problem I personally want to solve
with the KVM tool is broader than what Alexander's script is doing.
That's why I feel it's a pointless project.

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity a...@redhat.com wrote:
 You say that kvm-tool's scope is broader than Alex's script, therefore
 the latter is pointless.

I'm saying that Alex's script is pointless because it's not attempting
to fix the real issues. For example, we're trying to make make it as
easy as possible to setup a guest and to be able to access guest data
from the host. Alex's script is essentially just a simplified QEMU
front end for kernel developers.

That's why I feel it's a pointless thing to do.

On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity a...@redhat.com wrote:
 You accept that qemu's scope is broader than kvm-tool (and is a
 superset).  That is why many people think kvm-tool is pointless.

Sure. I think it's mostly people that are interested in non-Linux
virtualization that think the KVM tool is a pointless project.
However, some people (including myself) think the KVM tool is a more
usable and hackable tool than QEMU for Linux virtualization.

The difference here is that although I feel Alex's script is a
pointless project, I'm in no way opposed to merging it in the tree if
people use it and it solves their problem. Some people seem to be
violently opposed to merging the KVM tool and I'm having difficult
time understanding why that is.

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity a...@redhat.com wrote:
 Alex's script, though, is just a few dozen lines.  kvm-tool is a 20K
 patch - in fact 2X as large as kvm when it was first merged.  And it's
 main feature seems to be that it is not qemu.

I think I've mentioned many times that I find the QEMU source terribly
difficult to read and hack on. So if you mean not qemu from that
point of view, sure, I think it's a very important point. The command
line interface is also not qemu for a very good reason too.

As for virtio drivers and such, we're actually following QEMU's
example very closely. I guess we're going to diverge a bit for better
guest isolation but fundamentally I don't see why we'd want to be
totally different from QEMU on that level.

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

Hi Jan,

On Sun, Nov 6, 2011 at 6:19 PM, Jan Kiszka jan.kis...@web.de wrote:
 Usable - I've tried kvm-tool several times and still (today) fail to
 get a standard SUSE image (with a kernel I have to compile and provide
 separately...) up and running *). Likely a user mistake, but none that
 is very obvious. At least to me.

 In contrast, you can throw arbitrary Linux distros in various forms at
 QEMU, and it will catch and run them. For me, already this is more usable.

 *) kvm run -m 1000 -d OpenSuse11-4_64.img arch/x86/boot/bzImage \
        -p root=/dev/vda2
 ...
 [    1.772791] mousedev: PS/2 mouse device common for all mice
 [    1.774603] cpuidle: using governor ladder
 [    1.775490] cpuidle: using governor menu
 [    1.776865] input: AT Raw Set 2 keyboard as
 /devices/platform/i8042/serio0/input/input0
 [    1.778609] TCP cubic registered
 [    1.779456] Installing 9P2000 support
 [    1.782390] Registering the dns_resolver key type
 [    1.794323] registered taskstats version 1

 ...and here the boot just stops, guest apparently waits for something

Can you please share your kernel .config with me and I'll take a look
at it. We now have a make kvmconfig makefile target for enabling all
the necessary config options for guest kernels. I don't think any of
us developers are using SUSE so it can surely be a KVM tool bug as
well.

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

Hi Avi,

On Sun, Nov 6, 2011 at 5:56 PM, Avi Kivity a...@redhat.com wrote:
 On 11/06/2011 03:06 PM, Pekka Enberg wrote:
 On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity a...@redhat.com wrote:
  You say that kvm-tool's scope is broader than Alex's script, therefore
  the latter is pointless.

 I'm saying that Alex's script is pointless because it's not attempting
 to fix the real issues. For example, we're trying to make make it as
 easy as possible to setup a guest and to be able to access guest data
 from the host.

 Have you tried virt-install/virt-manager?

No, I don't use virtio-manager. I know a lot of people do which is why
someone is working on KVM tool libvirt integration.

 On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity a...@redhat.com wrote:
  You accept that qemu's scope is broader than kvm-tool (and is a
  superset).  That is why many people think kvm-tool is pointless.

 Sure. I think it's mostly people that are interested in non-Linux
 virtualization that think the KVM tool is a pointless project.
 However, some people (including myself) think the KVM tool is a more
 usable and hackable tool than QEMU for Linux virtualization.

 More hackable, certainly, as any 20kloc project will be compared to a
 700+kloc project with a long history.  More usable, I really doubt
 this.  You take it for granted that people want to run their /boot
 kernels in a guest, but in fact only kernel developers (and testers)
 want this.  The majority want the real guest kernel.

Our inability to boot ISO images, for example, is a usability
limitation, sure. I'm hoping to fix that at some point.

 The difference here is that although I feel Alex's script is a
 pointless project, I'm in no way opposed to merging it in the tree if
 people use it and it solves their problem. Some people seem to be
 violently opposed to merging the KVM tool and I'm having difficult
 time understanding why that is.

 One of the reasons is that if it is merge, anyone with a #include
 linux/foo.h will line up for the next merge window, wanting in.  The
 other is that anything in the Linux source tree might gain an unfair
 advantage over out-of-tree projects (at least that's how I read Jan's
 comment).

Well, having gone through the process of getting something included so
far, I'm not at all worried that there's going to be a huge queue of
#include linux/foo.h projects if we get in...

What kind of unfair advantage are you referring to? I've specifically
said that the only way for KVM tool to become a reference
implementation would be that the KVM maintainers take the tool through
their tree. As that's not going to happen, I don't see what the
problem would be.

 Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Sun, Nov 6, 2011 at 6:19 PM, Jan Kiszka jan.kis...@web.de wrote:
 In contrast, you can throw arbitrary Linux distros in various forms at
 QEMU, and it will catch and run them. For me, already this is more usable.

Yes, I completely agree that this is an unfortunate limitation in the
KVM tool. We definitely need to support booting to images which have
virtio drivers enabled.

 Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Sun, 6 Nov 2011, Jan Kiszka wrote:

Can you please share your kernel .config with me and I'll take a look
at it. We now have a make kvmconfig makefile target for enabling all
the necessary config options for guest kernels. I don't think any of
us developers are using SUSE so it can surely be a KVM tool bug as
well.


Attached.


It hang here as well. I ran

  make kvmconfig

on your .config and it works. It's basically these two:

@@ -1478,7 +1478,7 @@
 CONFIG_NETPOLL=y
 # CONFIG_NETPOLL_TRAP is not set
 CONFIG_NET_POLL_CONTROLLER=y
-CONFIG_VIRTIO_NET=m
+CONFIG_VIRTIO_NET=y
 # CONFIG_VMXNET3 is not set
 # CONFIG_ISDN is not set
 # CONFIG_PHONE is not set
@@ -1690,7 +1690,7 @@
 # CONFIG_SERIAL_PCH_UART is not set
 # CONFIG_SERIAL_XILINX_PS_UART is not set
 CONFIG_HVC_DRIVER=y
-CONFIG_VIRTIO_CONSOLE=m
+CONFIG_VIRTIO_CONSOLE=y
 CONFIG_IPMI_HANDLER=m
 # CONFIG_IPMI_PANIC_EVENT is not set
 CONFIG_IPMI_DEVICE_INTERFACE=m

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Sun, Nov 6, 2011 at 7:15 PM, Alexander Graf ag...@suse.de wrote:
 The difference here is that although I feel Alex's script is a
 pointless project, I'm in no way opposed to merging it in the tree if
 people use it and it solves their problem. Some people seem to be
 violently opposed to merging the KVM tool and I'm having difficult
 time understanding why that is.

 It's a matter of size and scope. Write a shell script that clones, builds and
 executes KVM Tool and throw it in testing/tools/ and I'll happily ack it!

That's pretty much what git submodule would do, isn't it?

I really don't see the point in doing that. We want to be part of
regular kernel history and release cycle. We want people to be able to
see what's going on in our tree to keep us honest and we want to make
the barrier of entry as low as possible.

It's not just about code, it's as much about culture and development process.

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Sun, 6 Nov 2011, Jan Kiszka wrote:

Doesn't help here (with a disk image).

Also, both dependencies make no sense to me as we boot from disk, not
from net, and the console is on ttyS0.


It's only VIRTIO_NET and the guest is not actually stuck, it just takes a 
while to boot:


[1.866614] Installing 9P2000 support
[1.868991] Registering the dns_resolver key type
[1.878084] registered taskstats version 1
[   13.927367] Root-NFS: no NFS server address
[   13.929500] VFS: Unable to mount root fs via NFS, trying floppy.
[   13.939177] VFS: Mounted root (9p filesystem) on device 0:12.
[   13.941522] devtmpfs: mounted
[   13.943317] Freeing unused kernel memory: 684k freed
Mounting...
Starting '/bin/sh'...
sh-4.2#

I'm CC'ing Sasha and Asias.

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Sun, Nov 6, 2011 at 7:30 PM, Alexander Graf ag...@suse.de wrote:
 That's pretty much what git submodule would do, isn't it?

 I really don't see the point in doing that. We want to be part of
 regular kernel history and release cycle. We want people to be able to
 see what's going on in our tree to keep us honest and we want to make
 the barrier of entry as low as possible.

 It's not just about code, it's as much about culture and development process.

 So you're saying that projects that are not living in the kernel tree aren't 
 worthwhile?

Yeah, that's exactly what I'm saying...

 Or are you only trying to bump your oloh stats?

That too!

On Sun, Nov 6, 2011 at 7:30 PM, Alexander Graf ag...@suse.de wrote:
 I mean, seriously, git makes it so easy to have a separate tree that
 it almost doesn't make sense not to have one. You're constantly
 working in separate trees yourself because every one of your
 branches is separate. Keeping in sync with the kernel release cycles
 (which I don't think makes any sense for you) should be easy enough
 too by merely releasing in sync with the kernel tree...

We'd be the only subsystem doing that! Why on earth do you think we
want to be the first ones to do that? We don't want to be different,
we want to make the barrier of entry low.

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Sun, Nov 6, 2011 at 7:08 PM, Anthony Liguori anth...@codemonkey.ws wrote:
 I'm quite happy with KVM tool and hope they continue working on it.  My only
 real wish is that they wouldn't copy QEMU so much and would try bolder
 things that are fundamentally different from QEMU.

Hey, right now our only source of crazy ideas is Ingo and I think he's
actually a pretty conservative guy when it comes to technology. Avi
has expressed some crazy ideas in the past but they require switching
away from C and that's not something we're interested in doing. ;-)

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Sun, Nov 06, 2011 at 11:08:10AM -0600, Anthony Liguori wrote:
 I'm quite happy with KVM tool and hope they continue working on it.
 My only real wish is that they wouldn't copy QEMU so much and would
 try bolder things that are fundamentally different from QEMU.

On Sun, Nov 6, 2011 at 8:31 PM, Ted Ts'o ty...@mit.edu wrote:
 My big wish is that they don't try to merge the KVM tool into the
 kernel code.  It's a separate userspace project, and there's no reason
 for it to be bundled with kernel code.  It just makes the kernel
 sources larger.  The mere fact that qemu-kvm exists means that the KVM
 interface has to remain backward compatible; it *is* an ABI.

 So integrating kvm-tool into the kernel isn't going to work as a free
 pass to make non-backwards compatible changes to the KVM user/kernel
 interface.  Given that, why bloat the kernel source tree size?

Ted, I'm confused. Making backwards incompatible ABI changes has never
been on the table. Why are you bringing it up?

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Sun, Nov 6, 2011 at 8:54 PM, Pekka Enberg penb...@kernel.org wrote:
 So integrating kvm-tool into the kernel isn't going to work as a free
 pass to make non-backwards compatible changes to the KVM user/kernel
 interface.  Given that, why bloat the kernel source tree size?

 Ted, I'm confused. Making backwards incompatible ABI changes has never
 been on the table. Why are you bringing it up?

And btw, KVM tool is not a random userspace project - it was designed
to live in tools/kvm from the beginning. I've explained the technical
rationale for sharing kernel code here:

https://lkml.org/lkml/2011/11/4/150

Please also see Ingo's original rant that started the project:

http://thread.gmane.org/gmane.linux.kernel/962051/focus=962620

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Sun, Nov 6, 2011 at 9:11 PM, Paolo Bonzini pbonz...@redhat.com wrote:
 I really don't see the point in doing that. We want to be part of
 regular kernel history and release cycle.

 But I'm pretty certain that, when testing 3.2 with KVM tool in a couple of
 years, I want all the shining new features you added in this time; I don't
 want the old end-2011 code.  Same if I'm bisecting kernels, I don't want to
 build KVM tool once per bisection cycle, do I?

If you're bisecting breakage that can be in the guest kernel or the
KVM tool, you'd want to build both.

What would prevent you from using a newer KVM tool with an older kernel?

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Sun, Nov 6, 2011 at 9:14 PM, Paolo Bonzini pbonz...@redhat.com wrote:
 GStreamer (V4L), RTSAdmin (LIO target), sg3_utils, trousers all are out of
 tree, and nobody of their authors is even thinking of doing all this
 brouhaha to get merged into Linus's tree.

We'd be the first subsystem to use the download script thing Alex suggested.

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Sun, Nov 6, 2011 at 10:01 PM, Paolo Bonzini pbonz...@redhat.com wrote:
 If you're bisecting breakage that can be in the guest kernel or the
 KVM tool, you'd want to build both.

 No.  I want to try new tool/old kernel and old tool/new kernel (kernel can
 be either guest or host, depending on the nature of the bug), and then
 bisect just one.  (*) And that's the exceptional case, and only KVM tool
 developers really should have the need to do that.

Exactly - having the source code in Linux kernel tree covers the
exceptional case where we're unsure which part of the equation broke
things (which are btw the nasties issues we've had so far). I have no
idea why you're trying to convince me that it doesn't matter. You can
bisect only one of the components in isolation just fine.

On Sun, Nov 6, 2011 at 10:01 PM, Paolo Bonzini pbonz...@redhat.com wrote:
 What would prevent you from using a newer KVM tool with an older kernel?

 Nothing, but I'm just giving you *strong* hints that a submodule or a merged
 tool is the wrong solution, and the histories of kernel and tool should be
 kept separate.

 More clearly: for its supposedly intended usage, namely testing development
 kernels in a *guest*, KVM tool will generally not run on the exact *host*
 kernel that is in the tree it lives with.  Almost never, in fact.  Unlike
 perf, if you want to test multiple guest kernels you should never need to
 rebuild KVM tool!

 This is the main argument as to whether or not to merge the tool.  Would the
 integration of the *build* make sense or not?  Assume you adapt the ktest
 script to make both the KVM tool and the kernel, and test the latter using
 the former.  Your host kernel never changes, and yet you introduce a new
 variable in your testing.  That complicates things, it doesn't simplify
 them.

I don't understand what trying to say. There's no requirement to build
the KVM tool if you're bisecting a guest kernel.

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Sun, Nov 6, 2011 at 10:01 PM, Paolo Bonzini pbonz...@redhat.com wrote:
 Nothing, but I'm just giving you *strong* hints that a submodule or a merged
 tool is the wrong solution, and the histories of kernel and tool should be
 kept separate.

And btw, I don't really understand what you're trying to accomplish
with this line of reasoning. We've tried both separate and shared
repository and the latter is much better from development point of
view.

This is not some random userspace project that uses the kernel system
calls. It's a hypervisor that implements virtio drivers, serial
emulation, and mini-BIOS. It's very close to the kernel which is why
it's such a good fit with the kernel tree.

I'd actually be willing to argue that from purely technical point of
view, KVM tool makes much more sense to have in the kernel tree than
perf does.

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Sun, 6 Nov 2011, Ted Ts'o wrote:

The only excuse I can see is a hope to make random changes to the
kernel and userspace tools without having to worry about compatibility
problems, which is an argument I've seen with perf (that you have to
use the same version of perf as the kernel version, which to me is bad
software engineering).  And that's why I pointed out that you can't do
that with KVM, since we have out-of-tree userspace users, namely
qemu-kvm.


I've never heard ABI incompatibility used as an argument for perf. Ingo?

As for the KVM tool, merging has never been about being able to do ABI 
incompatible changes and never will be. I'm still surprised you even 
brought this up because I've always been one to _complain_ about people 
breaking the ABI - not actually breaking it (at least on purpose).


Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

Hi Anthony,

On Sun, 6 Nov 2011, Anthony Liguori wrote:
- Drop SDL/VNC.  Make a proper Cairo GUI with a full blown GTK interface. 
Don't rely on virt-manager for this.  Not that I have anything against 
virt-manager but there are many layers between you and the end GUI if you go 
that route.


Funny that you should mention this. It was actually what I started out 
with. I went for SDL because it was a low-hanging fruit after the VNC 
patches which I didn't do myself.


However, it was never figured out if there was going to be a virtio 
transport for GPU commands:


http://lwn.net/Articles/408831/

On Sun, 6 Nov 2011, Anthony Liguori wrote:
- Sandbox the device model from day #1.  The size of the Linux kernel 
interface is pretty huge and as a hypervisor, it's the biggest place for 
improvement from a security perspective.  We're going to do sandboxing in 
QEMU, but it's going to be difficult.  It would be much easier for you given 
where you're at.


Completely agreed. I think Sasha is actually starting to work on this. See 
the Secure KVM thread on kvm@.


Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Pekka Enberg]

On Mon, Nov 7, 2011 at 12:08 AM, Frank Ch. Eigler f...@redhat.com wrote:
 [...]  We don't want to be different, we want to make the barrier of
 entry low.

 When has the barrier of entry into the kernel ever been low
 for anyone not already working in the kernel?

What's your point? Working on the KVM tool requires knowledge of the
Linux kernel.

Pekka

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around Qemu to test kernels

[Pekka Enberg]

On Wed, Aug 24, 2011 at 1:16 AM, Alexander Graf ag...@suse.de wrote:
 On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
 would be doing and what he expects from it. Basically he wants a
 small and simple tool he and other developers can run to try out and
 see if the kernel they just built actually works.

 Fortunately, Qemu can do that today already! The only piece that was
 missing was the simple piece of the equation, so here is a script
 that wraps around Qemu and executes a kernel you just built.

 If you do have KVM around and are not cross-compiling, it will use
 KVM. But if you don't, you can still fall back to emulation mode and
 at least check if your kernel still does what you expect. I only
 implemented support for s390x and ppc there, but it's easily extensible
 to more platforms, as Qemu can emulate (and virtualize) pretty much
 any platform out there.

 If you don't have qemu installed, please do so before using this script. Your
 distro should provide a package for it (might even call it kvm). If not,
 just compile it from source - it's not hard!

 To quickly get going, just execute the following as user:

    $ ./Documentation/run-qemu.sh -r / -a init=/bin/bash

 This will drop you into a shell on your rootfs.

 Happy hacking!

It's nice to see such an honest attempt at improving QEMU usability, Alexander!

One comment: in my experience, having shell scripts under
Documentation reduces the likelihood that people actually discover
them so you might want to consider putting it under scripts or tools.

Pekka