include/hw/i386/microvm.h | 8 +- hw/acpi/isa-acpi.c | 114 +++++++++++++++ hw/i386/acpi-build.c | 278 +++++++++++++++++++++++++++++------- hw/i386/microvm.c | 32 +++-- hw/acpi/Makefile.objs | 1 + pc-bios/bios-256k.bin | Bin 262144 -> 262144 bytes pc-bios/bios-microvm.bin | Bin 65536 -> 131072 bytes pc-bios/bios.bin | Bin 131072 -> 131072 bytes roms/Makefile | 5 +- roms/config.seabios-128k | 2 + roms/config.seabios-microvm | 25 ++++ roms/seabios | 2 +- 12 files changed, 403 insertions(+), 64 deletions(-) create mode 100644 hw/acpi/isa-acpi.c create mode 100644 roms/config.seabios-microvm
I know that not supporting ACPI in microvm is intentional. If you still
don't want ACPI this is perfectly fine, you can use the usual -no-acpi
switch to toggle ACPI support.
These are the advantages you are going to loose then:
(1) virtio-mmio device discovery without command line hacks (tweaking
the command line is a problem when not using direct kernel boot).
(2) Better IO-APIC support, we can use IRQ lines 16-23.
(3) ACPI power button (aka powerdown request) works.
(4) machine poweroff (aka S5 state) works.
Together with seabios patches for virtio-mmio support this allows to
boot standard fedora images (cloud, coreos, workstation live) with the
microvm machine type.
cheers,
Gerd
Gerd Hoffmann (13):
acpi: make build_madt() more generic.
acpi: factor out acpi_dsdt_add_fw_cfg()
microvm: add isa-acpi device
microvm: add minimal acpi support.
microvm: add acpi_dsdt_add_virtio() for x86
microvm: disable virtio-mmio cmdline hack
[testing] seabios: update submodule to experimental microvm branch
[testing] seabios: update config & build rules
[testing] seabios: update binaries to experimental microvm branch
microvm/acpi: add rtc
microvm/acpi: add serial
microvm: make virtio irq base runtime configurable
microvm/acpi: use GSI 16-23 for virtio
include/hw/i386/microvm.h | 8 +-
hw/acpi/isa-acpi.c | 114 +++++++++++++++
hw/i386/acpi-build.c | 278 +++++++++++++++++++++++++++++-------
hw/i386/microvm.c | 32 +++--
hw/acpi/Makefile.objs | 1 +
pc-bios/bios-256k.bin | Bin 262144 -> 262144 bytes
pc-bios/bios-microvm.bin | Bin 65536 -> 131072 bytes
pc-bios/bios.bin | Bin 131072 -> 131072 bytes
roms/Makefile | 5 +-
roms/config.seabios-128k | 2 +
roms/config.seabios-microvm | 25 ++++
roms/seabios | 2 +-
12 files changed, 403 insertions(+), 64 deletions(-)
create mode 100644 hw/acpi/isa-acpi.c
create mode 100644 roms/config.seabios-microvm
--
2.18.2
Patchew URL: https://patchew.org/QEMU/20200319080117.7725-1-kraxel@redhat.com/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
export ARCH=x86_64
make docker-image-fedora V=1 NETWORK=1
time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1
=== TEST SCRIPT END ===
CC hw/net/vhost_net.o
CC hw/net/vhost_net-stub.o
CC hw/net/rocker/rocker.o
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:52:46: error: too few arguments to function call, expected 5, have 4
&zero, NULL);
^
/tmp/qemu-test/src/include/qom/object.h:1687:1: note: 'object_property_add_uint8_ptr' declared here
void object_property_add_uint8_ptr(Object *obj, const char *name,
^
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:54:46: error: too few arguments to function call, expected 5, have 4
&zero, NULL);
^
/tmp/qemu-test/src/include/qom/object.h:1687:1: note: 'object_property_add_uint8_ptr' declared here
void object_property_add_uint8_ptr(Object *obj, const char *name,
^
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:56:54: error: too few arguments to function call, expected 5, have 4
&s->gpe_base, NULL);
^
/tmp/qemu-test/src/include/qom/object.h:1730:1: note: 'object_property_add_uint32_ptr' declared here
void object_property_add_uint32_ptr(Object *obj, const char *name,
^
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:58:53: error: too few arguments to function call, expected 5, have 4
&s->gpe_len, NULL);
^
/tmp/qemu-test/src/include/qom/object.h:1730:1: note: 'object_property_add_uint32_ptr' declared here
void object_property_add_uint32_ptr(Object *obj, const char *name,
^
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:60:53: error: too few arguments to function call, expected 5, have 4
&s->sci_irq, NULL);
^
/tmp/qemu-test/src/include/qom/object.h:1708:1: note: 'object_property_add_uint16_ptr' declared here
void object_property_add_uint16_ptr(Object *obj, const char *name,
^
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:62:53: error: too few arguments to function call, expected 5, have 4
&s->io_base, NULL);
^
/tmp/qemu-test/src/include/qom/object.h:1730:1: note: 'object_property_add_uint32_ptr' declared here
void object_property_add_uint32_ptr(Object *obj, const char *name,
^
6 errors generated.
make: *** [/tmp/qemu-test/src/rules.mak:69: hw/acpi/isa-acpi.o] Error 1
make: *** Waiting for unfinished jobs....
Traceback (most recent call last):
File "./tests/docker/docker.py", line 664, in <module>
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--label', 'com.qemu.instance.uuid=aff630669cd9451e8fc110b2fe62edd1', '-u', '1003', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=x86_64-softmmu', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 'SHOW_ENV=', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', '/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', '/var/tmp/patchew-tester-tmp-tzpaxn62/src/docker-src.2020-03-19-04.15.28.16361:/var/tmp/qemu:z,ro', 'qemu:fedora', '/var/tmp/qemu/run', 'test-debug']' returned non-zero exit status 2.
filter=--filter=label=com.qemu.instance.uuid=aff630669cd9451e8fc110b2fe62edd1
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-tzpaxn62/src'
make: *** [docker-run-test-debug@fedora] Error 2
real 4m0.766s
user 0m8.155s
The full log is available at
http://patchew.org/logs/20200319080117.7725-1-kraxel@redhat.com/testing.asan/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com
Patchew URL: https://patchew.org/QEMU/20200319080117.7725-1-kraxel@redhat.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===
CC hw/char/pl011.o
CC hw/char/serial.o
/tmp/qemu-test/src/hw/acpi/isa-acpi.c: In function 'isa_acpi_add_propeties':
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:52:35: error: incompatible type for argument 4 of 'object_property_add_uint8_ptr'
&zero, NULL);
^
In file included from /tmp/qemu-test/src/include/exec/memory.h:28:0,
---
/tmp/qemu-test/src/include/qom/object.h:1687:6: note: expected 'ObjectPropertyFlags' but argument is of type 'void *'
void object_property_add_uint8_ptr(Object *obj, const char *name,
^
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:52:35: error: too few arguments to function 'object_property_add_uint8_ptr'
&zero, NULL);
^
In file included from /tmp/qemu-test/src/include/exec/memory.h:28:0,
---
/tmp/qemu-test/src/include/qom/object.h:1687:6: note: declared here
void object_property_add_uint8_ptr(Object *obj, const char *name,
^
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:54:35: error: incompatible type for argument 4 of 'object_property_add_uint8_ptr'
&zero, NULL);
^
In file included from /tmp/qemu-test/src/include/exec/memory.h:28:0,
---
/tmp/qemu-test/src/include/qom/object.h:1687:6: note: expected 'ObjectPropertyFlags' but argument is of type 'void *'
void object_property_add_uint8_ptr(Object *obj, const char *name,
^
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:54:35: error: too few arguments to function 'object_property_add_uint8_ptr'
&zero, NULL);
^
In file included from /tmp/qemu-test/src/include/exec/memory.h:28:0,
---
/tmp/qemu-test/src/include/qom/object.h:1687:6: note: declared here
void object_property_add_uint8_ptr(Object *obj, const char *name,
^
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:56:36: error: incompatible type for argument 4 of 'object_property_add_uint32_ptr'
&s->gpe_base, NULL);
^
In file included from /tmp/qemu-test/src/include/exec/memory.h:28:0,
---
/tmp/qemu-test/src/include/qom/object.h:1730:6: note: expected 'ObjectPropertyFlags' but argument is of type 'void *'
void object_property_add_uint32_ptr(Object *obj, const char *name,
^
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:56:36: error: too few arguments to function 'object_property_add_uint32_ptr'
&s->gpe_base, NULL);
^
In file included from /tmp/qemu-test/src/include/exec/memory.h:28:0,
---
/tmp/qemu-test/src/include/qom/object.h:1730:6: note: declared here
void object_property_add_uint32_ptr(Object *obj, const char *name,
^
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:58:36: error: incompatible type for argument 4 of 'object_property_add_uint32_ptr'
&s->gpe_len, NULL);
^
In file included from /tmp/qemu-test/src/include/exec/memory.h:28:0,
---
/tmp/qemu-test/src/include/qom/object.h:1730:6: note: expected 'ObjectPropertyFlags' but argument is of type 'void *'
void object_property_add_uint32_ptr(Object *obj, const char *name,
^
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:58:36: error: too few arguments to function 'object_property_add_uint32_ptr'
&s->gpe_len, NULL);
^
In file included from /tmp/qemu-test/src/include/exec/memory.h:28:0,
---
/tmp/qemu-test/src/include/qom/object.h:1730:6: note: declared here
void object_property_add_uint32_ptr(Object *obj, const char *name,
^
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:60:36: error: incompatible type for argument 4 of 'object_property_add_uint16_ptr'
&s->sci_irq, NULL);
^
In file included from /tmp/qemu-test/src/include/exec/memory.h:28:0,
---
/tmp/qemu-test/src/include/qom/object.h:1708:6: note: expected 'ObjectPropertyFlags' but argument is of type 'void *'
void object_property_add_uint16_ptr(Object *obj, const char *name,
^
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:60:36: error: too few arguments to function 'object_property_add_uint16_ptr'
&s->sci_irq, NULL);
^
In file included from /tmp/qemu-test/src/include/exec/memory.h:28:0,
---
/tmp/qemu-test/src/include/qom/object.h:1708:6: note: declared here
void object_property_add_uint16_ptr(Object *obj, const char *name,
^
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:62:36: error: incompatible type for argument 4 of 'object_property_add_uint32_ptr'
&s->io_base, NULL);
^
In file included from /tmp/qemu-test/src/include/exec/memory.h:28:0,
---
/tmp/qemu-test/src/include/qom/object.h:1730:6: note: expected 'ObjectPropertyFlags' but argument is of type 'void *'
void object_property_add_uint32_ptr(Object *obj, const char *name,
^
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:62:36: error: too few arguments to function 'object_property_add_uint32_ptr'
&s->io_base, NULL);
^
In file included from /tmp/qemu-test/src/include/exec/memory.h:28:0,
---
/tmp/qemu-test/src/include/qom/object.h:1730:6: note: declared here
void object_property_add_uint32_ptr(Object *obj, const char *name,
^
make: *** [hw/acpi/isa-acpi.o] Error 1
make: *** Waiting for unfinished jobs....
Traceback (most recent call last):
File "./tests/docker/docker.py", line 664, in <module>
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--label', 'com.qemu.instance.uuid=f0129bb7ffba4103a5a73a523913e86e', '-u', '1003', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', '/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', '/var/tmp/patchew-tester-tmp-8zpl86hn/src/docker-src.2020-03-19-04.20.57.22139:/var/tmp/qemu:z,ro', 'qemu:centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit status 2.
filter=--filter=label=com.qemu.instance.uuid=f0129bb7ffba4103a5a73a523913e86e
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-8zpl86hn/src'
make: *** [docker-run-test-quick@centos7] Error 2
real 2m8.675s
user 0m7.952s
The full log is available at
http://patchew.org/logs/20200319080117.7725-1-kraxel@redhat.com/testing.docker-quick@centos7/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com
Patchew URL: https://patchew.org/QEMU/20200319080117.7725-1-kraxel@redhat.com/
Hi,
This series failed the docker-mingw@fedora build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#! /bin/bash
export ARCH=x86_64
make docker-image-fedora V=1 NETWORK=1
time make docker-test-mingw@fedora J=14 NETWORK=1
=== TEST SCRIPT END ===
CC hw/display/blizzard.o
CC hw/display/exynos4210_fimd.o
/tmp/qemu-test/src/hw/acpi/isa-acpi.c: In function 'isa_acpi_add_propeties':
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:52:42: error: incompatible type for argument 4 of 'object_property_add_uint8_ptr'
&zero, NULL);
^~~~
In file included from /tmp/qemu-test/src/include/exec/memory.h:28,
---
/tmp/qemu-test/src/include/qom/object.h:1688:74: note: expected 'ObjectPropertyFlags' {aka 'enum <anonymous>'} but argument is of type 'void *'
const uint8_t *v, ObjectPropertyFlags flags,
~~~~~~~~~~~~~~~~~~~~^~~~~
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:51:5: error: too few arguments to function 'object_property_add_uint8_ptr'
object_property_add_uint8_ptr(OBJECT(s), ACPI_PM_PROP_ACPI_ENABLE_CMD,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /tmp/qemu-test/src/include/exec/memory.h:28,
---
/tmp/qemu-test/src/include/qom/object.h:1687:6: note: declared here
void object_property_add_uint8_ptr(Object *obj, const char *name,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:54:42: error: incompatible type for argument 4 of 'object_property_add_uint8_ptr'
&zero, NULL);
^~~~
In file included from /tmp/qemu-test/src/include/exec/memory.h:28,
---
/tmp/qemu-test/src/include/qom/object.h:1688:74: note: expected 'ObjectPropertyFlags' {aka 'enum <anonymous>'} but argument is of type 'void *'
const uint8_t *v, ObjectPropertyFlags flags,
~~~~~~~~~~~~~~~~~~~~^~~~~
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:53:5: error: too few arguments to function 'object_property_add_uint8_ptr'
object_property_add_uint8_ptr(OBJECT(s), ACPI_PM_PROP_ACPI_DISABLE_CMD,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /tmp/qemu-test/src/include/exec/memory.h:28,
---
/tmp/qemu-test/src/include/qom/object.h:1687:6: note: declared here
void object_property_add_uint8_ptr(Object *obj, const char *name,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:56:50: error: incompatible type for argument 4 of 'object_property_add_uint32_ptr'
&s->gpe_base, NULL);
^~~~
In file included from /tmp/qemu-test/src/include/exec/memory.h:28,
---
/tmp/qemu-test/src/include/qom/object.h:1732:57: note: expected 'ObjectPropertyFlags' {aka 'enum <anonymous>'} but argument is of type 'void *'
ObjectPropertyFlags flags,
~~~~~~~~~~~~~~~~~~~~^~~~~
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:55:5: error: too few arguments to function 'object_property_add_uint32_ptr'
object_property_add_uint32_ptr(OBJECT(s), ACPI_PM_PROP_GPE0_BLK,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /tmp/qemu-test/src/include/exec/memory.h:28,
---
/tmp/qemu-test/src/include/qom/object.h:1730:6: note: declared here
void object_property_add_uint32_ptr(Object *obj, const char *name,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:58:49: error: incompatible type for argument 4 of 'object_property_add_uint32_ptr'
&s->gpe_len, NULL);
^~~~
In file included from /tmp/qemu-test/src/include/exec/memory.h:28,
---
/tmp/qemu-test/src/include/qom/object.h:1732:57: note: expected 'ObjectPropertyFlags' {aka 'enum <anonymous>'} but argument is of type 'void *'
ObjectPropertyFlags flags,
~~~~~~~~~~~~~~~~~~~~^~~~~
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:57:5: error: too few arguments to function 'object_property_add_uint32_ptr'
object_property_add_uint32_ptr(OBJECT(s), ACPI_PM_PROP_GPE0_BLK_LEN,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /tmp/qemu-test/src/include/exec/memory.h:28,
---
/tmp/qemu-test/src/include/qom/object.h:1730:6: note: declared here
void object_property_add_uint32_ptr(Object *obj, const char *name,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:60:49: error: incompatible type for argument 4 of 'object_property_add_uint16_ptr'
&s->sci_irq, NULL);
^~~~
In file included from /tmp/qemu-test/src/include/exec/memory.h:28,
---
/tmp/qemu-test/src/include/qom/object.h:1710:57: note: expected 'ObjectPropertyFlags' {aka 'enum <anonymous>'} but argument is of type 'void *'
ObjectPropertyFlags flags,
~~~~~~~~~~~~~~~~~~~~^~~~~
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:59:5: error: too few arguments to function 'object_property_add_uint16_ptr'
object_property_add_uint16_ptr(OBJECT(s), ACPI_PM_PROP_SCI_INT,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /tmp/qemu-test/src/include/exec/memory.h:28,
---
/tmp/qemu-test/src/include/qom/object.h:1708:6: note: declared here
void object_property_add_uint16_ptr(Object *obj, const char *name,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:62:49: error: incompatible type for argument 4 of 'object_property_add_uint32_ptr'
&s->io_base, NULL);
^~~~
In file included from /tmp/qemu-test/src/include/exec/memory.h:28,
---
/tmp/qemu-test/src/include/qom/object.h:1732:57: note: expected 'ObjectPropertyFlags' {aka 'enum <anonymous>'} but argument is of type 'void *'
ObjectPropertyFlags flags,
~~~~~~~~~~~~~~~~~~~~^~~~~
/tmp/qemu-test/src/hw/acpi/isa-acpi.c:61:5: error: too few arguments to function 'object_property_add_uint32_ptr'
object_property_add_uint32_ptr(OBJECT(s), ACPI_PM_PROP_PM_IO_BASE,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /tmp/qemu-test/src/include/exec/memory.h:28,
---
/tmp/qemu-test/src/include/qom/object.h:1730:6: note: declared here
void object_property_add_uint32_ptr(Object *obj, const char *name,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make: *** [/tmp/qemu-test/src/rules.mak:69: hw/acpi/isa-acpi.o] Error 1
make: *** Waiting for unfinished jobs....
Traceback (most recent call last):
File "./tests/docker/docker.py", line 664, in <module>
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--label', 'com.qemu.instance.uuid=aa63d72af4444bddaa87f3cc7ee3d260', '-u', '1001', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 'SHOW_ENV=', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', '/home/patchew/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', '/var/tmp/patchew-tester-tmp-jb7l4rgr/src/docker-src.2020-03-19-04.22.07.24398:/var/tmp/qemu:z,ro', 'qemu:fedora', '/var/tmp/qemu/run', 'test-mingw']' returned non-zero exit status 2.
filter=--filter=label=com.qemu.instance.uuid=aa63d72af4444bddaa87f3cc7ee3d260
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-jb7l4rgr/src'
make: *** [docker-run-test-mingw@fedora] Error 2
real 2m2.507s
user 0m8.570s
The full log is available at
http://patchew.org/logs/20200319080117.7725-1-kraxel@redhat.com/testing.docker-mingw@fedora/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com
On 19/03/20 09:01, Gerd Hoffmann wrote: > I know that not supporting ACPI in microvm is intentional. If you still > don't want ACPI this is perfectly fine, you can use the usual -no-acpi > switch to toggle ACPI support. Could we change -no-acpi into a "-machine acpi=..." property? Then it can have type OnOffAuto and we can decide whether to enable it by default or not for microvm. Also, can you confirm that it builds without CONFIG_I440FX and CONFIG_Q35? You probably need to add "imply ACPI" and possibly some '#include "config-devices.h"' and '#ifdef CONFIG_ACPI' here and there. Paolo > These are the advantages you are going to loose then: > > (1) virtio-mmio device discovery without command line hacks (tweaking > the command line is a problem when not using direct kernel boot). > (2) Better IO-APIC support, we can use IRQ lines 16-23. > (3) ACPI power button (aka powerdown request) works. > (4) machine poweroff (aka S5 state) works. > > Together with seabios patches for virtio-mmio support this allows to > boot standard fedora images (cloud, coreos, workstation live) with the > microvm machine type.
On Thu, Mar 19, 2020 at 09:49:55AM +0100, Paolo Bonzini wrote: > On 19/03/20 09:01, Gerd Hoffmann wrote: > > I know that not supporting ACPI in microvm is intentional. If you still > > don't want ACPI this is perfectly fine, you can use the usual -no-acpi > > switch to toggle ACPI support. > > Could we change -no-acpi into a "-machine acpi=..." property? Then it > can have type OnOffAuto and we can decide whether to enable it by > default or not for microvm. For all machine types not just microvm I guess? > Also, can you confirm that it builds without CONFIG_I440FX and > CONFIG_Q35? You probably need to add "imply ACPI" and possibly some > '#include "config-devices.h"' and '#ifdef CONFIG_ACPI' here and there. Didn't try that yet, will do. cheers, Gerd
On 19/03/20 10:33, Gerd Hoffmann wrote: > On Thu, Mar 19, 2020 at 09:49:55AM +0100, Paolo Bonzini wrote: >> On 19/03/20 09:01, Gerd Hoffmann wrote: >>> I know that not supporting ACPI in microvm is intentional. If you still >>> don't want ACPI this is perfectly fine, you can use the usual -no-acpi >>> switch to toggle ACPI support. >> >> Could we change -no-acpi into a "-machine acpi=..." property? Then it >> can have type OnOffAuto and we can decide whether to enable it by >> default or not for microvm. > > For all machine types not just microvm I guess? Yes, please. Strange that no one has noticed it for all this time! The main reason for not having ACPI was the time that it took to start; this is also why I preferred having device tree, but indeed that would mean no distro kernels (we could probably use U-Boot as the firmware, but still with a custom kernel). Paolo >> Also, can you confirm that it builds without CONFIG_I440FX and >> CONFIG_Q35? You probably need to add "imply ACPI" and possibly some >> '#include "config-devices.h"' and '#ifdef CONFIG_ACPI' here and there. > > Didn't try that yet, will do. > > cheers, > Gerd >
Hi,
> The main reason for not having ACPI was the time that it took to start;
Yep, ACPI needs additional boot time. Shouldn't be a big difference
though, microvm acpi only declares some devices and has small tables.
Also no acpi methods, so no interpreter work. Maybe it is mostly the
additional time needed to log the ACPI stuff to the serial console
(didn't try yet to time boots with "quiet").
On the other hand you have effects like this:
Without acpi the kernel checks whenever hardware is present:
# dmesg | grep i8042
[ 0.334403] i8042: PNP: No PS/2 controller found.
[ 0.334619] i8042: Probing ports directly.
[ 1.370573] i8042: No controller found
With acpi the kernel trusts the firmware and doesn't bother
probing directly:
# dmesg | grep i8042
[ 0.345500] i8042: PNP: No PS/2 controller found.
cheers,
Gerd
Hi, > Also, can you confirm that it builds without CONFIG_I440FX and > CONFIG_Q35? You probably need to add "imply ACPI" and possibly some > '#include "config-devices.h"' and '#ifdef CONFIG_ACPI' here and there. Hmm, is there some way to do this without modifying default-configs/i386-softmmu.mak in the source tree? So I can have two build trees with different confugurations? Also to reduce the risk that I commit default-config changes by mistake? thanks, Gerd
On 19/03/20 14:40, Gerd Hoffmann wrote: >> Also, can you confirm that it builds without CONFIG_I440FX and >> CONFIG_Q35? You probably need to add "imply ACPI" and possibly some >> '#include "config-devices.h"' and '#ifdef CONFIG_ACPI' here and there. > Hmm, is there some way to do this without modifying > default-configs/i386-softmmu.mak in the source tree? So I can have two > build trees with different confugurations? Also to reduce the risk that > I commit default-config changes by mistake? No, there is no way yet. Paolo
On Thu, Mar 19, 2020 at 06:34:40PM +0100, Paolo Bonzini wrote: > On 19/03/20 14:40, Gerd Hoffmann wrote: > >> Also, can you confirm that it builds without CONFIG_I440FX and > >> CONFIG_Q35? You probably need to add "imply ACPI" and possibly some > >> '#include "config-devices.h"' and '#ifdef CONFIG_ACPI' here and there. > > Hmm, is there some way to do this without modifying > > default-configs/i386-softmmu.mak in the source tree? So I can have two > > build trees with different confugurations? Also to reduce the risk that > > I commit default-config changes by mistake? > > No, there is no way yet. Hmm, seems we should have that for better regression testing. master branch doesn't build with pc+q35+isapc turned off: LINK x86_64-softmmu/qemu-system-x86_64 hw/virtio/virtio-iommu.o: In function `virtio_iommu_get_bdf': /home/kraxel/projects/qemu/hw/virtio/virtio-iommu.c:66: undefined reference to `pci_bus_num' hw/virtio/virtio-iommu.o: In function `iommu_find_iommu_pcibus': /home/kraxel/projects/qemu/hw/virtio/virtio-iommu.c:84: undefined reference to `pci_bus_num' hw/virtio/virtio-iommu.o: In function `virtio_iommu_device_realize': /home/kraxel/projects/qemu/hw/virtio/virtio-iommu.c:685: undefined reference to `pci_setup_iommu' collect2: error: ld returned 1 exit status [ adding Eric Auger to Cc: ] cheers, Gerd
On 20/03/20 09:32, Gerd Hoffmann wrote: > Hmm, seems we should have that for better regression testing. > master branch doesn't build with pc+q35+isapc turned off: > > LINK x86_64-softmmu/qemu-system-x86_64 > hw/virtio/virtio-iommu.o: In function `virtio_iommu_get_bdf': > /home/kraxel/projects/qemu/hw/virtio/virtio-iommu.c:66: undefined reference to `pci_bus_num' > hw/virtio/virtio-iommu.o: In function `iommu_find_iommu_pcibus': > /home/kraxel/projects/qemu/hw/virtio/virtio-iommu.c:84: undefined reference to `pci_bus_num' > hw/virtio/virtio-iommu.o: In function `virtio_iommu_device_realize': > /home/kraxel/projects/qemu/hw/virtio/virtio-iommu.c:685: undefined reference to `pci_setup_iommu' > collect2: error: ld returned 1 exit status You need to disable virtio-iommu for now, or apply the patch I've just sent and CC you on. Paolo
On Thu, 19 Mar 2020 09:01:04 +0100 Gerd Hoffmann <kraxel@redhat.com> wrote: > I know that not supporting ACPI in microvm is intentional. If you still > don't want ACPI this is perfectly fine, you can use the usual -no-acpi > switch to toggle ACPI support. > > These are the advantages you are going to loose then: > > (1) virtio-mmio device discovery without command line hacks (tweaking > the command line is a problem when not using direct kernel boot). > (2) Better IO-APIC support, we can use IRQ lines 16-23. > (3) ACPI power button (aka powerdown request) works. > (4) machine poweroff (aka S5 state) works. > > Together with seabios patches for virtio-mmio support this allows to > boot standard fedora images (cloud, coreos, workstation live) with the > microvm machine type. what CLI do you use to test it? > > cheers, > Gerd > > Gerd Hoffmann (13): > acpi: make build_madt() more generic. > acpi: factor out acpi_dsdt_add_fw_cfg() > microvm: add isa-acpi device > microvm: add minimal acpi support. > microvm: add acpi_dsdt_add_virtio() for x86 > microvm: disable virtio-mmio cmdline hack > [testing] seabios: update submodule to experimental microvm branch > [testing] seabios: update config & build rules > [testing] seabios: update binaries to experimental microvm branch > microvm/acpi: add rtc > microvm/acpi: add serial > microvm: make virtio irq base runtime configurable > microvm/acpi: use GSI 16-23 for virtio > > include/hw/i386/microvm.h | 8 +- > hw/acpi/isa-acpi.c | 114 +++++++++++++++ > hw/i386/acpi-build.c | 278 +++++++++++++++++++++++++++++------- > hw/i386/microvm.c | 32 +++-- > hw/acpi/Makefile.objs | 1 + > pc-bios/bios-256k.bin | Bin 262144 -> 262144 bytes > pc-bios/bios-microvm.bin | Bin 65536 -> 131072 bytes > pc-bios/bios.bin | Bin 131072 -> 131072 bytes > roms/Makefile | 5 +- > roms/config.seabios-128k | 2 + > roms/config.seabios-microvm | 25 ++++ > roms/seabios | 2 +- > 12 files changed, 403 insertions(+), 64 deletions(-) > create mode 100644 hw/acpi/isa-acpi.c > create mode 100644 roms/config.seabios-microvm >
On Wed, Mar 25, 2020 at 01:32:12PM +0100, Igor Mammedov wrote:
> On Thu, 19 Mar 2020 09:01:04 +0100
> Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> > I know that not supporting ACPI in microvm is intentional. If you still
> > don't want ACPI this is perfectly fine, you can use the usual -no-acpi
> > switch to toggle ACPI support.
> >
> > These are the advantages you are going to loose then:
> >
> > (1) virtio-mmio device discovery without command line hacks (tweaking
> > the command line is a problem when not using direct kernel boot).
> > (2) Better IO-APIC support, we can use IRQ lines 16-23.
> > (3) ACPI power button (aka powerdown request) works.
> > (4) machine poweroff (aka S5 state) works.
> >
> > Together with seabios patches for virtio-mmio support this allows to
> > boot standard fedora images (cloud, coreos, workstation live) with the
> > microvm machine type.
>
> what CLI do you use to test it?
Test script below. "qemu-default" is a wrapper script which starts
qemu-system-x86_64 from my build directory. "qemu-firmware" is the
same plus isa-debugcon configured for a firmware log on stdout.
Latest bits (with some of the review comments addressed) just pushed
to git://git,kraxel.org/qemu sirius/microvm
HTH,
Gerd
============================ cut here ============================
#!/bin/sh
mode="${1}"
shift
back=()
devs=()
args=()
qemu="qemu-firmware -monitor none -boot menu=on"
disk=""
liso=""
krnl=""
karg="console=ttyS0,115200"
case "$mode" in
kernel)
qemu="qemu-default -nographic"
disk="/vmdisk/imagefish/rhel-8.1.0-ks-x86_64-testboot-sys-disk.qcow2"
krnl="$HOME/build/linux-sirius-x86_64-qemu/arch/x86/boot/bzImage"
karg="$karg root=/dev/sda4"
karg="$karg quiet"
;;
seabios)
disk="/vmdisk/imagefish/rhel-8.1.0-ks-x86_64-testboot-sys-disk.qcow2"
krnl="$HOME/build/linux-sirius-x86_64-qemu/arch/x86/boot/bzImage"
karg="$karg root=/dev/sda4"
args+=("-bios" "/home/kraxel/projects/seabios/out-bios-microvm/bios.bin")
;;
cloud)
disk="/vmdisk/iso/Fedora-Cloud-Base-31-1.9.x86_64.raw"
;;
coreos)
disk="/vmdisk/iso/fedora-coreos-31.20200210.3.0-metal.x86_64.raw"
;;
live)
liso="/vmdisk/iso/Fedora-Workstation-Live-x86_64-30-1.2.iso"
devs+=("-device" "virtio-gpu-device")
devs+=("-device" "virtio-keyboard-device")
devs+=("-device" "virtio-tablet-device")
;;
*)
echo "unknown mode: $mode"
echo "known modes: kernel seabios cloud coreos live"
exit 1
;;
esac
if test "$disk" != ""; then
format="${disk##*.}"
back+=("-drive" "if=none,id=disk,format=${format},file=${disk}")
devs+=("-device" "scsi-hd,drive=disk,bootindex=1")
fi
if test "$liso" != ""; then
back+=("-drive" "if=none,id=cdrom,media=cdrom,readonly,format=raw,file=${liso}")
devs+=("-device" "scsi-cd,drive=cdrom,bootindex=2")
fi
if test "$krnl" != ""; then
args+=("-kernel" "$krnl")
args+=("-append" "$karg")
fi
set -ex
$qemu \
-enable-kvm \
-cpu host \
-M microvm,graphics=off,pit=off,pic=on,rtc=on \
\
-m 4G \
\
-netdev user,id=net \
"${back[@]}" \
\
-global virtio-mmio.force-legacy=false \
-device virtio-net-device,netdev=net \
-device virtio-scsi-device \
"${devs[@]}" \
\
"${args[@]}" \
"$@"
On Wed, 25 Mar 2020 16:03:39 +0100
Gerd Hoffmann <kraxel@redhat.com> wrote:
> On Wed, Mar 25, 2020 at 01:32:12PM +0100, Igor Mammedov wrote:
> > On Thu, 19 Mar 2020 09:01:04 +0100
> > Gerd Hoffmann <kraxel@redhat.com> wrote:
> >
> > > I know that not supporting ACPI in microvm is intentional. If you still
> > > don't want ACPI this is perfectly fine, you can use the usual -no-acpi
> > > switch to toggle ACPI support.
> > >
> > > These are the advantages you are going to loose then:
> > >
> > > (1) virtio-mmio device discovery without command line hacks (tweaking
> > > the command line is a problem when not using direct kernel boot).
> > > (2) Better IO-APIC support, we can use IRQ lines 16-23.
> > > (3) ACPI power button (aka powerdown request) works.
> > > (4) machine poweroff (aka S5 state) works.
> > >
> > > Together with seabios patches for virtio-mmio support this allows to
> > > boot standard fedora images (cloud, coreos, workstation live) with the
> > > microvm machine type.
> >
> > what CLI do you use to test it?
>
> Test script below. "qemu-default" is a wrapper script which starts
> qemu-system-x86_64 from my build directory. "qemu-firmware" is the
> same plus isa-debugcon configured for a firmware log on stdout.
>
> Latest bits (with some of the review comments addressed) just pushed
> to git://git,kraxel.org/qemu sirius/microvm
thanks, below are test results I got on my system,
spoiler hw-reduced reduces boot time on ~0.02s compared to full blown acpi
----
using timestamp at "Run /init as init process" as measuring point
no acpi
1.967316
1.975272
1.981267
1.974316
1.962452
1.960988
hw reduced acpi
0.893838
0.892573
0.890585
0.900306
0.897902
normal acpi:
0.921647
0.916298
0.923518
0.916298
0.913234
PS:
I just quickly hacked hw-reduced acpi (using arm/virt as model)
without implementing power button but I doubt that would affect results noticeably
on qemu side it probably also will save some time since there are less
things to setup for qemu.
>
> HTH,
> Gerd
>
> ============================ cut here ============================
> #!/bin/sh
>
> mode="${1}"
> shift
>
> back=()
> devs=()
> args=()
> qemu="qemu-firmware -monitor none -boot menu=on"
> disk=""
> liso=""
> krnl=""
> karg="console=ttyS0,115200"
>
> case "$mode" in
> kernel)
> qemu="qemu-default -nographic"
> disk="/vmdisk/imagefish/rhel-8.1.0-ks-x86_64-testboot-sys-disk.qcow2"
> krnl="$HOME/build/linux-sirius-x86_64-qemu/arch/x86/boot/bzImage"
> karg="$karg root=/dev/sda4"
> karg="$karg quiet"
> ;;
> seabios)
> disk="/vmdisk/imagefish/rhel-8.1.0-ks-x86_64-testboot-sys-disk.qcow2"
> krnl="$HOME/build/linux-sirius-x86_64-qemu/arch/x86/boot/bzImage"
> karg="$karg root=/dev/sda4"
> args+=("-bios" "/home/kraxel/projects/seabios/out-bios-microvm/bios.bin")
> ;;
> cloud)
> disk="/vmdisk/iso/Fedora-Cloud-Base-31-1.9.x86_64.raw"
> ;;
> coreos)
> disk="/vmdisk/iso/fedora-coreos-31.20200210.3.0-metal.x86_64.raw"
> ;;
> live)
> liso="/vmdisk/iso/Fedora-Workstation-Live-x86_64-30-1.2.iso"
> devs+=("-device" "virtio-gpu-device")
> devs+=("-device" "virtio-keyboard-device")
> devs+=("-device" "virtio-tablet-device")
> ;;
> *)
> echo "unknown mode: $mode"
> echo "known modes: kernel seabios cloud coreos live"
> exit 1
> ;;
> esac
>
> if test "$disk" != ""; then
> format="${disk##*.}"
> back+=("-drive" "if=none,id=disk,format=${format},file=${disk}")
> devs+=("-device" "scsi-hd,drive=disk,bootindex=1")
> fi
> if test "$liso" != ""; then
> back+=("-drive" "if=none,id=cdrom,media=cdrom,readonly,format=raw,file=${liso}")
> devs+=("-device" "scsi-cd,drive=cdrom,bootindex=2")
> fi
> if test "$krnl" != ""; then
> args+=("-kernel" "$krnl")
> args+=("-append" "$karg")
> fi
>
> set -ex
> $qemu \
> -enable-kvm \
> -cpu host \
> -M microvm,graphics=off,pit=off,pic=on,rtc=on \
> \
> -m 4G \
> \
> -netdev user,id=net \
> "${back[@]}" \
> \
> -global virtio-mmio.force-legacy=false \
> -device virtio-net-device,netdev=net \
> -device virtio-scsi-device \
> "${devs[@]}" \
> \
> "${args[@]}" \
> "$@"
On Wed, Mar 25, 2020 at 07:44:34PM +0100, Igor Mammedov wrote:
> On Wed, 25 Mar 2020 16:03:39 +0100
> Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> > On Wed, Mar 25, 2020 at 01:32:12PM +0100, Igor Mammedov wrote:
> > > On Thu, 19 Mar 2020 09:01:04 +0100
> > > Gerd Hoffmann <kraxel@redhat.com> wrote:
> > >
> > > > I know that not supporting ACPI in microvm is intentional. If you still
> > > > don't want ACPI this is perfectly fine, you can use the usual -no-acpi
> > > > switch to toggle ACPI support.
> > > >
> > > > These are the advantages you are going to loose then:
> > > >
> > > > (1) virtio-mmio device discovery without command line hacks (tweaking
> > > > the command line is a problem when not using direct kernel boot).
> > > > (2) Better IO-APIC support, we can use IRQ lines 16-23.
> > > > (3) ACPI power button (aka powerdown request) works.
> > > > (4) machine poweroff (aka S5 state) works.
> > > >
> > > > Together with seabios patches for virtio-mmio support this allows to
> > > > boot standard fedora images (cloud, coreos, workstation live) with the
> > > > microvm machine type.
> > >
> > > what CLI do you use to test it?
> >
> > Test script below. "qemu-default" is a wrapper script which starts
> > qemu-system-x86_64 from my build directory. "qemu-firmware" is the
> > same plus isa-debugcon configured for a firmware log on stdout.
> >
> > Latest bits (with some of the review comments addressed) just pushed
> > to git://git,kraxel.org/qemu sirius/microvm
>
> thanks, below are test results I got on my system,
> spoiler hw-reduced reduces boot time on ~0.02s compared to full blown acpi
> ----
> using timestamp at "Run /init as init process" as measuring point
>
> no acpi
> 1.967316
> 1.975272
> 1.981267
> 1.974316
> 1.962452
> 1.960988
>
> hw reduced acpi
> 0.893838
> 0.892573
> 0.890585
> 0.900306
> 0.897902
>
> normal acpi:
> 0.921647
> 0.916298
> 0.923518
> 0.916298
> 0.913234
>
> PS:
> I just quickly hacked hw-reduced acpi (using arm/virt as model)
> without implementing power button but I doubt that would affect results noticeably
> on qemu side it probably also will save some time since there are less
> things to setup for qemu.
And no ACPI is faster because of PS/2 probing, right?
> >
> > HTH,
> > Gerd
> >
> > ============================ cut here ============================
> > #!/bin/sh
> >
> > mode="${1}"
> > shift
> >
> > back=()
> > devs=()
> > args=()
> > qemu="qemu-firmware -monitor none -boot menu=on"
> > disk=""
> > liso=""
> > krnl=""
> > karg="console=ttyS0,115200"
> >
> > case "$mode" in
> > kernel)
> > qemu="qemu-default -nographic"
> > disk="/vmdisk/imagefish/rhel-8.1.0-ks-x86_64-testboot-sys-disk.qcow2"
> > krnl="$HOME/build/linux-sirius-x86_64-qemu/arch/x86/boot/bzImage"
> > karg="$karg root=/dev/sda4"
> > karg="$karg quiet"
> > ;;
> > seabios)
> > disk="/vmdisk/imagefish/rhel-8.1.0-ks-x86_64-testboot-sys-disk.qcow2"
> > krnl="$HOME/build/linux-sirius-x86_64-qemu/arch/x86/boot/bzImage"
> > karg="$karg root=/dev/sda4"
> > args+=("-bios" "/home/kraxel/projects/seabios/out-bios-microvm/bios.bin")
> > ;;
> > cloud)
> > disk="/vmdisk/iso/Fedora-Cloud-Base-31-1.9.x86_64.raw"
> > ;;
> > coreos)
> > disk="/vmdisk/iso/fedora-coreos-31.20200210.3.0-metal.x86_64.raw"
> > ;;
> > live)
> > liso="/vmdisk/iso/Fedora-Workstation-Live-x86_64-30-1.2.iso"
> > devs+=("-device" "virtio-gpu-device")
> > devs+=("-device" "virtio-keyboard-device")
> > devs+=("-device" "virtio-tablet-device")
> > ;;
> > *)
> > echo "unknown mode: $mode"
> > echo "known modes: kernel seabios cloud coreos live"
> > exit 1
> > ;;
> > esac
> >
> > if test "$disk" != ""; then
> > format="${disk##*.}"
> > back+=("-drive" "if=none,id=disk,format=${format},file=${disk}")
> > devs+=("-device" "scsi-hd,drive=disk,bootindex=1")
> > fi
> > if test "$liso" != ""; then
> > back+=("-drive" "if=none,id=cdrom,media=cdrom,readonly,format=raw,file=${liso}")
> > devs+=("-device" "scsi-cd,drive=cdrom,bootindex=2")
> > fi
> > if test "$krnl" != ""; then
> > args+=("-kernel" "$krnl")
> > args+=("-append" "$karg")
> > fi
> >
> > set -ex
> > $qemu \
> > -enable-kvm \
> > -cpu host \
> > -M microvm,graphics=off,pit=off,pic=on,rtc=on \
> > \
> > -m 4G \
> > \
> > -netdev user,id=net \
> > "${back[@]}" \
> > \
> > -global virtio-mmio.force-legacy=false \
> > -device virtio-net-device,netdev=net \
> > -device virtio-scsi-device \
> > "${devs[@]}" \
> > \
> > "${args[@]}" \
> > "$@"
On Thu, 26 Mar 2020 03:33:35 -0400
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Wed, Mar 25, 2020 at 07:44:34PM +0100, Igor Mammedov wrote:
> > On Wed, 25 Mar 2020 16:03:39 +0100
> > Gerd Hoffmann <kraxel@redhat.com> wrote:
> >
> > > On Wed, Mar 25, 2020 at 01:32:12PM +0100, Igor Mammedov wrote:
> > > > On Thu, 19 Mar 2020 09:01:04 +0100
> > > > Gerd Hoffmann <kraxel@redhat.com> wrote:
> > > >
> > > > > I know that not supporting ACPI in microvm is intentional. If you still
> > > > > don't want ACPI this is perfectly fine, you can use the usual -no-acpi
> > > > > switch to toggle ACPI support.
> > > > >
> > > > > These are the advantages you are going to loose then:
> > > > >
> > > > > (1) virtio-mmio device discovery without command line hacks (tweaking
> > > > > the command line is a problem when not using direct kernel boot).
> > > > > (2) Better IO-APIC support, we can use IRQ lines 16-23.
> > > > > (3) ACPI power button (aka powerdown request) works.
> > > > > (4) machine poweroff (aka S5 state) works.
> > > > >
> > > > > Together with seabios patches for virtio-mmio support this allows to
> > > > > boot standard fedora images (cloud, coreos, workstation live) with the
> > > > > microvm machine type.
> > > >
> > > > what CLI do you use to test it?
> > >
> > > Test script below. "qemu-default" is a wrapper script which starts
> > > qemu-system-x86_64 from my build directory. "qemu-firmware" is the
> > > same plus isa-debugcon configured for a firmware log on stdout.
> > >
> > > Latest bits (with some of the review comments addressed) just pushed
> > > to git://git,kraxel.org/qemu sirius/microvm
> >
> > thanks, below are test results I got on my system,
> > spoiler hw-reduced reduces boot time on ~0.02s compared to full blown acpi
> > ----
> > using timestamp at "Run /init as init process" as measuring point
> >
> > no acpi
> > 1.967316
> > 1.975272
> > 1.981267
> > 1.974316
> > 1.962452
> > 1.960988
> >
> > hw reduced acpi
> > 0.893838
> > 0.892573
> > 0.890585
> > 0.900306
> > 0.897902
> >
> > normal acpi:
> > 0.921647
> > 0.916298
> > 0.923518
> > 0.916298
> > 0.913234
> >
> > PS:
> > I just quickly hacked hw-reduced acpi (using arm/virt as model)
> > without implementing power button but I doubt that would affect results noticeably
> > on qemu side it probably also will save some time since there are less
> > things to setup for qemu.
>
> And no ACPI is faster because of PS/2 probing, right?
I suppose you've meant -slower- because of ...
if I compare at 'i8042: PNP: No PS/2 controller found.' to rule out
probing, then no-api and hw-reduced are about in the same ballpark
(3-4ms difference in favor of no-acpi).
no-acpi
0.765785
0.783540
0.785269
0.777751
0.774474
0.770611
0.789309
hw-reduced
0.788733
0.775982
0.793132
0.769077
0.774771
0.775191
0.771170
>
> > >
> > > HTH,
> > > Gerd
> > >
> > > ============================ cut here ============================
> > > #!/bin/sh
> > >
> > > mode="${1}"
> > > shift
> > >
> > > back=()
> > > devs=()
> > > args=()
> > > qemu="qemu-firmware -monitor none -boot menu=on"
> > > disk=""
> > > liso=""
> > > krnl=""
> > > karg="console=ttyS0,115200"
> > >
> > > case "$mode" in
> > > kernel)
> > > qemu="qemu-default -nographic"
> > > disk="/vmdisk/imagefish/rhel-8.1.0-ks-x86_64-testboot-sys-disk.qcow2"
> > > krnl="$HOME/build/linux-sirius-x86_64-qemu/arch/x86/boot/bzImage"
> > > karg="$karg root=/dev/sda4"
> > > karg="$karg quiet"
> > > ;;
> > > seabios)
> > > disk="/vmdisk/imagefish/rhel-8.1.0-ks-x86_64-testboot-sys-disk.qcow2"
> > > krnl="$HOME/build/linux-sirius-x86_64-qemu/arch/x86/boot/bzImage"
> > > karg="$karg root=/dev/sda4"
> > > args+=("-bios" "/home/kraxel/projects/seabios/out-bios-microvm/bios.bin")
> > > ;;
> > > cloud)
> > > disk="/vmdisk/iso/Fedora-Cloud-Base-31-1.9.x86_64.raw"
> > > ;;
> > > coreos)
> > > disk="/vmdisk/iso/fedora-coreos-31.20200210.3.0-metal.x86_64.raw"
> > > ;;
> > > live)
> > > liso="/vmdisk/iso/Fedora-Workstation-Live-x86_64-30-1.2.iso"
> > > devs+=("-device" "virtio-gpu-device")
> > > devs+=("-device" "virtio-keyboard-device")
> > > devs+=("-device" "virtio-tablet-device")
> > > ;;
> > > *)
> > > echo "unknown mode: $mode"
> > > echo "known modes: kernel seabios cloud coreos live"
> > > exit 1
> > > ;;
> > > esac
> > >
> > > if test "$disk" != ""; then
> > > format="${disk##*.}"
> > > back+=("-drive" "if=none,id=disk,format=${format},file=${disk}")
> > > devs+=("-device" "scsi-hd,drive=disk,bootindex=1")
> > > fi
> > > if test "$liso" != ""; then
> > > back+=("-drive" "if=none,id=cdrom,media=cdrom,readonly,format=raw,file=${liso}")
> > > devs+=("-device" "scsi-cd,drive=cdrom,bootindex=2")
> > > fi
> > > if test "$krnl" != ""; then
> > > args+=("-kernel" "$krnl")
> > > args+=("-append" "$karg")
> > > fi
> > >
> > > set -ex
> > > $qemu \
> > > -enable-kvm \
> > > -cpu host \
> > > -M microvm,graphics=off,pit=off,pic=on,rtc=on \
> > > \
> > > -m 4G \
> > > \
> > > -netdev user,id=net \
> > > "${back[@]}" \
> > > \
> > > -global virtio-mmio.force-legacy=false \
> > > -device virtio-net-device,netdev=net \
> > > -device virtio-scsi-device \
> > > "${devs[@]}" \
> > > \
> > > "${args[@]}" \
> > > "$@"
>
>
Hi, > I just quickly hacked hw-reduced acpi (using arm/virt as model) Can you send the patch or push a branch nevertheless? thanks, Gerd
On Fri, 27 Mar 2020 13:06:28 +0100 Gerd Hoffmann <kraxel@redhat.com> wrote: > Hi, > > > I just quickly hacked hw-reduced acpi (using arm/virt as model) > > Can you send the patch or push a branch nevertheless? It's no suitable for patch but I pushed it to my github repo https://github.com/imammedo/qemu.git microvm_acpi I just copy-pasted a bunch of code for test. from cleanup point of view we probably can generalize acpi_ram_update/acpi_build_update/acpi_build_reset/AcpiBuildState across arm/pc/microvm and make a shared acpi_setup for arm + microvm somewhere in hw/acpi/ the rest of common with pc things, I've copy-pasted, could be moved to hw/i386/x86_acpi.c and I'd rename acpi-build.c to pc_acpi.c to make naming consistent > > thanks, > Gerd >
On Thu, Mar 19, 2020 at 09:01:04AM +0100, Gerd Hoffmann wrote: > I know that not supporting ACPI in microvm is intentional. If you still > don't want ACPI this is perfectly fine, you can use the usual -no-acpi > switch to toggle ACPI support. > > These are the advantages you are going to loose then: > > (1) virtio-mmio device discovery without command line hacks (tweaking > the command line is a problem when not using direct kernel boot). > (2) Better IO-APIC support, we can use IRQ lines 16-23. > (3) ACPI power button (aka powerdown request) works. > (4) machine poweroff (aka S5 state) works. What is the cost though? How do boot times compare? > Together with seabios patches for virtio-mmio support this allows to > boot standard fedora images (cloud, coreos, workstation live) with the > microvm machine type. > > cheers, > Gerd > > Gerd Hoffmann (13): > acpi: make build_madt() more generic. > acpi: factor out acpi_dsdt_add_fw_cfg() > microvm: add isa-acpi device > microvm: add minimal acpi support. > microvm: add acpi_dsdt_add_virtio() for x86 > microvm: disable virtio-mmio cmdline hack > [testing] seabios: update submodule to experimental microvm branch > [testing] seabios: update config & build rules > [testing] seabios: update binaries to experimental microvm branch > microvm/acpi: add rtc > microvm/acpi: add serial > microvm: make virtio irq base runtime configurable > microvm/acpi: use GSI 16-23 for virtio > > include/hw/i386/microvm.h | 8 +- > hw/acpi/isa-acpi.c | 114 +++++++++++++++ > hw/i386/acpi-build.c | 278 +++++++++++++++++++++++++++++------- > hw/i386/microvm.c | 32 +++-- > hw/acpi/Makefile.objs | 1 + > pc-bios/bios-256k.bin | Bin 262144 -> 262144 bytes > pc-bios/bios-microvm.bin | Bin 65536 -> 131072 bytes > pc-bios/bios.bin | Bin 131072 -> 131072 bytes > roms/Makefile | 5 +- > roms/config.seabios-128k | 2 + > roms/config.seabios-microvm | 25 ++++ > roms/seabios | 2 +- > 12 files changed, 403 insertions(+), 64 deletions(-) > create mode 100644 hw/acpi/isa-acpi.c > create mode 100644 roms/config.seabios-microvm > > -- > 2.18.2
On Mon, Mar 23, 2020 at 06:51:10AM -0400, Michael S. Tsirkin wrote: > On Thu, Mar 19, 2020 at 09:01:04AM +0100, Gerd Hoffmann wrote: > > I know that not supporting ACPI in microvm is intentional. If you still > > don't want ACPI this is perfectly fine, you can use the usual -no-acpi > > switch to toggle ACPI support. > > > > These are the advantages you are going to loose then: > > > > (1) virtio-mmio device discovery without command line hacks (tweaking > > the command line is a problem when not using direct kernel boot). > > (2) Better IO-APIC support, we can use IRQ lines 16-23. > > (3) ACPI power button (aka powerdown request) works. > > (4) machine poweroff (aka S5 state) works. > > What is the cost though? How do boot times compare? Well, acpi speeds up booting by one second because this delay ... [ 0.275736] i8042: PNP: No PS/2 controller found. [ 0.275736] i8042: Probing ports directly. [ 1.315447] i8042: No controller found ... goes away, at least with standard distro kernels. When building your own you can probably compile out the driver somehow, even though something seems to select SERIO_I8042 so trying to simply flip CONFIG_SERIO_I8042 to 'n' in .config doesn't work. And a runtime switch seems to not be there either ... So that ruined my plan to just time until the root filesystem is mounted. Decided to use the "i8042: PNP: No PS/2 controller found." line instead for a simple test (just check the kernel log timestamps, three runs each). The ACPI initialization is already done at that point, so it should be useful nevertheless. Here we go: Without acpi: 0.277710 0.278852 0.279520 With acpi: 0.283917 0.284262 0.284836 So the difference is less than 0.01 seconds on my box. cheers, Gerd
On Mon, 23 Mar 2020 13:09:48 +0100 Gerd Hoffmann <kraxel@redhat.com> wrote: > On Mon, Mar 23, 2020 at 06:51:10AM -0400, Michael S. Tsirkin wrote: > > On Thu, Mar 19, 2020 at 09:01:04AM +0100, Gerd Hoffmann wrote: > > > I know that not supporting ACPI in microvm is intentional. If you still > > > don't want ACPI this is perfectly fine, you can use the usual -no-acpi > > > switch to toggle ACPI support. > > > > > > These are the advantages you are going to loose then: > > > > > > (1) virtio-mmio device discovery without command line hacks (tweaking > > > the command line is a problem when not using direct kernel boot). > > > (2) Better IO-APIC support, we can use IRQ lines 16-23. > > > (3) ACPI power button (aka powerdown request) works. > > > (4) machine poweroff (aka S5 state) works. > > > > What is the cost though? How do boot times compare? > > Well, acpi speeds up booting by one second because this delay ... > > [ 0.275736] i8042: PNP: No PS/2 controller found. > [ 0.275736] i8042: Probing ports directly. > [ 1.315447] i8042: No controller found > > ... goes away, at least with standard distro kernels. When building > your own you can probably compile out the driver somehow, even though > something seems to select SERIO_I8042 so trying to simply flip > CONFIG_SERIO_I8042 to 'n' in .config doesn't work. And a runtime > switch seems to not be there either ... > > So that ruined my plan to just time until the root filesystem is > mounted. Decided to use the "i8042: PNP: No PS/2 controller found." > line instead for a simple test (just check the kernel log timestamps, > three runs each). The ACPI initialization is already done at that > point, so it should be useful nevertheless. Here we go: > > Without acpi: > 0.277710 > 0.278852 > 0.279520 > > With acpi: > 0.283917 > 0.284262 > 0.284836 I wonder what would be difference with hw-reduced acpi > So the difference is less than 0.01 seconds on my box. > > cheers, > Gerd >
> > mounted. Decided to use the "i8042: PNP: No PS/2 controller found." > > line instead for a simple test (just check the kernel log timestamps, > > three runs each). The ACPI initialization is already done at that > > point, so it should be useful nevertheless. Here we go: > > > > Without acpi: > > 0.277710 > > 0.278852 > > 0.279520 > > > > With acpi: > > 0.283917 > > 0.284262 > > 0.284836 > I wonder what would be difference with hw-reduced acpi The kernel does a bunch of reads+writes at boot (roughly 20-30), mostly timer ports, so probably while initializing the pm_timer clocksource. Then it stops talking to the acpi hardware, preferring kvmclock clocksouce I guess. So I expect hw-reduced acpi wouldn't make much of a difference. Actually trying that isn't that high on my priority list. There is bigger fish to fry, untangling the hw/i386/acpi-build.c monster for starters, so building with ACPI=y + PCI=n works ... cheers, Gerd
On Wed, 25 Mar 2020 10:16:36 +0100 Gerd Hoffmann <kraxel@redhat.com> wrote: > > > mounted. Decided to use the "i8042: PNP: No PS/2 controller found." > > > line instead for a simple test (just check the kernel log timestamps, > > > three runs each). The ACPI initialization is already done at that > > > point, so it should be useful nevertheless. Here we go: > > > > > > Without acpi: > > > 0.277710 > > > 0.278852 > > > 0.279520 > > > > > > With acpi: > > > 0.283917 > > > 0.284262 > > > 0.284836 > > I wonder what would be difference with hw-reduced acpi > > The kernel does a bunch of reads+writes at boot (roughly 20-30), > mostly timer ports, so probably while initializing the pm_timer > clocksource. Then it stops talking to the acpi hardware, > preferring kvmclock clocksouce I guess. > > So I expect hw-reduced acpi wouldn't make much of a difference. > Actually trying that isn't that high on my priority list. > > There is bigger fish to fry, untangling the hw/i386/acpi-build.c > monster for starters, so building with ACPI=y + PCI=n works ... if you are after reducing start up time it may be better to leave alone acpi-build.c with a bunch of legacy/compat stuff and create microvm specific acpi file, and extract from acpi-build.c only common bits that are necessary to produce tables (i.e. do something similar hw/arm/virt-acpi-build.c) PS: side-note: guest kernel insist on finding PCI where it doesn't exists [ 0.301104] ACPI: bus type PCI registered [ 0.301717] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [ 0.302180] PCI: Fatal: No config space access function found it's probably the first time x86 generic kernel sees machine without PCI, and it probably could be fixed saving another 10-20ms > > cheers, > Gerd > >
On Wed, 25 Mar 2020 10:16:36 +0100 Gerd Hoffmann <kraxel@redhat.com> wrote: > > > mounted. Decided to use the "i8042: PNP: No PS/2 controller found." > > > line instead for a simple test (just check the kernel log timestamps, > > > three runs each). The ACPI initialization is already done at that > > > point, so it should be useful nevertheless. Here we go: > > > > > > Without acpi: > > > 0.277710 > > > 0.278852 > > > 0.279520 > > > > > > With acpi: > > > 0.283917 > > > 0.284262 > > > 0.284836 > > I wonder what would be difference with hw-reduced acpi > > The kernel does a bunch of reads+writes at boot (roughly 20-30), > mostly timer ports, so probably while initializing the pm_timer > clocksource. Then it stops talking to the acpi hardware, > preferring kvmclock clocksouce I guess. > > So I expect hw-reduced acpi wouldn't make much of a difference. > Actually trying that isn't that high on my priority list. there aren't pm timers on hw-reduced, that's the point of it (a bunch of registers that where mandatory with full profile are absent so OS doesn't have to initialize not needed stuff) > There is bigger fish to fry, untangling the hw/i386/acpi-build.c > monster for starters, so building with ACPI=y + PCI=n works ... > > cheers, > Gerd >
© 2016 - 2024 Red Hat, Inc.