* [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines'
@ 2016-11-22 1:11 Eduardo Habkost
2016-11-22 1:11 ` [Qemu-devel] [RFC 01/15] qemu.py: Make logging optional Eduardo Habkost
` (19 more replies)
0 siblings, 20 replies; 43+ messages in thread
From: Eduardo Habkost @ 2016-11-22 1:11 UTC (permalink / raw)
To: qemu-devel, Markus Armbruster, Marcel Apfelbaum, Michael S. Tsirkin
Cc: libvir-list, Laine Stump
The Problem
===========
Currently management software has no way to find out which device
types can be plugged in a machine, unless the machine is already
initialized.
Even after the machine is initialized, there's no way to map
existing bus types to supported device types unless management
software hardcodes the mapping between bus types and device
types.
Example: floppy support on q35 vs i440fx
----------------------------------------
There's no way for libvirt to find out that there's no floppy
controller on pc-q35-* machine-types by default.
With this series, pc-i440fx-* will report "floppy" as a supported
device type, but pc-q35-* will not.
Example: Legacy PCI vs vs PCIe devices
--------------------------------------
Some devices require a PCIe bus to be available, others work on
both legacy PCI and PCIe, while others work only on a legacy PCI
bus.
Currently management software has no way to know which devices
can be added to a given machine, unless it hardcodes machine-type
names and device-types names.
The Proposed Interface
======================
This series adds a new field to the output of 'query-machines':
'supported-device-types'. It will contain a list of QOM type
names, that can be used to find the list of device types that can
be plugged in the machine by default. The type names reported on
the new field can then be used as the 'implements' argument on
the 'qom-list-types' command, to find out which device types can
be plugged on the machine.
Example output
--------------
(QEMU) query-machines
{
"return": [
[...]
{
"supported-device-types": [
"sys-bus-device"
],
"cpu-max": 1,
"hotpluggable-cpus": false,
"name": "none"
},
[...]
{
"supported-device-types": [
"sys-bus-device"
],
"cpu-max": 1,
"hotpluggable-cpus": false,
"name": "xenpv"
},
[...]
{
"supported-device-types": [
"sys-bus-device",
"floppy",
"i2c-slave",
"pci-device",
"isa-device",
"ide-device"
],
"name": "pc-i440fx-2.8",
"alias": "pc",
"is-default": true,
"cpu-max": 255,
"hotpluggable-cpus": true
},
[...]
{
"supported-device-types": [
"sys-bus-device",
"floppy",
"isa-device",
"ide-device"
],
"cpu-max": 1,
"hotpluggable-cpus": true,
"name": "isapc"
},
[...]
{
"supported-device-types": [
"sys-bus-device",
"floppy",
"i2c-slave",
"pci-device",
"isa-device",
"ide-device"
],
"cpu-max": 128,
"hotpluggable-cpus": true,
"name": "xenfv"
},
[...]
{
"alias": "q35",
"supported-device-types": [
"sys-bus-device",
"i2c-slave",
"PCIE-device",
"isa-device",
"ide-device"
],
"cpu-max": 288,
"hotpluggable-cpus": true,
"name": "pc-q35-2.8"
},
[...]
]
}
Considered alternatives
=======================
Indirect mapping (machine => bus => device)
-------------------------------------------
This RFC implements a mechanism to implement ax
machine-type => supported-device-types
mapping. An alternative solution I considered was to expose an
indirect mapping:
machine-type => default-bus-types
followed by
bus-type => supported-device-types.
But exposing only the resulting supported device-types list
imposes less restrictions on how the device and bus type
hierarchy is implemented inside QEMU. There's still a
machine-type => bus-type => device-type
mapping implemented internally, but it is an implementation
detail on the current version, and not part of the
externally-visible interface.
The Implementation
==================
This add a new field to MachineClass: default_bus_types, and a
new field to BusClass: supported_device_type.
The two fields are used to build the list of supported device
types for a given machine. On most cases, the normal QOM type
hierarchy is used to define the set of supported devices for a
bus. On the case of PCIe buses, a INTERFACE_PCIE_DEVICE interface
name was introduced, to indicate PCIe-capable devices.
This means we are duplicating information in some cases:
* BusClass::supported_device_type duplicates knowlege that is
already encoded in DeviceClass::bus_type.
To make sure both fields agree with each other, a new
device_class_set_bus_type() wrapper was added, to perform
additional validation.
* MachineClass::default_bus_type duplicates knowledge that is
already encoded in the machine init function.
To make sure the information is correct, a qmp-machine-info.py
test case is added, that will validate the
supported-device-types field based on the buses created by the
machine.
* PCIDeviceClass::is_express and INTERFACE_PCIE_DEVICE
both encode the same information about a PCI device class.
A future version of this series may include a
class_base_post_init hook that will allow TYPE_PCI_DEVICE to
validate/update is_express and the interface list to ensure
both are always consistent.
Test Code
---------
qdev-based test code for the new field was implemented in a
Python script. Some extra support was implemented in
tests/Makefile.include, scripts/qemu.py and scripts/qtest.py to
allow the test to be implemented.
Limitations
===========
TYPE_SYS_BUS_DEVICE is too generic
----------------------------------
Currently all machines have a TYPE_SYS_BUS bus, meaning all
TYPE_SYS_BUS_DEVICE subclasses are reported as supported.
The current solution in this series is to report
TYPE_SYS_BUS_DEVICE as supported by all machines. But we could
gradually add arch-specific or machine-family-specific interface
names that can be used on devices that are meant to work with
only a subset of TYPE_SYS_BUS_DEVICE subclasses.
A future version of this series may remove TYPE_SYS_BUS_DEVICE
from the supported-device-types output, and return a
arch-specific or machine-family-specific interface name to
restrict management software to a subset of TYPE_SYS_BUS_DEVICE
subclasses.
PCI vs PCIe
-----------
Machines with PCIe buses will report INTERFACE_PCIE_DEVICE on
supported-device-types.
Machines with legacy PCI buses will report TYPE_PCI_DEVICE on
supported-device-types.
The problem with the current approach is that PCIe devices are
TYPE_PCI_DEVICE subclasses. The allows PCI device classes to
indicate they are PCIe-capable, but there's no obvious way to
indicate that a device is PCIe-only. This needs to be addressed
in a future version of this series.
Suggestions are welcome.
Incomplete bus lists on some machines
-------------------------------------
With this series, not all machines classes are changed to add the
full list of device types on the 'supported-device-types'. To
allow the code to be updated gradually, qmp-machine-info.py has a
STRICT_ARCHES variable, that will make the test code require a
complete device type list only on some architectures.
Out of scope: Configurable buses
--------------------------------
There's no way to map machine options like "usb=on|off" to
device-types or buses. I plan to propose a new interface that
allows machine options to be mapped to buses/device-types later.
Out of scope: Deciding where to plug devices
--------------------------------------------
Once management software discovers which devices can be plugged
to a machine, it still has to discover or define where devices
can/should/will be plugged. This is out of the scope of this
series.
Out of scope: Hotplug
---------------------
The proposed interface is supposed to help management software
find which device types can be used when creating the VM. Device
hotplug is out of the scope of this series. However, the new
'device-types' QOM property on bus objects could be used to find
out which device types can be plugged on the existing buses.
---
Cc: libvir-list@redhat.com
Cc: Laine Stump <laine@redhat.com>
Eduardo Habkost (15):
qemu.py: Make logging optional
qtest.py: Support QTEST_LOG environment variable
qtest.py: make logging optional
qtest.py: Make 'binary' parameter optional
tests: Add rules to non-gtester qtest test cases
qdev: Add device_type field to BusClass
machine: Add MachineClass::default_buses field
qmp: Add 'supported-device-types' field to 'query-machines'
pci: Introduce INTERFACE_PCIE_DEVICE interface name
pc: Initialize default bus lists
s390x: Initialize default bus lists
arm: Initialize default bus lists
mips: Initialize default bus lists
ppc: Initialize default bus lists
qdev: Add device_class_set_bus_type() function
hw/arm/aspeed.c | 2 +
hw/arm/collie.c | 1 +
hw/arm/cubieboard.c | 1 +
hw/arm/exynos4_boards.c | 5 ++
hw/arm/gumstix.c | 7 ++
hw/arm/highbank.c | 4 ++
hw/arm/imx25_pdk.c | 1 +
hw/arm/kzm.c | 1 +
hw/arm/musicpal.c | 1 +
hw/arm/nseries.c | 2 +
hw/arm/palm.c | 1 +
hw/arm/realview.c | 1 +
hw/arm/spitz.c | 10 +++
hw/arm/stellaris.c | 4 ++
hw/audio/intel-hda.c | 9 ++-
hw/block/fdc.c | 17 +++--
hw/block/nvme.c | 4 ++
hw/char/virtio-serial-bus.c | 3 +-
hw/core/bus.c | 9 +++
hw/core/machine.c | 18 ++++-
hw/core/qdev.c | 8 +++
hw/core/sysbus.c | 3 +-
hw/i2c/core.c | 9 ++-
hw/i386/pc_piix.c | 13 ++++
hw/i386/pc_q35.c | 4 ++
hw/ide/qdev.c | 3 +-
hw/input/adb.c | 9 ++-
hw/ipack/ipack.c | 9 ++-
hw/isa/isa-bus.c | 3 +-
hw/mips/mips_malta.c | 7 ++
hw/mips/mips_r4k.c | 2 +
hw/misc/auxbus.c | 3 +-
hw/net/e1000e.c | 4 ++
hw/net/vmxnet3.c | 4 ++
hw/pci-bridge/ioh3420.c | 4 ++
hw/pci-bridge/xio3130_downstream.c | 4 ++
hw/pci/pci.c | 16 ++++-
hw/ppc/e500plat.c | 3 +
hw/ppc/mac_newworld.c | 4 ++
hw/ppc/mac_oldworld.c | 3 +
hw/ppc/mpc8544ds.c | 4 ++
hw/ppc/ppc440_bamboo.c | 1 +
hw/ppc/prep.c | 4 ++
hw/ppc/spapr_vio.c | 3 +-
hw/s390x/css-bridge.c | 2 +
hw/s390x/event-facility.c | 3 +-
hw/s390x/s390-pci-bus.c | 9 ++-
hw/s390x/s390-virtio-ccw.c | 6 ++
hw/s390x/virtio-ccw.c | 2 +-
hw/scsi/megasas.c | 7 ++
hw/scsi/scsi-bus.c | 3 +-
hw/scsi/vmw_pvscsi.c | 1 +
hw/sd/core.c | 7 ++
hw/sd/sd.c | 2 +-
hw/ssi/ssi.c | 9 ++-
hw/usb/bus.c | 3 +-
hw/usb/dev-smartcard-reader.c | 9 ++-
hw/usb/hcd-xhci.c | 4 ++
hw/vfio/pci.c | 4 ++
hw/virtio/virtio-bus.c | 1 +
hw/virtio/virtio-pci.c | 4 ++
hw/virtio/virtio.c | 2 +-
include/hw/boards.h | 5 ++
include/hw/pci/pci.h | 3 +
include/hw/qdev-core.h | 4 ++
qapi-schema.json | 9 ++-
scripts/qemu.py | 25 +++++--
scripts/qtest.py | 15 +++-
tests/Makefile.include | 39 ++++++++++-
tests/qmp-machine-info.py | 138 +++++++++++++++++++++++++++++++++++++
vl.c | 11 +++
71 files changed, 518 insertions(+), 37 deletions(-)
create mode 100755 tests/qmp-machine-info.py
--
2.7.4
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Qemu-devel] [RFC 01/15] qemu.py: Make logging optional
2016-11-22 1:11 [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Eduardo Habkost
@ 2016-11-22 1:11 ` Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 02/15] qtest.py: Support QTEST_LOG environment variable Eduardo Habkost
` (18 subsequent siblings)
19 siblings, 0 replies; 43+ messages in thread
From: Eduardo Habkost @ 2016-11-22 1:11 UTC (permalink / raw)
To: qemu-devel, Markus Armbruster, Marcel Apfelbaum, Michael S. Tsirkin
If a test case doesn't make QEMU generate any output, there's no
need to redirect stdout and stderr to a file. On those cases,
logging can be disabled so any errors are included on the test
case output.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
scripts/qemu.py | 25 +++++++++++++++++++------
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/scripts/qemu.py b/scripts/qemu.py
index 6d1b623..1468286 100644
--- a/scripts/qemu.py
+++ b/scripts/qemu.py
@@ -24,13 +24,17 @@ class QEMUMachine(object):
'''A QEMU VM'''
def __init__(self, binary, args=[], wrapper=[], name=None, test_dir="/var/tmp",
- monitor_address=None, socket_scm_helper=None, debug=False):
+ monitor_address=None, socket_scm_helper=None, debug=False,
+ logging=True):
if name is None:
name = "qemu-%d" % os.getpid()
if monitor_address is None:
monitor_address = os.path.join(test_dir, name + "-monitor.sock")
self._monitor_address = monitor_address
- self._qemu_log_path = os.path.join(test_dir, name + ".log")
+ if logging:
+ self._qemu_log_path = os.path.join(test_dir, name + ".log")
+ else:
+ self._qemu_log_path = None
self._popen = None
self._binary = binary
self._args = list(args) # Force copy args in case we modify them
@@ -91,6 +95,8 @@ class QEMUMachine(object):
return self._popen.pid
def _load_io_log(self):
+ if self._qemu_log_path is None:
+ return
with open(self._qemu_log_path, "r") as fh:
self._iolog = fh.read()
@@ -115,17 +121,24 @@ class QEMUMachine(object):
def _post_shutdown(self):
if not isinstance(self._monitor_address, tuple):
self._remove_if_exists(self._monitor_address)
- self._remove_if_exists(self._qemu_log_path)
+ if self._qemu_log_path is not None:
+ self._remove_if_exists(self._qemu_log_path)
def launch(self):
'''Launch the VM and establish a QMP connection'''
devnull = open('/dev/null', 'rb')
- qemulog = open(self._qemu_log_path, 'wb')
+ if self._qemu_log_path is not None:
+ qemulog = open(self._qemu_log_path, 'wb')
+ stdout=qemulog
+ stderr=subprocess.STDOUT
+ else:
+ stdout=None
+ stderr=None
try:
self._pre_launch()
args = self._wrapper + [self._binary] + self._base_args() + self._args
- self._popen = subprocess.Popen(args, stdin=devnull, stdout=qemulog,
- stderr=subprocess.STDOUT, shell=False)
+ self._popen = subprocess.Popen(args, stdin=devnull, stdout=stdout,
+ stderr=stderr, shell=False)
self._post_launch()
except:
if self._popen:
--
2.7.4
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Qemu-devel] [RFC 02/15] qtest.py: Support QTEST_LOG environment variable
2016-11-22 1:11 [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Eduardo Habkost
2016-11-22 1:11 ` [Qemu-devel] [RFC 01/15] qemu.py: Make logging optional Eduardo Habkost
@ 2016-11-22 1:12 ` Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 03/15] qtest.py: make logging optional Eduardo Habkost
` (17 subsequent siblings)
19 siblings, 0 replies; 43+ messages in thread
From: Eduardo Habkost @ 2016-11-22 1:12 UTC (permalink / raw)
To: qemu-devel, Markus Armbruster, Marcel Apfelbaum, Michael S. Tsirkin
qtest logs everything to stderr by default, but we don't want it
to be the default behavior on test cases.
Implement the same behavior of libqtest.c, and redirect the qtest
log to /dev/null by default unless the QTEST_LOG environment
variable is set.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
scripts/qtest.py | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/scripts/qtest.py b/scripts/qtest.py
index d5aecb5..5ac2c69 100644
--- a/scripts/qtest.py
+++ b/scripts/qtest.py
@@ -88,8 +88,14 @@ class QEMUQtestMachine(qemu.QEMUMachine):
self._qtest_path = os.path.join(test_dir, name + "-qtest.sock")
def _base_args(self):
+ if os.getenv('QTEST_LOG'):
+ qtest_log = '/dev/fd/2'
+ else:
+ qtest_log = '/dev/null'
+
args = super(QEMUQtestMachine, self)._base_args()
args.extend(['-qtest', 'unix:path=' + self._qtest_path,
+ '-qtest-log', qtest_log,
'-machine', 'accel=qtest'])
return args
--
2.7.4
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Qemu-devel] [RFC 03/15] qtest.py: make logging optional
2016-11-22 1:11 [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Eduardo Habkost
2016-11-22 1:11 ` [Qemu-devel] [RFC 01/15] qemu.py: Make logging optional Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 02/15] qtest.py: Support QTEST_LOG environment variable Eduardo Habkost
@ 2016-11-22 1:12 ` Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 04/15] qtest.py: Make 'binary' parameter optional Eduardo Habkost
` (16 subsequent siblings)
19 siblings, 0 replies; 43+ messages in thread
From: Eduardo Habkost @ 2016-11-22 1:12 UTC (permalink / raw)
To: qemu-devel, Markus Armbruster, Marcel Apfelbaum, Michael S. Tsirkin
Support the 'logging' parameter on QEMUQtestMachine, for test
cases that don't require logging.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
scripts/qtest.py | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/scripts/qtest.py b/scripts/qtest.py
index 5ac2c69..0496490 100644
--- a/scripts/qtest.py
+++ b/scripts/qtest.py
@@ -80,11 +80,12 @@ class QEMUQtestMachine(qemu.QEMUMachine):
'''A QEMU VM'''
def __init__(self, binary, args=[], name=None, test_dir="/var/tmp",
- socket_scm_helper=None):
+ socket_scm_helper=None, logging=True):
if name is None:
name = "qemu-%d" % os.getpid()
super(QEMUQtestMachine, self).__init__(binary, args, name=name, test_dir=test_dir,
- socket_scm_helper=socket_scm_helper)
+ socket_scm_helper=socket_scm_helper,
+ logging=logging)
self._qtest_path = os.path.join(test_dir, name + "-qtest.sock")
def _base_args(self):
--
2.7.4
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Qemu-devel] [RFC 04/15] qtest.py: Make 'binary' parameter optional
2016-11-22 1:11 [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Eduardo Habkost
` (2 preceding siblings ...)
2016-11-22 1:12 ` [Qemu-devel] [RFC 03/15] qtest.py: make logging optional Eduardo Habkost
@ 2016-11-22 1:12 ` Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 05/15] tests: Add rules to non-gtester qtest test cases Eduardo Habkost
` (15 subsequent siblings)
19 siblings, 0 replies; 43+ messages in thread
From: Eduardo Habkost @ 2016-11-22 1:12 UTC (permalink / raw)
To: qemu-devel, Markus Armbruster, Marcel Apfelbaum, Michael S. Tsirkin
If the 'binary' parameter is omitted, use the $QTEST_QEMU_BINARY
environment variable.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
scripts/qtest.py | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/scripts/qtest.py b/scripts/qtest.py
index 0496490..5a37b48 100644
--- a/scripts/qtest.py
+++ b/scripts/qtest.py
@@ -79,8 +79,10 @@ class QEMUQtestProtocol(object):
class QEMUQtestMachine(qemu.QEMUMachine):
'''A QEMU VM'''
- def __init__(self, binary, args=[], name=None, test_dir="/var/tmp",
+ def __init__(self, binary=None, args=[], name=None, test_dir="/var/tmp",
socket_scm_helper=None, logging=True):
+ if binary is None:
+ binary = os.getenv('QTEST_QEMU_BINARY')
if name is None:
name = "qemu-%d" % os.getpid()
super(QEMUQtestMachine, self).__init__(binary, args, name=name, test_dir=test_dir,
--
2.7.4
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Qemu-devel] [RFC 05/15] tests: Add rules to non-gtester qtest test cases
2016-11-22 1:11 [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Eduardo Habkost
` (3 preceding siblings ...)
2016-11-22 1:12 ` [Qemu-devel] [RFC 04/15] qtest.py: Make 'binary' parameter optional Eduardo Habkost
@ 2016-11-22 1:12 ` Eduardo Habkost
2016-11-22 13:34 ` Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 06/15] qdev: Add device_type field to BusClass Eduardo Habkost
` (14 subsequent siblings)
19 siblings, 1 reply; 43+ messages in thread
From: Eduardo Habkost @ 2016-11-22 1:12 UTC (permalink / raw)
To: qemu-devel, Markus Armbruster, Marcel Apfelbaum, Michael S. Tsirkin
Today, simple non-gtester binaries can be run easily by a single
Makefile rule (e.g. check-tests/qemu-iotest-quick.sh), but we
don't have anything to help us automatically run the same test
binary for multiple architectures.
This add check-simpleqtest-* rules that will help us run binaries
present in $(check-simpleqtest-*-y).
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
tests/Makefile.include | 37 ++++++++++++++++++++++++++++++++++++-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/tests/Makefile.include b/tests/Makefile.include
index e98d3b6..eb1031b 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -791,6 +791,40 @@ check-report.html: check-report.xml
$(call quiet-command,gtester-report $< > $@,"GEN","$@")
+# rules for non-gtester qtest tests:
+
+SIMPLETEST_OPTIONS = $(if $(V),--verbose,--quiet)
+
+# rule dependencies are:
+# check-simpleqtest: check-simpleqtest-$(ARCH) for each ARCH in QTEST_ARCH
+# check-simpleqtest-$(ARCH): check-simpleqtest-$(TEST)-$(ARCH) for each
+# TEST in $(check-simpleqtest-$(ARCH)-y)
+# (generated by qtest_target macro)
+# check-simpleqtest-$(TEST)-$(ARCH): runs test with $(SIMPLETEST_OPTIONS)
+# (generated by qtest_target macro)
+#
+# $(check-simpleqtest-$(ARCH)-y) automatically includes
+# $(check-simpleqtest-generic-y)
+
+define qtest-target =
+
+check-simpleqtest-$(1)-y += $$(check-simpleqtest-generic-y)
+
+.PHONY: $$(patsubst %, check-simpleqtest-%-$(1), $$(check-simpleqtest-$(1)-y))
+$$(patsubst %, check-simpleqtest-%-$(1), $$(check-simpleqtest-$(1)-y)): check-simpleqtest-%-$(1): %
+ $$(call quiet-command,QTEST_QEMU_BINARY=$(1)-softmmu/qemu-system-$(1) \
+ QTEST_QEMU_IMG=qemu-img$$(EXESUF) \
+ MALLOC_PERTURB_=$${MALLOC_PERTURB_:-$$((RANDOM % 255 + 1))} \
+ $$< $$(SIMPLETEST_OPTIONS),"QTEST", "$$<")
+
+.PHONY: check-simpleqtest-$(1)
+check-simpleqtest-$(1): $$(patsubst %, check-simpleqtest-%-$(1), $$(check-simpleqtest-$(1)-y))
+
+endef
+
+$(foreach TARGET,$(QTEST_TARGETS),$(eval $(call qtest-target,$(TARGET))))
+
+
# Other tests
QEMU_IOTESTS_HELPERS-$(CONFIG_LINUX) = tests/qemu-iotests/socket_scm_helper$(EXESUF)
@@ -818,7 +852,8 @@ $(patsubst %, check-%, $(check-qapi-schema-y)): check-%.json: $(SRC_PATH)/%.json
.PHONY: check-qapi-schema check-qtest check-unit check check-clean
check-qapi-schema: $(patsubst %,check-%, $(check-qapi-schema-y))
-check-qtest: $(patsubst %,check-qtest-%, $(QTEST_TARGETS))
+check-simpleqtest: $(patsubst %,check-simpleqtest-%, $(QTEST_TARGETS))
+check-qtest: $(patsubst %,check-qtest-%, $(QTEST_TARGETS)) check-simpleqtest
check-unit: $(patsubst %,check-%, $(check-unit-y))
check-block: $(patsubst %,check-%, $(check-block-y))
check: check-qapi-schema check-unit check-qtest
--
2.7.4
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Qemu-devel] [RFC 06/15] qdev: Add device_type field to BusClass
2016-11-22 1:11 [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Eduardo Habkost
` (4 preceding siblings ...)
2016-11-22 1:12 ` [Qemu-devel] [RFC 05/15] tests: Add rules to non-gtester qtest test cases Eduardo Habkost
@ 2016-11-22 1:12 ` Eduardo Habkost
2016-11-24 16:48 ` Cornelia Huck
2016-11-22 1:12 ` [Qemu-devel] [RFC 07/15] machine: Add MachineClass::default_buses field Eduardo Habkost
` (13 subsequent siblings)
19 siblings, 1 reply; 43+ messages in thread
From: Eduardo Habkost @ 2016-11-22 1:12 UTC (permalink / raw)
To: qemu-devel, Markus Armbruster, Marcel Apfelbaum, Michael S. Tsirkin
Each bus class will now be aware of the specific device type that
can be plugged on it.
Also add a read-only 'device-type' property to the class, that
will be useful for:
* Runtime check for which devices types can be plugged to the
machine;
* Validation of query-machines output by automated tests.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
hw/audio/intel-hda.c | 7 +++++++
hw/block/fdc.c | 15 +++++++++++----
hw/char/virtio-serial-bus.c | 1 +
hw/core/bus.c | 9 +++++++++
hw/core/sysbus.c | 1 +
hw/i2c/core.c | 7 +++++++
hw/ide/qdev.c | 1 +
hw/input/adb.c | 7 +++++++
hw/ipack/ipack.c | 7 +++++++
hw/isa/isa-bus.c | 1 +
hw/misc/auxbus.c | 1 +
hw/pci/pci.c | 1 +
hw/ppc/spapr_vio.c | 1 +
hw/s390x/css-bridge.c | 2 ++
hw/s390x/event-facility.c | 1 +
hw/s390x/s390-pci-bus.c | 7 +++++++
hw/scsi/scsi-bus.c | 1 +
hw/sd/core.c | 7 +++++++
hw/ssi/ssi.c | 7 +++++++
hw/usb/bus.c | 1 +
hw/usb/dev-smartcard-reader.c | 7 +++++++
hw/virtio/virtio-bus.c | 1 +
include/hw/qdev-core.h | 2 ++
23 files changed, 91 insertions(+), 4 deletions(-)
diff --git a/hw/audio/intel-hda.c b/hw/audio/intel-hda.c
index 537face..a363993 100644
--- a/hw/audio/intel-hda.c
+++ b/hw/audio/intel-hda.c
@@ -36,9 +36,16 @@ static Property hda_props[] = {
DEFINE_PROP_END_OF_LIST()
};
+static void hda_codec_bus_class_init(ObjectClass *oc, void *opaque)
+{
+ BusClass *bc = BUS_CLASS(oc);
+ bc->device_type = TYPE_HDA_CODEC_DEVICE;
+}
+
static const TypeInfo hda_codec_bus_info = {
.name = TYPE_HDA_BUS,
.parent = TYPE_BUS,
+ .class_init = hda_codec_bus_class_init,
.instance_size = sizeof(HDACodecBus),
};
diff --git a/hw/block/fdc.c b/hw/block/fdc.c
index 17d29e7..09bfdda 100644
--- a/hw/block/fdc.c
+++ b/hw/block/fdc.c
@@ -60,6 +60,10 @@
#define TYPE_FLOPPY_BUS "floppy-bus"
#define FLOPPY_BUS(obj) OBJECT_CHECK(FloppyBus, (obj), TYPE_FLOPPY_BUS)
+#define TYPE_FLOPPY_DRIVE "floppy"
+#define FLOPPY_DRIVE(obj) \
+ OBJECT_CHECK(FloppyDrive, (obj), TYPE_FLOPPY_DRIVE)
+
typedef struct FDCtrl FDCtrl;
typedef struct FDrive FDrive;
static FDrive *get_drv(FDCtrl *fdctrl, int unit);
@@ -69,9 +73,16 @@ typedef struct FloppyBus {
FDCtrl *fdc;
} FloppyBus;
+static void floppy_bus_class_init(ObjectClass *oc, void *opaque)
+{
+ BusClass *bc = BUS_CLASS(oc);
+ bc->device_type = TYPE_FLOPPY_DRIVE;
+}
+
static const TypeInfo floppy_bus_info = {
.name = TYPE_FLOPPY_BUS,
.parent = TYPE_BUS,
+ .class_init = floppy_bus_class_init,
.instance_size = sizeof(FloppyBus),
};
@@ -483,10 +494,6 @@ static const BlockDevOps fd_block_ops = {
};
-#define TYPE_FLOPPY_DRIVE "floppy"
-#define FLOPPY_DRIVE(obj) \
- OBJECT_CHECK(FloppyDrive, (obj), TYPE_FLOPPY_DRIVE)
-
typedef struct FloppyDrive {
DeviceState qdev;
uint32_t unit;
diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index 7975c2c..215e180 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -832,6 +832,7 @@ static void virtser_bus_class_init(ObjectClass *klass, void *data)
{
BusClass *k = BUS_CLASS(klass);
k->print_dev = virtser_bus_dev_print;
+ k->device_type = TYPE_VIRTIO_SERIAL_PORT;
}
static const TypeInfo virtser_bus_info = {
diff --git a/hw/core/bus.c b/hw/core/bus.c
index cf383fc..57bac8f 100644
--- a/hw/core/bus.c
+++ b/hw/core/bus.c
@@ -208,12 +208,21 @@ static char *default_bus_get_fw_dev_path(DeviceState *dev)
return g_strdup(object_get_typename(OBJECT(dev)));
}
+static char *bus_get_device_type(Object *obj, Error **errp)
+{
+ BusClass *bc = BUS_GET_CLASS(obj);
+ return g_strdup(bc->device_type);
+}
+
static void bus_class_init(ObjectClass *class, void *data)
{
BusClass *bc = BUS_CLASS(class);
class->unparent = bus_unparent;
bc->get_fw_dev_path = default_bus_get_fw_dev_path;
+
+ object_class_property_add_str(class, "device-type",
+ bus_get_device_type, NULL, &error_abort);
}
static void qbus_finalize(Object *obj)
diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index c0f560b..c065eb8 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -76,6 +76,7 @@ static void system_bus_class_init(ObjectClass *klass, void *data)
k->print_dev = sysbus_dev_print;
k->get_fw_dev_path = sysbus_get_fw_dev_path;
+ k->device_type = TYPE_SYS_BUS_DEVICE;
}
static const TypeInfo system_bus_info = {
diff --git a/hw/i2c/core.c b/hw/i2c/core.c
index abd4c4c..81b6ae4 100644
--- a/hw/i2c/core.c
+++ b/hw/i2c/core.c
@@ -35,9 +35,16 @@ static Property i2c_props[] = {
#define TYPE_I2C_BUS "i2c-bus"
#define I2C_BUS(obj) OBJECT_CHECK(I2CBus, (obj), TYPE_I2C_BUS)
+static void i2c_bus_class_init(ObjectClass *oc, void *opaque)
+{
+ BusClass *bc = BUS_CLASS(oc);
+ bc->device_type = TYPE_I2C_SLAVE;
+}
+
static const TypeInfo i2c_bus_info = {
.name = TYPE_I2C_BUS,
.parent = TYPE_BUS,
+ .class_init = i2c_bus_class_init,
.instance_size = sizeof(I2CBus),
};
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index dbaa75c..b526f85 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -43,6 +43,7 @@ static void ide_bus_class_init(ObjectClass *klass, void *data)
BusClass *k = BUS_CLASS(klass);
k->get_fw_dev_path = idebus_get_fw_dev_path;
+ k->device_type = TYPE_IDE_DEVICE;
}
static void idebus_unrealize(DeviceState *qdev, Error **errp)
diff --git a/hw/input/adb.c b/hw/input/adb.c
index 43d3205..c6a2b31 100644
--- a/hw/input/adb.c
+++ b/hw/input/adb.c
@@ -121,9 +121,16 @@ int adb_poll(ADBBusState *s, uint8_t *obuf, uint16_t poll_mask)
return olen;
}
+static void adb_bus_class_init(ObjectClass *oc, void *opaque)
+{
+ BusClass *bc = BUS_CLASS(oc);
+ bc->device_type = TYPE_ADB_DEVICE;
+}
+
static const TypeInfo adb_bus_type_info = {
.name = TYPE_ADB_BUS,
.parent = TYPE_BUS,
+ .class_init = adb_bus_class_init,
.instance_size = sizeof(ADBBusState),
};
diff --git a/hw/ipack/ipack.c b/hw/ipack/ipack.c
index 6021e6d..f22c504 100644
--- a/hw/ipack/ipack.c
+++ b/hw/ipack/ipack.c
@@ -106,9 +106,16 @@ static const TypeInfo ipack_device_info = {
.abstract = true,
};
+static void ipack_bus_class_init(ObjectClass *oc, void *opaque)
+{
+ BusClass *bc = BUS_CLASS(oc);
+ bc->device_type = TYPE_IPACK_DEVICE;
+}
+
static const TypeInfo ipack_bus_info = {
.name = TYPE_IPACK_BUS,
.parent = TYPE_BUS,
+ .class_init = ipack_bus_class_init,
.instance_size = sizeof(IPackBus),
};
diff --git a/hw/isa/isa-bus.c b/hw/isa/isa-bus.c
index 9d07b11..aad7669 100644
--- a/hw/isa/isa-bus.c
+++ b/hw/isa/isa-bus.c
@@ -36,6 +36,7 @@ static void isa_bus_class_init(ObjectClass *klass, void *data)
k->print_dev = isabus_dev_print;
k->get_fw_dev_path = isabus_get_fw_dev_path;
+ k->device_type = TYPE_ISA_DEVICE;
}
static const TypeInfo isa_dma_info = {
diff --git a/hw/misc/auxbus.c b/hw/misc/auxbus.c
index e4a7ba4..4b0d565 100644
--- a/hw/misc/auxbus.c
+++ b/hw/misc/auxbus.c
@@ -57,6 +57,7 @@ static void aux_bus_class_init(ObjectClass *klass, void *data)
* in monitor.
*/
k->print_dev = aux_slave_dev_print;
+ k->device_type = TYPE_AUX_SLAVE;
}
AUXBus *aux_init_bus(DeviceState *parent, const char *name)
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 24fae16..74b8fef 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -152,6 +152,7 @@ static void pci_bus_class_init(ObjectClass *klass, void *data)
k->realize = pci_bus_realize;
k->unrealize = pci_bus_unrealize;
k->reset = pcibus_reset;
+ k->device_type = TYPE_PCI_DEVICE;
pbc->is_root = pcibus_is_root;
pbc->bus_num = pcibus_num;
diff --git a/hw/ppc/spapr_vio.c b/hw/ppc/spapr_vio.c
index cc1e09c..c70b9b9 100644
--- a/hw/ppc/spapr_vio.c
+++ b/hw/ppc/spapr_vio.c
@@ -61,6 +61,7 @@ static void spapr_vio_bus_class_init(ObjectClass *klass, void *data)
k->get_dev_path = spapr_vio_get_dev_name;
k->get_fw_dev_path = spapr_vio_get_dev_name;
+ k->device_type = TYPE_VIO_SPAPR_DEVICE;
}
static const TypeInfo spapr_vio_bus_info = {
diff --git a/hw/s390x/css-bridge.c b/hw/s390x/css-bridge.c
index 9a7f7ee..8a6c1ae 100644
--- a/hw/s390x/css-bridge.c
+++ b/hw/s390x/css-bridge.c
@@ -17,6 +17,7 @@
#include "hw/s390x/css.h"
#include "ccw-device.h"
#include "hw/s390x/css-bridge.h"
+#include "hw/s390x/virtio-ccw.h"
/*
* Invoke device-specific unplug handler, disable the subchannel
@@ -81,6 +82,7 @@ static void virtual_css_bus_class_init(ObjectClass *klass, void *data)
k->reset = virtual_css_bus_reset;
k->get_dev_path = virtual_css_bus_get_dev_path;
+ k->device_type = TYPE_VIRTIO_CCW_DEVICE;
}
static const TypeInfo virtual_css_bus_info = {
diff --git a/hw/s390x/event-facility.c b/hw/s390x/event-facility.c
index 34b2faf..f2562ce 100644
--- a/hw/s390x/event-facility.c
+++ b/hw/s390x/event-facility.c
@@ -307,6 +307,7 @@ static void sclp_events_bus_class_init(ObjectClass *klass, void *data)
BusClass *bc = BUS_CLASS(klass);
bc->realize = sclp_events_bus_realize;
+ bc->device_type = TYPE_SCLP_EVENT;
}
static const TypeInfo sclp_events_bus_info = {
diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
index 63f6248..7470fdd 100644
--- a/hw/s390x/s390-pci-bus.c
+++ b/hw/s390x/s390-pci-bus.c
@@ -783,10 +783,17 @@ static const TypeInfo s390_pcihost_info = {
}
};
+static void s390_pcibus_class_init(ObjectClass *oc, void *opaque)
+{
+ BusClass *bc = BUS_CLASS(oc);
+ bc->device_type = TYPE_S390_PCI_DEVICE;
+}
+
static const TypeInfo s390_pcibus_info = {
.name = TYPE_S390_PCI_BUS,
.parent = TYPE_BUS,
.instance_size = sizeof(S390PCIBus),
+ .class_init = s390_pcibus_class_init,
};
static uint16_t s390_pci_generate_uid(void)
diff --git a/hw/scsi/scsi-bus.c b/hw/scsi/scsi-bus.c
index 297216d..9faf45f 100644
--- a/hw/scsi/scsi-bus.c
+++ b/hw/scsi/scsi-bus.c
@@ -31,6 +31,7 @@ static void scsi_bus_class_init(ObjectClass *klass, void *data)
k->get_dev_path = scsibus_get_dev_path;
k->get_fw_dev_path = scsibus_get_fw_dev_path;
+ k->device_type = TYPE_SCSI_DEVICE;
hc->unplug = qdev_simple_device_unplug_cb;
}
diff --git a/hw/sd/core.c b/hw/sd/core.c
index 14c2bdf..49b9f59 100644
--- a/hw/sd/core.c
+++ b/hw/sd/core.c
@@ -131,11 +131,18 @@ void sdbus_set_readonly(SDBus *sdbus, bool readonly)
}
}
+static void sd_bus_class_init(ObjectClass *oc, void *opaque)
+{
+ BusClass *bc = BUS_CLASS(oc);
+ bc->device_type = TYPE_SD_CARD;
+}
+
static const TypeInfo sd_bus_info = {
.name = TYPE_SD_BUS,
.parent = TYPE_BUS,
.instance_size = sizeof(SDBus),
.class_size = sizeof(SDBusClass),
+ .class_init = sd_bus_class_init,
};
static void sd_bus_register_types(void)
diff --git a/hw/ssi/ssi.c b/hw/ssi/ssi.c
index 7eaaf56..c48920d 100644
--- a/hw/ssi/ssi.c
+++ b/hw/ssi/ssi.c
@@ -22,10 +22,17 @@ struct SSIBus {
#define TYPE_SSI_BUS "SSI"
#define SSI_BUS(obj) OBJECT_CHECK(SSIBus, (obj), TYPE_SSI_BUS)
+static void ssi_bus_class_init(ObjectClass *oc, void *opaque)
+{
+ BusClass *bc = BUS_CLASS(oc);
+ bc->device_type = TYPE_SSI_SLAVE;
+}
+
static const TypeInfo ssi_bus_info = {
.name = TYPE_SSI_BUS,
.parent = TYPE_BUS,
.instance_size = sizeof(SSIBus),
+ .class_init = ssi_bus_class_init,
};
static void ssi_cs_default(void *opaque, int n, int level)
diff --git a/hw/usb/bus.c b/hw/usb/bus.c
index 25913ad..2cb7fa4 100644
--- a/hw/usb/bus.c
+++ b/hw/usb/bus.c
@@ -33,6 +33,7 @@ static void usb_bus_class_init(ObjectClass *klass, void *data)
k->print_dev = usb_bus_dev_print;
k->get_dev_path = usb_get_dev_path;
k->get_fw_dev_path = usb_get_fw_dev_path;
+ k->device_type = TYPE_USB_DEVICE;
hc->unplug = qdev_simple_device_unplug_cb;
}
diff --git a/hw/usb/dev-smartcard-reader.c b/hw/usb/dev-smartcard-reader.c
index 89e11b6..2721f0c 100644
--- a/hw/usb/dev-smartcard-reader.c
+++ b/hw/usb/dev-smartcard-reader.c
@@ -1180,10 +1180,17 @@ static Property ccid_props[] = {
#define TYPE_CCID_BUS "ccid-bus"
#define CCID_BUS(obj) OBJECT_CHECK(CCIDBus, (obj), TYPE_CCID_BUS)
+static void ccid_bus_class_init(ObjectClass *oc, void *opaque)
+{
+ BusClass *bc = BUS_CLASS(oc);
+ bc->device_type = TYPE_CCID_CARD;
+}
+
static const TypeInfo ccid_bus_info = {
.name = TYPE_CCID_BUS,
.parent = TYPE_BUS,
.instance_size = sizeof(CCIDBus),
+ .class_init = ccid_bus_class_init,
};
void ccid_card_send_apdu_to_guest(CCIDCardState *card,
diff --git a/hw/virtio/virtio-bus.c b/hw/virtio/virtio-bus.c
index d6c0c72..815f3dd 100644
--- a/hw/virtio/virtio-bus.c
+++ b/hw/virtio/virtio-bus.c
@@ -293,6 +293,7 @@ static void virtio_bus_class_init(ObjectClass *klass, void *data)
BusClass *bus_class = BUS_CLASS(klass);
bus_class->get_dev_path = virtio_bus_get_dev_path;
bus_class->get_fw_dev_path = virtio_bus_get_fw_dev_path;
+ bus_class->device_type = TYPE_VIRTIO_DEVICE;
}
static const TypeInfo virtio_bus_info = {
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index 2c97347..7c34f14 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -207,6 +207,8 @@ struct BusClass {
int max_dev;
/* number of automatically allocated bus ids (e.g. ide.0) */
int automatic_ids;
+ /* type or interface name devices should implement */
+ const char *device_type;
};
typedef struct BusChild {
--
2.7.4
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Qemu-devel] [RFC 07/15] machine: Add MachineClass::default_buses field
2016-11-22 1:11 [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Eduardo Habkost
` (5 preceding siblings ...)
2016-11-22 1:12 ` [Qemu-devel] [RFC 06/15] qdev: Add device_type field to BusClass Eduardo Habkost
@ 2016-11-22 1:12 ` Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 08/15] qmp: Add 'supported-device-types' field to 'query-machines' Eduardo Habkost
` (12 subsequent siblings)
19 siblings, 0 replies; 43+ messages in thread
From: Eduardo Habkost @ 2016-11-22 1:12 UTC (permalink / raw)
To: qemu-devel, Markus Armbruster, Marcel Apfelbaum, Michael S. Tsirkin
The new field can be populated by class_init functions with the
list of bus types that are created by default when the machine is
initialized. It will be used to build the device type
compatibility list on 'query-machines' output.
As a TYPE_SYSTEM_BUS bus is always created, add it to the default
list on TYPE_MACHINE.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
hw/core/machine.c | 18 +++++++++++++++++-
include/hw/boards.h | 5 +++++
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/hw/core/machine.c b/hw/core/machine.c
index b0fd91f..8d55c1a 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -357,6 +357,13 @@ static void machine_init_notify(Notifier *notifier, void *data)
foreach_dynamic_sysbus_device(error_on_sysbus_device, NULL);
}
+void machine_class_add_default_bus(MachineClass *mc, const char *typename)
+{
+ mc->default_buses =
+ g_list_append(mc->default_buses, g_strdup(typename));
+
+}
+
static void machine_class_init(ObjectClass *oc, void *data)
{
MachineClass *mc = MACHINE_CLASS(oc);
@@ -365,6 +372,8 @@ static void machine_class_init(ObjectClass *oc, void *data)
mc->default_ram_size = 128 * M_BYTE;
mc->rom_file_has_mr = true;
+ machine_class_add_default_bus(mc, TYPE_SYSTEM_BUS);
+
object_class_property_add_str(oc, "accel",
machine_get_accel, machine_set_accel, &error_abort);
object_class_property_set_description(oc, "accel",
@@ -466,13 +475,20 @@ static void machine_class_init(ObjectClass *oc, void *data)
static void machine_class_base_init(ObjectClass *oc, void *data)
{
+ MachineClass *mc = MACHINE_CLASS(oc);
+
if (!object_class_is_abstract(oc)) {
- MachineClass *mc = MACHINE_CLASS(oc);
const char *cname = object_class_get_name(oc);
assert(g_str_has_suffix(cname, TYPE_MACHINE_SUFFIX));
mc->name = g_strndup(cname,
strlen(cname) - strlen(TYPE_MACHINE_SUFFIX));
}
+
+ /*FIXME: this should be g_list_copy_deep(), but it requires
+ * a more recent GLib version. Should be replaced with something
+ * equivalent.
+ */
+ mc->default_buses = g_list_copy(mc->default_buses);
}
static void machine_initfn(Object *obj)
diff --git a/include/hw/boards.h b/include/hw/boards.h
index a51da9c..78348ff 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -42,6 +42,8 @@ bool machine_dump_guest_core(MachineState *machine);
bool machine_mem_merge(MachineState *machine);
void machine_register_compat_props(MachineState *machine);
+void machine_class_add_default_bus(MachineClass *mc, const char *typename);
+
/**
* CPUArchId:
* @arch_id - architecture-dependent CPU ID of present or possible CPU
@@ -92,6 +94,8 @@ typedef struct {
* size than the target architecture's minimum. (Attempting to create
* such a CPU will fail.) Note that changing this is a migration
* compatibility break for the machine.
+ * @default_buses:
+ * List of typenames of buses that are created by default by the machine.
*/
struct MachineClass {
/*< private >*/
@@ -131,6 +135,7 @@ struct MachineClass {
bool option_rom_has_mr;
bool rom_file_has_mr;
int minimum_page_bits;
+ GList *default_buses;
HotplugHandler *(*get_hotplug_handler)(MachineState *machine,
DeviceState *dev);
--
2.7.4
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Qemu-devel] [RFC 08/15] qmp: Add 'supported-device-types' field to 'query-machines'
2016-11-22 1:11 [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Eduardo Habkost
` (6 preceding siblings ...)
2016-11-22 1:12 ` [Qemu-devel] [RFC 07/15] machine: Add MachineClass::default_buses field Eduardo Habkost
@ 2016-11-22 1:12 ` Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 09/15] pci: Introduce INTERFACE_PCIE_DEVICE interface name Eduardo Habkost
` (11 subsequent siblings)
19 siblings, 0 replies; 43+ messages in thread
From: Eduardo Habkost @ 2016-11-22 1:12 UTC (permalink / raw)
To: qemu-devel, Markus Armbruster, Marcel Apfelbaum, Michael S. Tsirkin
Cc: libvir-list, Laine Stump
The new field will return a list of device type names that are
compatible with the default bus configuration of the
machine-type. The list can be easily built using the
MachineClass::default_bus_types and
BusClass::supported_device_type fields.
The returned types can be used as the 'implements' parameter to
'qom-list-types', to find the list of devices that can be plugged
on the machine.
Note that some machine options may enable or disable some bus
types and affect the set of compatible device types.
Introspection of those options is out of the scope of this patch.
Includes a qtest test case that will validate the returned by
actually running each machine-type and checking the list of
available buses.
Cc: libvir-list@redhat.com
Cc: Laine Stump <laine@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
qapi-schema.json | 9 ++-
tests/Makefile.include | 2 +
tests/qmp-machine-info.py | 138 ++++++++++++++++++++++++++++++++++++++++++++++
vl.c | 11 ++++
4 files changed, 159 insertions(+), 1 deletion(-)
create mode 100755 tests/qmp-machine-info.py
diff --git a/qapi-schema.json b/qapi-schema.json
index f3e9bfc..6db397d 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -3178,12 +3178,19 @@
#
# @hotpluggable-cpus: cpu hotplug via -device is supported (since 2.7.0)
#
+# @supported-device-types: List of QOM type names of devices that
+# can be plugged on the machine by default.
+# Note that some machine options may enable
+# or disable some bus types and affect the
+# set of compatible device types. (since 2.9)
+#
# Since: 1.2.0
##
{ 'struct': 'MachineInfo',
'data': { 'name': 'str', '*alias': 'str',
'*is-default': 'bool', 'cpu-max': 'int',
- 'hotpluggable-cpus': 'bool'} }
+ 'hotpluggable-cpus': 'bool',
+ 'supported-device-types': [ 'str' ] } }
##
# @query-machines:
diff --git a/tests/Makefile.include b/tests/Makefile.include
index eb1031b..7016737 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -315,6 +315,8 @@ check-qtest-s390x-y = tests/boot-serial-test$(EXESUF)
check-qtest-generic-y += tests/qom-test$(EXESUF)
+check-simpleqtest-generic-y += $(SRC_PATH)/tests/qmp-machine-info.py
+
qapi-schema += alternate-any.json
qapi-schema += alternate-array.json
qapi-schema += alternate-base.json
diff --git a/tests/qmp-machine-info.py b/tests/qmp-machine-info.py
new file mode 100755
index 0000000..5258434
--- /dev/null
+++ b/tests/qmp-machine-info.py
@@ -0,0 +1,138 @@
+#!/usr/bin/env python
+import sys, os
+sys.path.append(os.path.join(os.path.dirname(__file__), '..', 'scripts'))
+import qtest
+import unittest
+import logging
+import argparse
+
+logger = logging.getLogger('qemu.tests.machineinfo')
+
+# machines that we can't easily test because they can't run on all hosts:
+BLACKLIST = set(['xenpv', 'xenfv'])
+
+# architectures where machines are expected to report all available buses:
+STRICT_ARCHES = set()
+
+class QueryMachinesTest(unittest.TestCase):
+ def walkQOMTree(self, vm, path):
+ """Walk QOM tree recusrively, starting at path"""
+ children = vm.qmp('qom-list', path=path)['return']
+ for c in children:
+ logging.debug('walking %s. child: %s', path, c)
+ if not c['type'].startswith('child<'):
+ continue
+
+ cp = '%s/%s' % (path, c['name'])
+ yield cp
+
+ for gc in self.walkQOMTree(vm, cp):
+ yield gc
+
+ def findAllBuses(self, vm):
+ """Find all bus objects in the QOM tree"""
+ r = vm.qmp('qom-list-types', implements='bus')
+ bus_types = set([b['name'] for b in r['return']])
+ for cp in self.walkQOMTree(vm, '/machine'):
+ t = vm.qmp('qom-get', path=cp, property='type')['return']
+ if t in bus_types:
+ dt = vm.qmp('qom-get', path=cp, property='device-type')['return']
+ yield dict(path=cp, type=t, device_type=dt)
+
+ def validateSupportedDeviceTypes(self, machine):
+ """Validate 'supported-device-types' on 'query-machines'"""
+ if machine['name'] in BLACKLIST:
+ return
+
+ vm = qtest.QEMUQtestMachine(args=['-S', '-machine', machine['name']], logging=False)
+ vm.launch()
+ try:
+ buses = list(self.findAllBuses(vm))
+ bus_types = set([b['type'] for b in buses])
+ device_types = set([b['device_type'] for b in buses])
+ logger.debug("buses for machine %s: %s", machine['name'],
+ ' '.join(bus_types))
+ logger.debug("device-type for machine %s: %s", machine['name'],
+ ' '.join(device_types))
+ reported_types = set(machine['supported-device-types'])
+ extra_types = reported_types.difference(device_types)
+ missing_types = device_types.difference(reported_types)
+ # the machine MUST NOT report any types if the bus is not available
+ # by default (in other words, extra_types should be empty)
+ self.assertEquals(extra_types, set())
+ # missing_types, on the other hand, may be empty. sometimes
+ # a bus is available but the machine doesn't report it yet
+ if missing_types:
+ logger.info("extra device types present on machine %s: %s",
+ machine['name'], ' '.join(missing_types))
+ if vm.qmp('query-target')['return']['arch'] in STRICT_ARCHES:
+ self.fail("extra device types: %s" % (' '.join(missing_types)))
+ finally:
+ vm.shutdown()
+
+ @classmethod
+ def addMachineTest(klass, method, machine):
+ """Dynamically add a testMachine_<name>_<machine> method to the class"""
+ def testMachine(self):
+ return method(self, machine)
+ machine_name = machine['name'].replace('-', '_').replace('.', '_')
+ method_name = 'testMachine_%s_%s' % (method.__name__, machine_name)
+ setattr(klass, method_name, testMachine)
+
+ @classmethod
+ def discoverMachines(klass):
+ """Run query-machines
+
+ This method is run before test cases are started, so we
+ can dynamically add test cases for each machine supported
+ by the binary.
+ """
+ vm = qtest.QEMUQtestMachine(args=['-S', '-machine', 'none'], logging=False)
+ vm.launch()
+ try:
+ machines = vm.qmp('query-machines')['return']
+ finally:
+ vm.shutdown()
+ return machines
+
+ @classmethod
+ def addMachineTestCases(klass):
+ """Dynamically add test methods for each machine-type"""
+ machines = klass.discoverMachines()
+ for m in machines:
+ klass.addMachineTest(klass.validateSupportedDeviceTypes, m)
+
+def load_tests(loader, tests=None, pattern=None):
+ QueryMachinesTest.addMachineTestCases()
+ ts = unittest.TestSuite()
+ tests = loader.loadTestsFromTestCase(QueryMachinesTest)
+ ts.addTests(tests)
+ return ts
+
+def main(argv):
+ # we don't use unittest.main() because:
+ # 1) it doesn't configure logging level
+ # 2) it doesn't let us disable all output
+ parser = argparse.ArgumentParser()
+ parser.add_argument('--verbosity', help='Set verbosity',
+ default=1, type=int)
+ parser.add_argument('--quiet', '-q', help='Run tests quietly',
+ action='store_const', dest='verbosity', const=0)
+ parser.add_argument('--verbose', '-v', help='Run tests verbosely',
+ action='store_const', dest='verbosity', const=2)
+ parser.add_argument('--debug', '-d', help='Debug output',
+ action='store_const', dest='verbosity', const=4)
+ args = parser.parse_args(argv[1:])
+ if args.verbosity == 0:
+ output = open('/dev/null', 'w')
+ else:
+ output = sys.stderr
+ if args.verbosity >= 4:
+ logging.basicConfig(level=logging.DEBUG)
+ elif args.verbosity >= 2:
+ logging.basicConfig(level=logging.INFO)
+ tests = load_tests(unittest.TestLoader(), None, None)
+ unittest.TextTestRunner(stream=output, verbosity=args.verbosity).run(tests)
+
+if __name__ == '__main__':
+ main(sys.argv)
diff --git a/vl.c b/vl.c
index d77dd86..af862db 100644
--- a/vl.c
+++ b/vl.c
@@ -1541,6 +1541,8 @@ MachineInfoList *qmp_query_machines(Error **errp)
MachineClass *mc = el->data;
MachineInfoList *entry;
MachineInfo *info;
+ GList *bus;
+ strList **next_dev;
info = g_malloc0(sizeof(*info));
if (mc->is_default) {
@@ -1557,6 +1559,15 @@ MachineInfoList *qmp_query_machines(Error **errp)
info->cpu_max = !mc->max_cpus ? 1 : mc->max_cpus;
info->hotpluggable_cpus = !!mc->query_hotpluggable_cpus;
+ next_dev = &info->supported_device_types;
+ for (bus = mc->default_buses; bus; bus = bus->next) {
+ BusClass *bc = BUS_CLASS(object_class_by_name(bus->data));
+ strList *new = g_new0(strList, 1);
+ new->value = g_strdup(bc->device_type);
+ *next_dev = new;
+ next_dev = &new->next;
+ }
+
entry = g_malloc0(sizeof(*entry));
entry->value = info;
entry->next = mach_list;
--
2.7.4
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Qemu-devel] [RFC 09/15] pci: Introduce INTERFACE_PCIE_DEVICE interface name
2016-11-22 1:11 [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Eduardo Habkost
` (7 preceding siblings ...)
2016-11-22 1:12 ` [Qemu-devel] [RFC 08/15] qmp: Add 'supported-device-types' field to 'query-machines' Eduardo Habkost
@ 2016-11-22 1:12 ` Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 10/15] pc: Initialize default bus lists Eduardo Habkost
` (10 subsequent siblings)
19 siblings, 0 replies; 43+ messages in thread
From: Eduardo Habkost @ 2016-11-22 1:12 UTC (permalink / raw)
To: qemu-devel, Markus Armbruster, Marcel Apfelbaum, Michael S. Tsirkin
The new interface name will be used by TYPE_PCIE_BUS to allow
only PCIe devices to be plugged, by setting
BusClass::supported_device_type = INTERFACE_PCIE_DEVICE.
This patch changes all devices that set is_express=1 or set
QEMU_PCI_CAP_EXPRESS directly to implement INTERFACE_PCIE_DEVICE.
There are two issues I still want to fix in this patch:
* Duplication between PCIDeviceClass::is_express and
INTERFACE_PCIE_DEVICE. There are two ways of encoding info
about a device class supporting PCIe:
PCIDeviceClass::is_express, and INTERFACE_PCIE_DEVICE. This
duplication needs to be eliminated.
* Differentiating PCIe-only and hybrid devices. There's no
obvious way to indicate that a device is supposed to be plugged
on PCIe buses only. PCIDeviceClass::is_express and
INTERFACE_PCIE_DEVICE only indicate PCIe is supported, but
doesn't say anything about legacy PCI being (un)supported. Some
PCIe device classes also support legacy PCI, and some don't.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
hw/block/nvme.c | 4 ++++
hw/net/e1000e.c | 4 ++++
hw/net/vmxnet3.c | 4 ++++
hw/pci-bridge/ioh3420.c | 4 ++++
hw/pci-bridge/xio3130_downstream.c | 4 ++++
hw/pci/pci.c | 13 +++++++++++++
hw/scsi/megasas.c | 7 +++++++
hw/scsi/vmw_pvscsi.c | 1 +
hw/usb/hcd-xhci.c | 4 ++++
hw/vfio/pci.c | 4 ++++
hw/virtio/virtio-pci.c | 4 ++++
include/hw/pci/pci.h | 3 +++
12 files changed, 56 insertions(+)
diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index d479fd2..694e31c 100644
--- a/hw/block/nvme.c
+++ b/hw/block/nvme.c
@@ -980,6 +980,10 @@ static const TypeInfo nvme_info = {
.instance_size = sizeof(NvmeCtrl),
.class_init = nvme_class_init,
.instance_init = nvme_instance_init,
+ .interfaces = (InterfaceInfo[]) {
+ { INTERFACE_PCIE_DEVICE },
+ { }
+ },
};
static void nvme_register_types(void)
diff --git a/hw/net/e1000e.c b/hw/net/e1000e.c
index 4994e1c..59cec01 100644
--- a/hw/net/e1000e.c
+++ b/hw/net/e1000e.c
@@ -701,6 +701,10 @@ static const TypeInfo e1000e_info = {
.instance_size = sizeof(E1000EState),
.class_init = e1000e_class_init,
.instance_init = e1000e_instance_init,
+ .interfaces = (InterfaceInfo[]) {
+ { INTERFACE_PCIE_DEVICE },
+ { }
+ },
};
static void e1000e_register_types(void)
diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c
index 92f6af9..856a51e 100644
--- a/hw/net/vmxnet3.c
+++ b/hw/net/vmxnet3.c
@@ -2726,6 +2726,10 @@ static const TypeInfo vmxnet3_info = {
.instance_size = sizeof(VMXNET3State),
.class_init = vmxnet3_class_init,
.instance_init = vmxnet3_instance_init,
+ .interfaces = (InterfaceInfo[]) {
+ { INTERFACE_PCIE_DEVICE },
+ { }
+ },
};
static void vmxnet3_register_types(void)
diff --git a/hw/pci-bridge/ioh3420.c b/hw/pci-bridge/ioh3420.c
index c8b5ac4..a7320a4 100644
--- a/hw/pci-bridge/ioh3420.c
+++ b/hw/pci-bridge/ioh3420.c
@@ -209,6 +209,10 @@ static const TypeInfo ioh3420_info = {
.name = "ioh3420",
.parent = TYPE_PCIE_SLOT,
.class_init = ioh3420_class_init,
+ .interfaces = (InterfaceInfo[]) {
+ { INTERFACE_PCIE_DEVICE },
+ { }
+ },
};
static void ioh3420_register_types(void)
diff --git a/hw/pci-bridge/xio3130_downstream.c b/hw/pci-bridge/xio3130_downstream.c
index cef6e13..32b1785 100644
--- a/hw/pci-bridge/xio3130_downstream.c
+++ b/hw/pci-bridge/xio3130_downstream.c
@@ -195,6 +195,10 @@ static const TypeInfo xio3130_downstream_info = {
.name = "xio3130-downstream",
.parent = TYPE_PCIE_SLOT,
.class_init = xio3130_downstream_class_init,
+ .interfaces = (InterfaceInfo[]) {
+ { INTERFACE_PCIE_DEVICE },
+ { }
+ },
};
static void xio3130_downstream_register_types(void)
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 74b8fef..1b0b7d3 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -167,8 +167,20 @@ static const TypeInfo pci_bus_info = {
.class_init = pci_bus_class_init,
};
+static const TypeInfo pcie_interface_info = {
+ .name = INTERFACE_PCIE_DEVICE,
+ .parent = TYPE_INTERFACE,
+};
+
+static void pcie_bus_class_init(ObjectClass *oc, void *opaque)
+{
+ BusClass *bc = BUS_CLASS(oc);
+ bc->device_type = INTERFACE_PCIE_DEVICE;
+}
+
static const TypeInfo pcie_bus_info = {
.name = TYPE_PCIE_BUS,
+ .class_init = pcie_bus_class_init,
.parent = TYPE_PCI_BUS,
};
@@ -2627,6 +2639,7 @@ static void pci_register_types(void)
{
type_register_static(&pci_bus_info);
type_register_static(&pcie_bus_info);
+ type_register_static(&pcie_interface_info);
type_register_static(&pci_device_type_info);
}
diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
index 52a4123..80ca8aa 100644
--- a/hw/scsi/megasas.c
+++ b/hw/scsi/megasas.c
@@ -2538,11 +2538,18 @@ static void megasas_register_types(void)
for (i = 0; i < ARRAY_SIZE(megasas_devices); i++) {
const MegasasInfo *info = &megasas_devices[i];
TypeInfo type_info = {};
+ InterfaceInfo pcie_interfaces[] = {
+ { INTERFACE_PCIE_DEVICE },
+ { },
+ };
type_info.name = info->name;
type_info.parent = TYPE_MEGASAS_BASE;
type_info.class_data = (void *)info;
type_info.class_init = megasas_class_init;
+ if (info->is_express) {
+ type_info.interfaces = pcie_interfaces;
+ }
type_register(&type_info);
}
diff --git a/hw/scsi/vmw_pvscsi.c b/hw/scsi/vmw_pvscsi.c
index a5ce7de..9afb689 100644
--- a/hw/scsi/vmw_pvscsi.c
+++ b/hw/scsi/vmw_pvscsi.c
@@ -1306,6 +1306,7 @@ static const TypeInfo pvscsi_info = {
.class_init = pvscsi_class_init,
.interfaces = (InterfaceInfo[]) {
{ TYPE_HOTPLUG_HANDLER },
+ { INTERFACE_PCIE_DEVICE },
{ }
}
};
diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c
index 4acf0c6..cbed4b1 100644
--- a/hw/usb/hcd-xhci.c
+++ b/hw/usb/hcd-xhci.c
@@ -3962,6 +3962,10 @@ static const TypeInfo xhci_info = {
.parent = TYPE_PCI_DEVICE,
.instance_size = sizeof(XHCIState),
.class_init = xhci_class_init,
+ .interfaces = (InterfaceInfo[]) {
+ { INTERFACE_PCIE_DEVICE },
+ { }
+ },
};
static void xhci_register_types(void)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index d7dbe0e..81d9d1c 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -2983,6 +2983,10 @@ static const TypeInfo vfio_pci_dev_info = {
.class_init = vfio_pci_dev_class_init,
.instance_init = vfio_instance_init,
.instance_finalize = vfio_instance_finalize,
+ .interfaces = (InterfaceInfo[]) {
+ { INTERFACE_PCIE_DEVICE },
+ { }
+ },
};
static void register_vfio_pci_dev_type(void)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 521ba0b..9413066 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1893,6 +1893,10 @@ static const TypeInfo virtio_pci_info = {
.class_init = virtio_pci_class_init,
.class_size = sizeof(VirtioPCIClass),
.abstract = true,
+ .interfaces = (InterfaceInfo[]) {
+ { INTERFACE_PCIE_DEVICE },
+ { }
+ },
};
/* virtio-blk-pci */
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index 772692f..e88eb78 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -386,6 +386,9 @@ typedef PCIINTxRoute (*pci_route_irq_fn)(void *opaque, int pin);
#define PCI_BUS_GET_CLASS(obj) OBJECT_GET_CLASS(PCIBusClass, (obj), TYPE_PCI_BUS)
#define TYPE_PCIE_BUS "PCIE"
+/* Interface implemented by devices that can be plugged on PCIE buses */
+#define INTERFACE_PCIE_DEVICE "PCIE-device"
+
bool pci_bus_is_express(PCIBus *bus);
bool pci_bus_is_root(PCIBus *bus);
void pci_bus_new_inplace(PCIBus *bus, size_t bus_size, DeviceState *parent,
--
2.7.4
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Qemu-devel] [RFC 10/15] pc: Initialize default bus lists
2016-11-22 1:11 [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Eduardo Habkost
` (8 preceding siblings ...)
2016-11-22 1:12 ` [Qemu-devel] [RFC 09/15] pci: Introduce INTERFACE_PCIE_DEVICE interface name Eduardo Habkost
@ 2016-11-22 1:12 ` Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 11/15] s390x: " Eduardo Habkost
` (9 subsequent siblings)
19 siblings, 0 replies; 43+ messages in thread
From: Eduardo Habkost @ 2016-11-22 1:12 UTC (permalink / raw)
To: qemu-devel, Markus Armbruster, Marcel Apfelbaum, Michael S. Tsirkin
Populate the default_bus_types list for the PC machines. This
will allow qmp-machine-info.py to run in strict mode for x86.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
hw/i386/pc_piix.c | 13 +++++++++++++
hw/i386/pc_q35.c | 4 ++++
tests/qmp-machine-info.py | 2 +-
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index a54a468..055f46a 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -435,6 +435,11 @@ static void pc_i440fx_machine_options(MachineClass *m)
m->hot_add_cpu = pc_hot_add_cpu;
m->default_machine_opts = "firmware=bios-256k.bin";
m->default_display = "std";
+ machine_class_add_default_bus(m, "floppy-bus"); //FIXME: use macro
+ machine_class_add_default_bus(m, "i2c-bus"); //FIXME: use macro
+ machine_class_add_default_bus(m, TYPE_PCI_BUS);
+ machine_class_add_default_bus(m, TYPE_ISA_BUS);
+ machine_class_add_default_bus(m, "IDE");//FIXME: use macro
}
static void pc_i440fx_2_8_machine_options(MachineClass *m)
@@ -1079,6 +1084,9 @@ static void isapc_machine_options(MachineClass *m)
m->max_cpus = 1;
m->option_rom_has_mr = true;
m->rom_file_has_mr = false;
+ machine_class_add_default_bus(m, "floppy-bus"); //FIXME: use macro
+ machine_class_add_default_bus(m, TYPE_ISA_BUS);
+ machine_class_add_default_bus(m, "IDE");//FIXME: use macro
pcmc->pci_enabled = false;
pcmc->has_acpi_build = false;
pcmc->smbios_defaults = false;
@@ -1098,6 +1106,11 @@ static void xenfv_machine_options(MachineClass *m)
m->max_cpus = HVM_MAX_VCPUS;
m->default_machine_opts = "accel=xen";
m->hot_add_cpu = pc_hot_add_cpu;
+ machine_class_add_default_bus(m, "floppy-bus"); //FIXME: use macro
+ machine_class_add_default_bus(m, "i2c-bus"); //FIXME: use macro
+ machine_class_add_default_bus(m, TYPE_PCI_BUS);
+ machine_class_add_default_bus(m, TYPE_ISA_BUS);
+ machine_class_add_default_bus(m, "IDE");//FIXME: use macro
}
DEFINE_PC_MACHINE(xenfv, "xenfv", pc_xen_hvm_init,
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index b40d19e..4602852 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -292,6 +292,10 @@ static void pc_q35_machine_options(MachineClass *m)
m->no_floppy = 1;
m->has_dynamic_sysbus = true;
m->max_cpus = 288;
+ machine_class_add_default_bus(m, "i2c-bus"); //FIXME: use macro
+ machine_class_add_default_bus(m, TYPE_PCIE_BUS);
+ machine_class_add_default_bus(m, TYPE_ISA_BUS);
+ machine_class_add_default_bus(m, "IDE");//FIXME: use macro
}
static void pc_q35_2_8_machine_options(MachineClass *m)
diff --git a/tests/qmp-machine-info.py b/tests/qmp-machine-info.py
index 5258434..a43cd1b 100755
--- a/tests/qmp-machine-info.py
+++ b/tests/qmp-machine-info.py
@@ -12,7 +12,7 @@ logger = logging.getLogger('qemu.tests.machineinfo')
BLACKLIST = set(['xenpv', 'xenfv'])
# architectures where machines are expected to report all available buses:
-STRICT_ARCHES = set()
+STRICT_ARCHES = set(['x86_64', 'i386'])
class QueryMachinesTest(unittest.TestCase):
def walkQOMTree(self, vm, path):
--
2.7.4
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Qemu-devel] [RFC 11/15] s390x: Initialize default bus lists
2016-11-22 1:11 [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Eduardo Habkost
` (9 preceding siblings ...)
2016-11-22 1:12 ` [Qemu-devel] [RFC 10/15] pc: Initialize default bus lists Eduardo Habkost
@ 2016-11-22 1:12 ` Eduardo Habkost
2016-12-05 15:24 ` David Hildenbrand
2016-11-22 1:12 ` [Qemu-devel] [RFC 12/15] arm: " Eduardo Habkost
` (8 subsequent siblings)
19 siblings, 1 reply; 43+ messages in thread
From: Eduardo Habkost @ 2016-11-22 1:12 UTC (permalink / raw)
To: qemu-devel, Markus Armbruster, Marcel Apfelbaum, Michael S. Tsirkin
Populate the default_bus_types list for the s390x machines. This
will allow qmp-machine-info.py to run in strict mode for s390x.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
hw/s390x/s390-virtio-ccw.c | 6 ++++++
tests/qmp-machine-info.py | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index e340eab..2532fcb 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -206,6 +206,12 @@ static void ccw_machine_class_init(ObjectClass *oc, void *data)
mc->use_sclp = 1;
mc->max_cpus = 248;
mc->get_hotplug_handler = s390_get_hotplug_handler;
+ machine_class_add_default_bus(mc, TYPE_VIRTUAL_CSS_BUS);
+ machine_class_add_default_bus(mc, TYPE_PCI_BUS);
+ machine_class_add_default_bus(mc, TYPE_S390_PCI_BUS);
+ machine_class_add_default_bus(mc, "s390-sclp-events-bus");
+ machine_class_add_default_bus(mc, TYPE_VIRTIO_BUS);
+
hc->plug = s390_machine_device_plug;
nc->nmi_monitor_handler = s390_nmi;
}
diff --git a/tests/qmp-machine-info.py b/tests/qmp-machine-info.py
index a43cd1b..e6a6b76 100755
--- a/tests/qmp-machine-info.py
+++ b/tests/qmp-machine-info.py
@@ -12,7 +12,7 @@ logger = logging.getLogger('qemu.tests.machineinfo')
BLACKLIST = set(['xenpv', 'xenfv'])
# architectures where machines are expected to report all available buses:
-STRICT_ARCHES = set(['x86_64', 'i386'])
+STRICT_ARCHES = set(['x86_64', 'i386', 's390x'])
class QueryMachinesTest(unittest.TestCase):
def walkQOMTree(self, vm, path):
--
2.7.4
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Qemu-devel] [RFC 12/15] arm: Initialize default bus lists
2016-11-22 1:11 [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Eduardo Habkost
` (10 preceding siblings ...)
2016-11-22 1:12 ` [Qemu-devel] [RFC 11/15] s390x: " Eduardo Habkost
@ 2016-11-22 1:12 ` Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 13/15] mips: " Eduardo Habkost
` (7 subsequent siblings)
19 siblings, 0 replies; 43+ messages in thread
From: Eduardo Habkost @ 2016-11-22 1:12 UTC (permalink / raw)
To: qemu-devel, Markus Armbruster, Marcel Apfelbaum, Michael S. Tsirkin
Cc: Peter Maydell, Beniamino Galvani, Igor Mitsyanko, Rob Herring,
Peter Chubb, Jan Kiszka, Andrzej Zaborowski, qemu-arm
Populate default_bus_types for some machines. Work in progress, I
didn't check if all machines were converted (so we could enable
strict mode for arm in qmp-machine-info.py).
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Beniamino Galvani <b.galvani@gmail.com>
Cc: Igor Mitsyanko <i.mitsyanko@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Peter Chubb <peter.chubb@nicta.com.au>
Cc: Jan Kiszka <jan.kiszka@web.de>
Cc: Andrzej Zaborowski <balrogg@gmail.com>
Cc: qemu-arm@nongnu.org
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
hw/arm/aspeed.c | 2 ++
hw/arm/collie.c | 1 +
hw/arm/cubieboard.c | 1 +
hw/arm/exynos4_boards.c | 5 +++++
hw/arm/gumstix.c | 7 +++++++
hw/arm/highbank.c | 4 ++++
hw/arm/imx25_pdk.c | 1 +
hw/arm/kzm.c | 1 +
hw/arm/musicpal.c | 1 +
hw/arm/nseries.c | 2 ++
hw/arm/palm.c | 1 +
hw/arm/realview.c | 1 +
hw/arm/spitz.c | 10 ++++++++++
hw/arm/stellaris.c | 4 ++++
14 files changed, 41 insertions(+)
diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index c7206fd..042f2d0 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -180,6 +180,8 @@ static void ast2500_evb_class_init(ObjectClass *oc, void *data)
mc->no_floppy = 1;
mc->no_cdrom = 1;
mc->no_parallel = 1;
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
+ machine_class_add_default_bus(mc, "SSI");//FIXME: use macro
}
static const TypeInfo ast2500_evb_type = {
diff --git a/hw/arm/collie.c b/hw/arm/collie.c
index 2e69531..049be5d 100644
--- a/hw/arm/collie.c
+++ b/hw/arm/collie.c
@@ -64,6 +64,7 @@ static void collie_machine_init(MachineClass *mc)
{
mc->desc = "Sharp SL-5500 (Collie) PDA (SA-1110)";
mc->init = collie_init;
+ machine_class_add_default_bus(mc, "SSI");//FIXME: use macro
}
DEFINE_MACHINE("collie", collie_machine_init)
diff --git a/hw/arm/cubieboard.c b/hw/arm/cubieboard.c
index dd19ba3..7f3841d 100644
--- a/hw/arm/cubieboard.c
+++ b/hw/arm/cubieboard.c
@@ -82,6 +82,7 @@ static void cubieboard_machine_init(MachineClass *mc)
{
mc->desc = "cubietech cubieboard";
mc->init = cubieboard_init;
+ machine_class_add_default_bus(mc, TYPE_IDE_BUS);//FIXME: use macro
}
DEFINE_MACHINE("cubieboard", cubieboard_machine_init)
diff --git a/hw/arm/exynos4_boards.c b/hw/arm/exynos4_boards.c
index 0efa194..321895d 100644
--- a/hw/arm/exynos4_boards.c
+++ b/hw/arm/exynos4_boards.c
@@ -32,6 +32,7 @@
#include "exec/address-spaces.h"
#include "hw/arm/exynos4210.h"
#include "hw/boards.h"
+#include "hw/usb.h"
#undef DEBUG
@@ -154,6 +155,8 @@ static void nuri_class_init(ObjectClass *oc, void *data)
mc->desc = "Samsung NURI board (Exynos4210)";
mc->init = nuri_init;
mc->max_cpus = EXYNOS4210_NCPUS;
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
+ machine_class_add_default_bus(mc, TYPE_USB_BUS);
}
static const TypeInfo nuri_type = {
@@ -169,6 +172,8 @@ static void smdkc210_class_init(ObjectClass *oc, void *data)
mc->desc = "Samsung SMDKC210 board (Exynos4210)";
mc->init = smdkc210_init;
mc->max_cpus = EXYNOS4210_NCPUS;
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
+ machine_class_add_default_bus(mc, TYPE_USB_BUS);
}
static const TypeInfo smdkc210_type = {
diff --git a/hw/arm/gumstix.c b/hw/arm/gumstix.c
index d59d9ba..9e07d75 100644
--- a/hw/arm/gumstix.c
+++ b/hw/arm/gumstix.c
@@ -41,6 +41,7 @@
#include "hw/block/flash.h"
#include "hw/devices.h"
#include "hw/boards.h"
+#include "hw/usb.h"
#include "sysemu/block-backend.h"
#include "exec/address-spaces.h"
#include "sysemu/qtest.h"
@@ -128,6 +129,9 @@ static void connex_class_init(ObjectClass *oc, void *data)
mc->desc = "Gumstix Connex (PXA255)";
mc->init = connex_init;
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
+ machine_class_add_default_bus(mc, TYPE_USB_BUS);
+ machine_class_add_default_bus(mc, "SSI");//FIXME: use macro
}
static const TypeInfo connex_type = {
@@ -142,6 +146,9 @@ static void verdex_class_init(ObjectClass *oc, void *data)
mc->desc = "Gumstix Verdex (PXA270)";
mc->init = verdex_init;
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
+ machine_class_add_default_bus(mc, TYPE_USB_BUS);
+ machine_class_add_default_bus(mc, "SSI");//FIXME: use macro
}
static const TypeInfo verdex_type = {
diff --git a/hw/arm/highbank.c b/hw/arm/highbank.c
index 80e5fd4..30ce089 100644
--- a/hw/arm/highbank.c
+++ b/hw/arm/highbank.c
@@ -407,6 +407,8 @@ static void highbank_class_init(ObjectClass *oc, void *data)
mc->init = highbank_init;
mc->block_default_type = IF_SCSI;
mc->max_cpus = 4;
+ machine_class_add_default_bus(mc, "SSI");//FIXME: use macro
+ machine_class_add_default_bus(mc, "IDE");//FIXME: use macro
}
static const TypeInfo highbank_type = {
@@ -423,6 +425,8 @@ static void midway_class_init(ObjectClass *oc, void *data)
mc->init = midway_init;
mc->block_default_type = IF_SCSI;
mc->max_cpus = 4;
+ machine_class_add_default_bus(mc, "SSI");//FIXME: use macro
+ machine_class_add_default_bus(mc, "IDE");//FIXME: use macro
}
static const TypeInfo midway_type = {
diff --git a/hw/arm/imx25_pdk.c b/hw/arm/imx25_pdk.c
index 025b608..e29f9d4 100644
--- a/hw/arm/imx25_pdk.c
+++ b/hw/arm/imx25_pdk.c
@@ -148,6 +148,7 @@ static void imx25_pdk_machine_init(MachineClass *mc)
{
mc->desc = "ARM i.MX25 PDK board (ARM926)";
mc->init = imx25_pdk_init;
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
}
DEFINE_MACHINE("imx25-pdk", imx25_pdk_machine_init)
diff --git a/hw/arm/kzm.c b/hw/arm/kzm.c
index 2c96ee3..004f303 100644
--- a/hw/arm/kzm.c
+++ b/hw/arm/kzm.c
@@ -142,6 +142,7 @@ static void kzm_machine_init(MachineClass *mc)
{
mc->desc = "ARM KZM Emulation Baseboard (ARM1136)";
mc->init = kzm_init;
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
}
DEFINE_MACHINE("kzm", kzm_machine_init)
diff --git a/hw/arm/musicpal.c b/hw/arm/musicpal.c
index cbbca4e..7ff117c 100644
--- a/hw/arm/musicpal.c
+++ b/hw/arm/musicpal.c
@@ -1719,6 +1719,7 @@ static void musicpal_machine_init(MachineClass *mc)
{
mc->desc = "Marvell 88w8618 / MusicPal (ARM926EJ-S)";
mc->init = musicpal_init;
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
}
DEFINE_MACHINE("musicpal", musicpal_machine_init)
diff --git a/hw/arm/nseries.c b/hw/arm/nseries.c
index c86cf80..0df490f 100644
--- a/hw/arm/nseries.c
+++ b/hw/arm/nseries.c
@@ -1425,6 +1425,7 @@ static void n800_class_init(ObjectClass *oc, void *data)
mc->desc = "Nokia N800 tablet aka. RX-34 (OMAP2420)";
mc->init = n800_init;
mc->default_boot_order = "";
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
}
static const TypeInfo n800_type = {
@@ -1440,6 +1441,7 @@ static void n810_class_init(ObjectClass *oc, void *data)
mc->desc = "Nokia N810 tablet aka. RX-44 (OMAP2420)";
mc->init = n810_init;
mc->default_boot_order = "";
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
}
static const TypeInfo n810_type = {
diff --git a/hw/arm/palm.c b/hw/arm/palm.c
index 7f46073..b49c865 100644
--- a/hw/arm/palm.c
+++ b/hw/arm/palm.c
@@ -275,6 +275,7 @@ static void palmte_machine_init(MachineClass *mc)
{
mc->desc = "Palm Tungsten|E aka. Cheetah PDA (OMAP310)";
mc->init = palmte_init;
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
}
DEFINE_MACHINE("cheetah", palmte_machine_init)
diff --git a/hw/arm/realview.c b/hw/arm/realview.c
index 8eafcca..a7d8747 100644
--- a/hw/arm/realview.c
+++ b/hw/arm/realview.c
@@ -445,6 +445,7 @@ static void realview_pbx_a9_class_init(ObjectClass *oc, void *data)
mc->init = realview_pbx_a9_init;
mc->block_default_type = IF_SCSI;
mc->max_cpus = 4;
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
}
static const TypeInfo realview_pbx_a9_type = {
diff --git a/hw/arm/spitz.c b/hw/arm/spitz.c
index 949a15a..6888dff 100644
--- a/hw/arm/spitz.c
+++ b/hw/arm/spitz.c
@@ -30,6 +30,7 @@
#include "hw/sysbus.h"
#include "exec/address-spaces.h"
#include "sysemu/sysemu.h"
+#include "hw/usb.h"
#undef REG_FMT
#define REG_FMT "0x%02lx"
@@ -984,6 +985,9 @@ static void akitapda_class_init(ObjectClass *oc, void *data)
mc->desc = "Sharp SL-C1000 (Akita) PDA (PXA270)";
mc->init = akita_init;
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
+ machine_class_add_default_bus(mc, TYPE_USB_BUS);
+ machine_class_add_default_bus(mc, "SSI");//FIXME: use macro
}
static const TypeInfo akitapda_type = {
@@ -998,6 +1002,9 @@ static void spitzpda_class_init(ObjectClass *oc, void *data)
mc->desc = "Sharp SL-C3000 (Spitz) PDA (PXA270)";
mc->init = spitz_init;
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
+ machine_class_add_default_bus(mc, TYPE_USB_BUS);
+ machine_class_add_default_bus(mc, "SSI");//FIXME: use macro
}
static const TypeInfo spitzpda_type = {
@@ -1012,6 +1019,9 @@ static void borzoipda_class_init(ObjectClass *oc, void *data)
mc->desc = "Sharp SL-C3100 (Borzoi) PDA (PXA270)";
mc->init = borzoi_init;
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
+ machine_class_add_default_bus(mc, TYPE_USB_BUS);
+ machine_class_add_default_bus(mc, "SSI");//FIXME: use macro
}
static const TypeInfo borzoipda_type = {
diff --git a/hw/arm/stellaris.c b/hw/arm/stellaris.c
index 794a3ad..49b153b 100644
--- a/hw/arm/stellaris.c
+++ b/hw/arm/stellaris.c
@@ -1393,6 +1393,8 @@ static void lm3s811evb_class_init(ObjectClass *oc, void *data)
mc->desc = "Stellaris LM3S811EVB";
mc->init = lm3s811evb_init;
+ machine_class_add_default_bus(mc, "SSI");//FIXME: use macro
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
}
static const TypeInfo lm3s811evb_type = {
@@ -1407,6 +1409,8 @@ static void lm3s6965evb_class_init(ObjectClass *oc, void *data)
mc->desc = "Stellaris LM3S6965EVB";
mc->init = lm3s6965evb_init;
+ machine_class_add_default_bus(mc, "SSI");//FIXME: use macro
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
}
static const TypeInfo lm3s6965evb_type = {
--
2.7.4
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Qemu-devel] [RFC 13/15] mips: Initialize default bus lists
2016-11-22 1:11 [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Eduardo Habkost
` (11 preceding siblings ...)
2016-11-22 1:12 ` [Qemu-devel] [RFC 12/15] arm: " Eduardo Habkost
@ 2016-11-22 1:12 ` Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 14/15] ppc: " Eduardo Habkost
` (6 subsequent siblings)
19 siblings, 0 replies; 43+ messages in thread
From: Eduardo Habkost @ 2016-11-22 1:12 UTC (permalink / raw)
To: qemu-devel, Markus Armbruster, Marcel Apfelbaum, Michael S. Tsirkin
Cc: Aurelien Jarno, Yongbok Kim
Populate default_bus_types for some machines. Work in progress, I
didn't check if all machines were converted (so we could enable
strict mode for mips in qmp-machine-info.py).
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Yongbok Kim <yongbok.kim@imgtec.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
hw/mips/mips_malta.c | 7 +++++++
hw/mips/mips_r4k.c | 2 ++
2 files changed, 9 insertions(+)
diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
index cf48f42..af25595 100644
--- a/hw/mips/mips_malta.c
+++ b/hw/mips/mips_malta.c
@@ -57,6 +57,7 @@
#include "sysemu/kvm.h"
#include "exec/semihost.h"
#include "hw/mips/cps.h"
+#include "hw/usb.h"
//#define DEBUG_BOARD_INIT
@@ -1266,6 +1267,12 @@ static void mips_malta_machine_init(MachineClass *mc)
mc->init = mips_malta_init;
mc->max_cpus = 16;
mc->is_default = 1;
+ machine_class_add_default_bus(mc, "floppy-bus"); //FIXME: use macro
+ machine_class_add_default_bus(mc, "i2c-bus"); //FIXME: use macro
+ machine_class_add_default_bus(mc, TYPE_PCI_BUS);
+ machine_class_add_default_bus(mc, TYPE_ISA_BUS);
+ machine_class_add_default_bus(mc, "IDE");//FIXME: use macro
+ machine_class_add_default_bus(mc, TYPE_USB_BUS);
}
DEFINE_MACHINE("malta", mips_malta_machine_init)
diff --git a/hw/mips/mips_r4k.c b/hw/mips/mips_r4k.c
index 27548c4..69ca97a 100644
--- a/hw/mips/mips_r4k.c
+++ b/hw/mips/mips_r4k.c
@@ -306,6 +306,8 @@ static void mips_machine_init(MachineClass *mc)
{
mc->desc = "mips r4k platform";
mc->init = mips_r4k_init;
+ machine_class_add_default_bus(mc, TYPE_ISA_BUS);
+ machine_class_add_default_bus(mc, "IDE");//FIXME: use macro
}
DEFINE_MACHINE("mips", mips_machine_init)
--
2.7.4
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Qemu-devel] [RFC 14/15] ppc: Initialize default bus lists
2016-11-22 1:11 [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Eduardo Habkost
` (12 preceding siblings ...)
2016-11-22 1:12 ` [Qemu-devel] [RFC 13/15] mips: " Eduardo Habkost
@ 2016-11-22 1:12 ` Eduardo Habkost
2016-11-23 3:42 ` Alexey Kardashevskiy
2016-11-22 1:12 ` [Qemu-devel] [RFC 15/15] qdev: Add device_class_set_bus_type() function Eduardo Habkost
` (5 subsequent siblings)
19 siblings, 1 reply; 43+ messages in thread
From: Eduardo Habkost @ 2016-11-22 1:12 UTC (permalink / raw)
To: qemu-devel, Markus Armbruster, Marcel Apfelbaum, Michael S. Tsirkin
Cc: Alexander Graf, Scott Wood, David Gibson, qemu-ppc
Populate default_bus_types for some machines. Work in progress, I
didn't check if all machines were converted (so we could enable
strict mode for ppci in qmp-machine-info.py).
Cc: Alexander Graf <agraf@suse.de>
Cc: Scott Wood <scottwood@freescale.com>
Cc: David Gibson <david@gibson.dropbear.id.au>
Cc: qemu-ppc@nongnu.org
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
hw/ppc/e500plat.c | 3 +++
hw/ppc/mac_newworld.c | 4 ++++
hw/ppc/mac_oldworld.c | 3 +++
hw/ppc/mpc8544ds.c | 4 ++++
hw/ppc/ppc440_bamboo.c | 1 +
hw/ppc/prep.c | 4 ++++
6 files changed, 19 insertions(+)
diff --git a/hw/ppc/e500plat.c b/hw/ppc/e500plat.c
index 94b4545..015e1a1 100644
--- a/hw/ppc/e500plat.c
+++ b/hw/ppc/e500plat.c
@@ -17,6 +17,7 @@
#include "sysemu/kvm.h"
#include "hw/pci/pci.h"
#include "hw/ppc/openpic.h"
+#include "hw/virtio/virtio-bus.h"
#include "kvm_ppc.h"
static void e500plat_fixup_devtree(PPCE500Params *params, void *fdt)
@@ -64,6 +65,8 @@ static void e500plat_machine_init(MachineClass *mc)
mc->init = e500plat_init;
mc->max_cpus = 32;
mc->has_dynamic_sysbus = true;
+ machine_class_add_default_bus(mc, TYPE_PCI_BUS);
+ machine_class_add_default_bus(mc, TYPE_VIRTIO_BUS);
}
DEFINE_MACHINE("ppce500", e500plat_machine_init)
diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
index 2bfdb64..cbe510e 100644
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -521,6 +521,10 @@ static void core99_machine_class_init(ObjectClass *oc, void *data)
mc->max_cpus = MAX_CPUS;
mc->default_boot_order = "cd";
mc->kvm_type = core99_kvm_type;
+ machine_class_add_default_bus(mc, TYPE_IDE_BUS);
+ machine_class_add_default_bus(mc, TYPE_ADB_BUS);
+ machine_class_add_default_bus(mc, TYPE_PCI_BUS);
+ machine_class_add_default_bus(mc, TYPE_USB_BUS);
}
static const TypeInfo core99_machine_info = {
diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
index 56282c5..f281555 100644
--- a/hw/ppc/mac_oldworld.c
+++ b/hw/ppc/mac_oldworld.c
@@ -375,6 +375,9 @@ static void heathrow_machine_init(MachineClass *mc)
/* TOFIX "cad" when Mac floppy is implemented */
mc->default_boot_order = "cd";
mc->kvm_type = heathrow_kvm_type;
+ machine_class_add_default_bus(mc, TYPE_IDE_BUS);
+ machine_class_add_default_bus(mc, TYPE_ADB_BUS);
+ machine_class_add_default_bus(mc, TYPE_PCI_BUS);
}
DEFINE_MACHINE("g3beige", heathrow_machine_init)
diff --git a/hw/ppc/mpc8544ds.c b/hw/ppc/mpc8544ds.c
index 27b8289..3cef73a 100644
--- a/hw/ppc/mpc8544ds.c
+++ b/hw/ppc/mpc8544ds.c
@@ -15,6 +15,8 @@
#include "hw/boards.h"
#include "sysemu/device_tree.h"
#include "hw/ppc/openpic.h"
+#include "hw/pci/pci.h"
+#include "hw/virtio/virtio-bus.h"
#include "qemu/error-report.h"
static void mpc8544ds_fixup_devtree(PPCE500Params *params, void *fdt)
@@ -55,6 +57,8 @@ static void ppce500_machine_init(MachineClass *mc)
mc->desc = "mpc8544ds";
mc->init = mpc8544ds_init;
mc->max_cpus = 15;
+ machine_class_add_default_bus(mc, TYPE_PCI_BUS);
+ machine_class_add_default_bus(mc, TYPE_VIRTIO_BUS);
}
DEFINE_MACHINE("mpc8544ds", ppce500_machine_init)
diff --git a/hw/ppc/ppc440_bamboo.c b/hw/ppc/ppc440_bamboo.c
index 5c535b1..73e812b 100644
--- a/hw/ppc/ppc440_bamboo.c
+++ b/hw/ppc/ppc440_bamboo.c
@@ -295,6 +295,7 @@ static void bamboo_machine_init(MachineClass *mc)
{
mc->desc = "bamboo";
mc->init = bamboo_init;
+ machine_class_add_default_bus(mc, TYPE_PCI_BUS);
}
DEFINE_MACHINE("bamboo", bamboo_machine_init)
diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
index 054af1e..04cd7f4 100644
--- a/hw/ppc/prep.c
+++ b/hw/ppc/prep.c
@@ -675,6 +675,10 @@ static void prep_machine_init(MachineClass *mc)
mc->init = ppc_prep_init;
mc->max_cpus = MAX_CPUS;
mc->default_boot_order = "cad";
+ machine_class_add_default_bus(mc, "floppy-bus"); //FIXME: use macro
+ machine_class_add_default_bus(mc, TYPE_PCI_BUS);
+ machine_class_add_default_bus(mc, TYPE_ISA_BUS);
+ machine_class_add_default_bus(mc, "IDE");//FIXME: use macro
}
DEFINE_MACHINE("prep", prep_machine_init)
--
2.7.4
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Qemu-devel] [RFC 15/15] qdev: Add device_class_set_bus_type() function
2016-11-22 1:11 [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Eduardo Habkost
` (13 preceding siblings ...)
2016-11-22 1:12 ` [Qemu-devel] [RFC 14/15] ppc: " Eduardo Habkost
@ 2016-11-22 1:12 ` Eduardo Habkost
2016-11-22 1:34 ` [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' no-reply
` (4 subsequent siblings)
19 siblings, 0 replies; 43+ messages in thread
From: Eduardo Habkost @ 2016-11-22 1:12 UTC (permalink / raw)
To: qemu-devel, Markus Armbruster, Marcel Apfelbaum, Michael S. Tsirkin
Add a function set BusClass::bus_type, so we can perform extra
validation of the field, to ensure the corresponding bus class
has supported_device_types set propertly.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
hw/audio/intel-hda.c | 2 +-
hw/block/fdc.c | 2 +-
hw/char/virtio-serial-bus.c | 2 +-
hw/core/qdev.c | 8 ++++++++
hw/core/sysbus.c | 2 +-
hw/i2c/core.c | 2 +-
hw/ide/qdev.c | 2 +-
hw/input/adb.c | 2 +-
hw/ipack/ipack.c | 2 +-
hw/isa/isa-bus.c | 2 +-
hw/misc/auxbus.c | 2 +-
hw/pci/pci.c | 2 +-
hw/ppc/spapr_vio.c | 2 +-
hw/s390x/event-facility.c | 2 +-
hw/s390x/s390-pci-bus.c | 2 +-
hw/s390x/virtio-ccw.c | 2 +-
hw/scsi/scsi-bus.c | 2 +-
hw/sd/sd.c | 2 +-
hw/ssi/ssi.c | 2 +-
hw/usb/bus.c | 2 +-
hw/usb/dev-smartcard-reader.c | 2 +-
hw/virtio/virtio.c | 2 +-
include/hw/qdev-core.h | 2 ++
23 files changed, 31 insertions(+), 21 deletions(-)
diff --git a/hw/audio/intel-hda.c b/hw/audio/intel-hda.c
index a363993..5f18595 100644
--- a/hw/audio/intel-hda.c
+++ b/hw/audio/intel-hda.c
@@ -1327,7 +1327,7 @@ static void hda_codec_device_class_init(ObjectClass *klass, void *data)
k->realize = hda_codec_dev_realize;
k->exit = hda_codec_dev_exit;
set_bit(DEVICE_CATEGORY_SOUND, k->categories);
- k->bus_type = TYPE_HDA_BUS;
+ device_class_set_bus_type(k, TYPE_HDA_BUS);
k->props = hda_props;
}
diff --git a/hw/block/fdc.c b/hw/block/fdc.c
index 09bfdda..da655a6 100644
--- a/hw/block/fdc.c
+++ b/hw/block/fdc.c
@@ -593,7 +593,7 @@ static void floppy_drive_class_init(ObjectClass *klass, void *data)
DeviceClass *k = DEVICE_CLASS(klass);
k->init = floppy_drive_init;
set_bit(DEVICE_CATEGORY_STORAGE, k->categories);
- k->bus_type = TYPE_FLOPPY_BUS;
+ device_class_set_bus_type(k, TYPE_FLOPPY_BUS);
k->props = floppy_drive_properties;
k->desc = "virtual floppy drive";
}
diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index 215e180..ec0906a 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -1089,7 +1089,7 @@ static void virtio_serial_port_class_init(ObjectClass *klass, void *data)
DeviceClass *k = DEVICE_CLASS(klass);
set_bit(DEVICE_CATEGORY_INPUT, k->categories);
- k->bus_type = TYPE_VIRTIO_SERIAL_BUS;
+ device_class_set_bus_type(k, TYPE_VIRTIO_SERIAL_BUS);
k->realize = virtser_port_device_realize;
k->unrealize = virtser_port_device_unrealize;
k->props = virtser_props;
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 5783442..65ed738 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -1080,6 +1080,14 @@ static void device_finalize(Object *obj)
}
}
+void device_class_set_bus_type(DeviceClass *dc, const char *bus_type)
+{
+ BusClass *bc = BUS_CLASS(object_class_by_name(bus_type));
+
+ assert(object_class_dynamic_cast(OBJECT_CLASS(dc), bc->device_type));
+ dc->bus_type = bus_type;
+}
+
static void device_class_base_init(ObjectClass *class, void *data)
{
DeviceClass *klass = DEVICE_CLASS(class);
diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index c065eb8..ee3b768 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -326,7 +326,7 @@ static void sysbus_device_class_init(ObjectClass *klass, void *data)
{
DeviceClass *k = DEVICE_CLASS(klass);
k->init = sysbus_device_init;
- k->bus_type = TYPE_SYSTEM_BUS;
+ device_class_set_bus_type(k, TYPE_SYSTEM_BUS);
}
static const TypeInfo sysbus_device_type_info = {
diff --git a/hw/i2c/core.c b/hw/i2c/core.c
index 81b6ae4..66254ae 100644
--- a/hw/i2c/core.c
+++ b/hw/i2c/core.c
@@ -285,7 +285,7 @@ static void i2c_slave_class_init(ObjectClass *klass, void *data)
DeviceClass *k = DEVICE_CLASS(klass);
k->init = i2c_slave_qdev_init;
set_bit(DEVICE_CATEGORY_MISC, k->categories);
- k->bus_type = TYPE_I2C_BUS;
+ device_class_set_bus_type(k, TYPE_I2C_BUS);
k->props = i2c_props;
}
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index b526f85..35a65a0 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -365,7 +365,7 @@ static void ide_device_class_init(ObjectClass *klass, void *data)
DeviceClass *k = DEVICE_CLASS(klass);
k->init = ide_qdev_init;
set_bit(DEVICE_CATEGORY_STORAGE, k->categories);
- k->bus_type = TYPE_IDE_BUS;
+ device_class_set_bus_type(k, TYPE_IDE_BUS);
k->unrealize = idebus_unrealize;
k->props = ide_props;
}
diff --git a/hw/input/adb.c b/hw/input/adb.c
index c6a2b31..0e64b1c 100644
--- a/hw/input/adb.c
+++ b/hw/input/adb.c
@@ -162,7 +162,7 @@ static void adb_device_class_init(ObjectClass *oc, void *data)
DeviceClass *dc = DEVICE_CLASS(oc);
dc->realize = adb_device_realizefn;
- dc->bus_type = TYPE_ADB_BUS;
+ device_class_set_bus_type(dc, TYPE_ADB_BUS);
}
static const TypeInfo adb_device_type_info = {
diff --git a/hw/ipack/ipack.c b/hw/ipack/ipack.c
index f22c504..8a7fb63 100644
--- a/hw/ipack/ipack.c
+++ b/hw/ipack/ipack.c
@@ -81,7 +81,7 @@ static void ipack_device_class_init(ObjectClass *klass, void *data)
DeviceClass *k = DEVICE_CLASS(klass);
set_bit(DEVICE_CATEGORY_INPUT, k->categories);
- k->bus_type = TYPE_IPACK_BUS;
+ device_class_set_bus_type(k, TYPE_IPACK_BUS);
k->realize = ipack_device_realize;
k->unrealize = ipack_device_unrealize;
k->props = ipack_device_props;
diff --git a/hw/isa/isa-bus.c b/hw/isa/isa-bus.c
index aad7669..f97fe52 100644
--- a/hw/isa/isa-bus.c
+++ b/hw/isa/isa-bus.c
@@ -233,7 +233,7 @@ static const TypeInfo isabus_bridge_info = {
static void isa_device_class_init(ObjectClass *klass, void *data)
{
DeviceClass *k = DEVICE_CLASS(klass);
- k->bus_type = TYPE_ISA_BUS;
+ device_class_set_bus_type(k, TYPE_ISA_BUS);
}
static const TypeInfo isa_device_type_info = {
diff --git a/hw/misc/auxbus.c b/hw/misc/auxbus.c
index 4b0d565..b310dc4 100644
--- a/hw/misc/auxbus.c
+++ b/hw/misc/auxbus.c
@@ -272,7 +272,7 @@ static void aux_slave_class_init(ObjectClass *klass, void *data)
DeviceClass *k = DEVICE_CLASS(klass);
set_bit(DEVICE_CATEGORY_MISC, k->categories);
- k->bus_type = TYPE_AUX_BUS;
+ device_class_set_bus_type(k, TYPE_AUX_BUS);
}
static const TypeInfo aux_slave_type_info = {
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 1b0b7d3..be8ed2e 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -2504,7 +2504,7 @@ static void pci_device_class_init(ObjectClass *klass, void *data)
k->realize = pci_qdev_realize;
k->unrealize = pci_qdev_unrealize;
- k->bus_type = TYPE_PCI_BUS;
+ device_class_set_bus_type(k, TYPE_PCI_BUS);
k->props = pci_props;
pc->realize = pci_default_realize;
}
diff --git a/hw/ppc/spapr_vio.c b/hw/ppc/spapr_vio.c
index c70b9b9..53cb87c 100644
--- a/hw/ppc/spapr_vio.c
+++ b/hw/ppc/spapr_vio.c
@@ -586,7 +586,7 @@ static void vio_spapr_device_class_init(ObjectClass *klass, void *data)
DeviceClass *k = DEVICE_CLASS(klass);
k->realize = spapr_vio_busdev_realize;
k->reset = spapr_vio_busdev_reset;
- k->bus_type = TYPE_SPAPR_VIO_BUS;
+ device_class_set_bus_type(k, TYPE_SPAPR_VIO_BUS);
k->props = spapr_vio_props;
}
diff --git a/hw/s390x/event-facility.c b/hw/s390x/event-facility.c
index f2562ce..527ba36 100644
--- a/hw/s390x/event-facility.c
+++ b/hw/s390x/event-facility.c
@@ -426,7 +426,7 @@ static void event_class_init(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
- dc->bus_type = TYPE_SCLP_EVENTS_BUS;
+ device_class_set_bus_type(dc, TYPE_SCLP_EVENTS_BUS);
dc->realize = event_realize;
dc->unrealize = event_unrealize;
}
diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
index 7470fdd..a29c729 100644
--- a/hw/s390x/s390-pci-bus.c
+++ b/hw/s390x/s390-pci-bus.c
@@ -939,7 +939,7 @@ static void s390_pci_device_class_init(ObjectClass *klass, void *data)
dc->desc = "zpci device";
dc->reset = s390_pci_device_reset;
- dc->bus_type = TYPE_S390_PCI_BUS;
+ device_class_set_bus_type(dc, TYPE_S390_PCI_BUS);
dc->realize = s390_pci_device_realize;
dc->props = s390_pci_device_properties;
}
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index f5c1d98..b4ce290 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -1550,7 +1550,7 @@ static void virtio_ccw_device_class_init(ObjectClass *klass, void *data)
k->unplug = virtio_ccw_busdev_unplug;
dc->realize = virtio_ccw_busdev_realize;
dc->exit = virtio_ccw_busdev_exit;
- dc->bus_type = TYPE_VIRTUAL_CSS_BUS;
+ device_class_set_bus_type(dc, TYPE_VIRTUAL_CSS_BUS);
}
static const TypeInfo virtio_ccw_device_info = {
diff --git a/hw/scsi/scsi-bus.c b/hw/scsi/scsi-bus.c
index 9faf45f..b60079a 100644
--- a/hw/scsi/scsi-bus.c
+++ b/hw/scsi/scsi-bus.c
@@ -2067,7 +2067,7 @@ static void scsi_device_class_init(ObjectClass *klass, void *data)
{
DeviceClass *k = DEVICE_CLASS(klass);
set_bit(DEVICE_CATEGORY_STORAGE, k->categories);
- k->bus_type = TYPE_SCSI_BUS;
+ device_class_set_bus_type(k, TYPE_SCSI_BUS);
k->realize = scsi_qdev_realize;
k->unrealize = scsi_qdev_unrealize;
k->props = scsi_props;
diff --git a/hw/sd/sd.c b/hw/sd/sd.c
index 8e88e83..b1e5bc6 100644
--- a/hw/sd/sd.c
+++ b/hw/sd/sd.c
@@ -1917,7 +1917,7 @@ static void sd_class_init(ObjectClass *klass, void *data)
dc->props = sd_properties;
dc->vmsd = &sd_vmstate;
dc->reset = sd_reset;
- dc->bus_type = TYPE_SD_BUS;
+ device_class_set_bus_type(dc, TYPE_SD_BUS);
sc->do_command = sd_do_command;
sc->write_data = sd_write_data;
diff --git a/hw/ssi/ssi.c b/hw/ssi/ssi.c
index c48920d..b97d726 100644
--- a/hw/ssi/ssi.c
+++ b/hw/ssi/ssi.c
@@ -80,7 +80,7 @@ static void ssi_slave_class_init(ObjectClass *klass, void *data)
DeviceClass *dc = DEVICE_CLASS(klass);
dc->realize = ssi_slave_realize;
- dc->bus_type = TYPE_SSI_BUS;
+ device_class_set_bus_type(dc, TYPE_SSI_BUS);
if (!ssc->transfer_raw) {
ssc->transfer_raw = ssi_transfer_raw_default;
}
diff --git a/hw/usb/bus.c b/hw/usb/bus.c
index 2cb7fa4..978d9d5 100644
--- a/hw/usb/bus.c
+++ b/hw/usb/bus.c
@@ -789,7 +789,7 @@ static void usb_device_instance_init(Object *obj)
static void usb_device_class_init(ObjectClass *klass, void *data)
{
DeviceClass *k = DEVICE_CLASS(klass);
- k->bus_type = TYPE_USB_BUS;
+ device_class_set_bus_type(k, TYPE_USB_BUS);
k->realize = usb_qdev_realize;
k->unrealize = usb_qdev_unrealize;
k->props = usb_props;
diff --git a/hw/usb/dev-smartcard-reader.c b/hw/usb/dev-smartcard-reader.c
index 2721f0c..a7cf0f9 100644
--- a/hw/usb/dev-smartcard-reader.c
+++ b/hw/usb/dev-smartcard-reader.c
@@ -1487,7 +1487,7 @@ static const TypeInfo ccid_info = {
static void ccid_card_class_init(ObjectClass *klass, void *data)
{
DeviceClass *k = DEVICE_CLASS(klass);
- k->bus_type = TYPE_CCID_BUS;
+ device_class_set_bus_type(k, TYPE_CCID_BUS);
k->init = ccid_card_init;
k->exit = ccid_card_exit;
k->props = ccid_props;
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 1af2de2..9dfab8a 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -2247,7 +2247,7 @@ static void virtio_device_class_init(ObjectClass *klass, void *data)
dc->realize = virtio_device_realize;
dc->unrealize = virtio_device_unrealize;
- dc->bus_type = TYPE_VIRTIO_BUS;
+ device_class_set_bus_type(dc, TYPE_VIRTIO_BUS);
dc->props = virtio_properties;
vdc->start_ioeventfd = virtio_device_start_ioeventfd_impl;
vdc->stop_ioeventfd = virtio_device_stop_ioeventfd_impl;
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index 7c34f14..2f82950 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -406,4 +406,6 @@ static inline bool qbus_is_hotpluggable(BusState *bus)
void device_listener_register(DeviceListener *listener);
void device_listener_unregister(DeviceListener *listener);
+void device_class_set_bus_type(DeviceClass *dc, const char *bus_type);
+
#endif
--
2.7.4
^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines'
2016-11-22 1:11 [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Eduardo Habkost
` (14 preceding siblings ...)
2016-11-22 1:12 ` [Qemu-devel] [RFC 15/15] qdev: Add device_class_set_bus_type() function Eduardo Habkost
@ 2016-11-22 1:34 ` no-reply
2016-11-22 1:36 ` no-reply
` (3 subsequent siblings)
19 siblings, 0 replies; 43+ messages in thread
From: no-reply @ 2016-11-22 1:34 UTC (permalink / raw)
To: ehabkost; +Cc: famz, qemu-devel, armbru, marcel, mst, libvir-list, laine
Hi,
Your series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines'
Type: series
Message-id: 1479777133-23567-1-git-send-email-ehabkost@redhat.com
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0
# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True
commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done
exit $failed
=== TEST SCRIPT END ===
Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
* [new tag] patchew/1479777133-23567-1-git-send-email-ehabkost@redhat.com -> patchew/1479777133-23567-1-git-send-email-ehabkost@redhat.com
Switched to a new branch 'test'
5e1ecf3 qdev: Add device_class_set_bus_type() function
c8ab7cb ppc: Initialize default bus lists
70590aa mips: Initialize default bus lists
896edc8 arm: Initialize default bus lists
dd993a8 s390x: Initialize default bus lists
9ef506f pc: Initialize default bus lists
24f4450 pci: Introduce INTERFACE_PCIE_DEVICE interface name
c39bfeb qmp: Add 'supported-device-types' field to 'query-machines'
07ce179 machine: Add MachineClass::default_buses field
7680d6c qdev: Add device_type field to BusClass
76da7a3 tests: Add rules to non-gtester qtest test cases
e531dad qtest.py: Make 'binary' parameter optional
80780b6 qtest.py: make logging optional
3d3c3e5 qtest.py: Support QTEST_LOG environment variable
b2326ca qemu.py: Make logging optional
=== OUTPUT BEGIN ===
Checking PATCH 1/15: qemu.py: Make logging optional...
Checking PATCH 2/15: qtest.py: Support QTEST_LOG environment variable...
Checking PATCH 3/15: qtest.py: make logging optional...
WARNING: line over 80 characters
#26: FILE: scripts/qtest.py:87:
+ socket_scm_helper=socket_scm_helper,
total: 0 errors, 1 warnings, 14 lines checked
Your patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Checking PATCH 4/15: qtest.py: Make 'binary' parameter optional...
Checking PATCH 5/15: tests: Add rules to non-gtester qtest test cases...
Checking PATCH 6/15: qdev: Add device_type field to BusClass...
Checking PATCH 7/15: machine: Add MachineClass::default_buses field...
Checking PATCH 8/15: qmp: Add 'supported-device-types' field to 'query-machines'...
WARNING: line over 80 characters
#111: FILE: tests/qmp-machine-info.py:39:
+ dt = vm.qmp('qom-get', path=cp, property='device-type')['return']
ERROR: line over 90 characters
#119: FILE: tests/qmp-machine-info.py:47:
+ vm = qtest.QEMUQtestMachine(args=['-S', '-machine', machine['name']], logging=False)
WARNING: line over 80 characters
#141: FILE: tests/qmp-machine-info.py:69:
+ self.fail("extra device types: %s" % (' '.join(missing_types)))
WARNING: line over 80 characters
#162: FILE: tests/qmp-machine-info.py:90:
+ vm = qtest.QEMUQtestMachine(args=['-S', '-machine', 'none'], logging=False)
total: 1 errors, 3 warnings, 189 lines checked
Your patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Checking PATCH 9/15: pci: Introduce INTERFACE_PCIE_DEVICE interface name...
Checking PATCH 10/15: pc: Initialize default bus lists...
ERROR: do not use C99 // comments
#20: FILE: hw/i386/pc_piix.c:438:
+ machine_class_add_default_bus(m, "floppy-bus"); //FIXME: use macro
ERROR: do not use C99 // comments
#21: FILE: hw/i386/pc_piix.c:439:
+ machine_class_add_default_bus(m, "i2c-bus"); //FIXME: use macro
ERROR: do not use C99 // comments
#24: FILE: hw/i386/pc_piix.c:442:
+ machine_class_add_default_bus(m, "IDE");//FIXME: use macro
ERROR: do not use C99 // comments
#32: FILE: hw/i386/pc_piix.c:1087:
+ machine_class_add_default_bus(m, "floppy-bus"); //FIXME: use macro
ERROR: do not use C99 // comments
#34: FILE: hw/i386/pc_piix.c:1089:
+ machine_class_add_default_bus(m, "IDE");//FIXME: use macro
ERROR: do not use C99 // comments
#42: FILE: hw/i386/pc_piix.c:1109:
+ machine_class_add_default_bus(m, "floppy-bus"); //FIXME: use macro
ERROR: do not use C99 // comments
#43: FILE: hw/i386/pc_piix.c:1110:
+ machine_class_add_default_bus(m, "i2c-bus"); //FIXME: use macro
ERROR: do not use C99 // comments
#46: FILE: hw/i386/pc_piix.c:1113:
+ machine_class_add_default_bus(m, "IDE");//FIXME: use macro
ERROR: do not use C99 // comments
#58: FILE: hw/i386/pc_q35.c:295:
+ machine_class_add_default_bus(m, "i2c-bus"); //FIXME: use macro
ERROR: do not use C99 // comments
#61: FILE: hw/i386/pc_q35.c:298:
+ machine_class_add_default_bus(m, "IDE");//FIXME: use macro
total: 10 errors, 0 warnings, 49 lines checked
Your patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Checking PATCH 11/15: s390x: Initialize default bus lists...
Checking PATCH 12/15: arm: Initialize default bus lists...
ERROR: do not use C99 // comments
#29: FILE: hw/arm/aspeed.c:183:
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
ERROR: do not use C99 // comments
#30: FILE: hw/arm/aspeed.c:184:
+ machine_class_add_default_bus(mc, "SSI");//FIXME: use macro
ERROR: do not use C99 // comments
#42: FILE: hw/arm/collie.c:67:
+ machine_class_add_default_bus(mc, "SSI");//FIXME: use macro
ERROR: do not use C99 // comments
#54: FILE: hw/arm/cubieboard.c:85:
+ machine_class_add_default_bus(mc, TYPE_IDE_BUS);//FIXME: use macro
ERROR: do not use C99 // comments
#74: FILE: hw/arm/exynos4_boards.c:158:
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
ERROR: do not use C99 // comments
#83: FILE: hw/arm/exynos4_boards.c:175:
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
ERROR: do not use C99 // comments
#104: FILE: hw/arm/gumstix.c:132:
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
ERROR: do not use C99 // comments
#106: FILE: hw/arm/gumstix.c:134:
+ machine_class_add_default_bus(mc, "SSI");//FIXME: use macro
ERROR: do not use C99 // comments
#114: FILE: hw/arm/gumstix.c:149:
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
ERROR: do not use C99 // comments
#116: FILE: hw/arm/gumstix.c:151:
+ machine_class_add_default_bus(mc, "SSI");//FIXME: use macro
ERROR: do not use C99 // comments
#128: FILE: hw/arm/highbank.c:410:
+ machine_class_add_default_bus(mc, "SSI");//FIXME: use macro
ERROR: do not use C99 // comments
#129: FILE: hw/arm/highbank.c:411:
+ machine_class_add_default_bus(mc, "IDE");//FIXME: use macro
ERROR: do not use C99 // comments
#137: FILE: hw/arm/highbank.c:428:
+ machine_class_add_default_bus(mc, "SSI");//FIXME: use macro
ERROR: do not use C99 // comments
#138: FILE: hw/arm/highbank.c:429:
+ machine_class_add_default_bus(mc, "IDE");//FIXME: use macro
ERROR: do not use C99 // comments
#150: FILE: hw/arm/imx25_pdk.c:151:
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
ERROR: do not use C99 // comments
#162: FILE: hw/arm/kzm.c:145:
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
ERROR: do not use C99 // comments
#174: FILE: hw/arm/musicpal.c:1722:
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
ERROR: do not use C99 // comments
#186: FILE: hw/arm/nseries.c:1428:
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
ERROR: do not use C99 // comments
#194: FILE: hw/arm/nseries.c:1444:
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
ERROR: do not use C99 // comments
#206: FILE: hw/arm/palm.c:278:
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
ERROR: do not use C99 // comments
#218: FILE: hw/arm/realview.c:448:
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
ERROR: do not use C99 // comments
#238: FILE: hw/arm/spitz.c:988:
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
ERROR: do not use C99 // comments
#240: FILE: hw/arm/spitz.c:990:
+ machine_class_add_default_bus(mc, "SSI");//FIXME: use macro
ERROR: do not use C99 // comments
#248: FILE: hw/arm/spitz.c:1005:
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
ERROR: do not use C99 // comments
#250: FILE: hw/arm/spitz.c:1007:
+ machine_class_add_default_bus(mc, "SSI");//FIXME: use macro
ERROR: do not use C99 // comments
#258: FILE: hw/arm/spitz.c:1022:
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
ERROR: do not use C99 // comments
#260: FILE: hw/arm/spitz.c:1024:
+ machine_class_add_default_bus(mc, "SSI");//FIXME: use macro
ERROR: do not use C99 // comments
#272: FILE: hw/arm/stellaris.c:1396:
+ machine_class_add_default_bus(mc, "SSI");//FIXME: use macro
ERROR: do not use C99 // comments
#273: FILE: hw/arm/stellaris.c:1397:
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
ERROR: do not use C99 // comments
#281: FILE: hw/arm/stellaris.c:1412:
+ machine_class_add_default_bus(mc, "SSI");//FIXME: use macro
ERROR: do not use C99 // comments
#282: FILE: hw/arm/stellaris.c:1413:
+ machine_class_add_default_bus(mc, "i2c-bus");//FIXME: use macro
total: 31 errors, 0 warnings, 185 lines checked
Your patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Checking PATCH 13/15: mips: Initialize default bus lists...
ERROR: do not use C99 // comments
#31: FILE: hw/mips/mips_malta.c:1270:
+ machine_class_add_default_bus(mc, "floppy-bus"); //FIXME: use macro
ERROR: do not use C99 // comments
#32: FILE: hw/mips/mips_malta.c:1271:
+ machine_class_add_default_bus(mc, "i2c-bus"); //FIXME: use macro
ERROR: do not use C99 // comments
#35: FILE: hw/mips/mips_malta.c:1274:
+ machine_class_add_default_bus(mc, "IDE");//FIXME: use macro
ERROR: do not use C99 // comments
#49: FILE: hw/mips/mips_r4k.c:310:
+ machine_class_add_default_bus(mc, "IDE");//FIXME: use macro
total: 4 errors, 0 warnings, 27 lines checked
Your patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Checking PATCH 14/15: ppc: Initialize default bus lists...
ERROR: do not use C99 // comments
#109: FILE: hw/ppc/prep.c:678:
+ machine_class_add_default_bus(mc, "floppy-bus"); //FIXME: use macro
ERROR: do not use C99 // comments
#112: FILE: hw/ppc/prep.c:681:
+ machine_class_add_default_bus(mc, "IDE");//FIXME: use macro
total: 2 errors, 0 warnings, 67 lines checked
Your patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Checking PATCH 15/15: qdev: Add device_class_set_bus_type() function...
=== OUTPUT END ===
Test command exited with code: 1
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-devel@freelists.org
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines'
2016-11-22 1:11 [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Eduardo Habkost
` (15 preceding siblings ...)
2016-11-22 1:34 ` [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' no-reply
@ 2016-11-22 1:36 ` no-reply
2016-11-22 8:18 ` David Hildenbrand
` (2 subsequent siblings)
19 siblings, 0 replies; 43+ messages in thread
From: no-reply @ 2016-11-22 1:36 UTC (permalink / raw)
To: ehabkost; +Cc: famz, qemu-devel, armbru, marcel, mst, libvir-list, laine
Hi,
Your series failed automatic build test. Please find the testing commands and
their output below. If you have docker installed, you can probably reproduce it
locally.
Subject: [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines'
Type: series
Message-id: 1479777133-23567-1-git-send-email-ehabkost@redhat.com
=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
export J=16
make docker-test-quick@centos6
make docker-test-mingw@fedora
make docker-test-build@min-glib
=== TEST SCRIPT END ===
Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
5e1ecf3 qdev: Add device_class_set_bus_type() function
c8ab7cb ppc: Initialize default bus lists
70590aa mips: Initialize default bus lists
896edc8 arm: Initialize default bus lists
dd993a8 s390x: Initialize default bus lists
9ef506f pc: Initialize default bus lists
24f4450 pci: Introduce INTERFACE_PCIE_DEVICE interface name
c39bfeb qmp: Add 'supported-device-types' field to 'query-machines'
07ce179 machine: Add MachineClass::default_buses field
7680d6c qdev: Add device_type field to BusClass
76da7a3 tests: Add rules to non-gtester qtest test cases
e531dad qtest.py: Make 'binary' parameter optional
80780b6 qtest.py: make logging optional
3d3c3e5 qtest.py: Support QTEST_LOG environment variable
b2326ca qemu.py: Make logging optional
=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into 'dtc'...
Submodule path 'dtc': checked out '65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf'
BUILD centos6
make[1]: Entering directory `/var/tmp/patchew-tester-tmp-fmoi6289/src'
ARCHIVE qemu.tgz
ARCHIVE dtc.tgz
COPY RUNNER
RUN test-quick in qemu:centos6
Packages installed:
SDL-devel-1.2.14-7.el6_7.1.x86_64
ccache-3.1.6-2.el6.x86_64
epel-release-6-8.noarch
gcc-4.4.7-17.el6.x86_64
git-1.7.1-4.el6_7.1.x86_64
glib2-devel-2.28.8-5.el6.x86_64
libfdt-devel-1.4.0-1.el6.x86_64
make-3.81-23.el6.x86_64
package g++ is not installed
pixman-devel-0.32.8-1.el6.x86_64
tar-1.23-15.el6_8.x86_64
zlib-devel-1.2.3-29.el6.x86_64
Environment variables:
PACKAGES=libfdt-devel ccache tar git make gcc g++ zlib-devel glib2-devel SDL-devel pixman-devel epel-release
HOSTNAME=68bc562d605e
TERM=xterm
MAKEFLAGS= -j16
HISTSIZE=1000
J=16
USER=root
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
MAIL=/var/spool/mail/root
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
LANG=en_US.UTF-8
TARGET_LIST=
HISTCONTROL=ignoredups
SHLVL=1
HOME=/root
TEST_DIR=/tmp/qemu-test
LOGNAME=root
LESSOPEN=||/usr/bin/lesspipe.sh %s
FEATURES= dtc
DEBUG=
G_BROKEN_FILENAMES=1
CCACHE_HASHDIR=
_=/usr/bin/env
Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu --prefix=/var/tmp/qemu-build/install
No C++ compiler available; disabling C++ specific optional code
Install prefix /var/tmp/qemu-build/install
BIOS directory /var/tmp/qemu-build/install/share/qemu
binary directory /var/tmp/qemu-build/install/bin
library directory /var/tmp/qemu-build/install/lib
module directory /var/tmp/qemu-build/install/lib/qemu
libexec directory /var/tmp/qemu-build/install/libexec
include directory /var/tmp/qemu-build/install/include
config directory /var/tmp/qemu-build/install/etc
local state directory /var/tmp/qemu-build/install/var
Manual directory /var/tmp/qemu-build/install/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path /tmp/qemu-test/src
C compiler cc
Host C compiler cc
C++ compiler
Objective-C compiler cc
ARFLAGS rv
CFLAGS -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g
QEMU_CFLAGS -I/usr/include/pixman-1 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -fPIE -DPIE -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all
LDFLAGS -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g
make make
install install
python python -B
smbd /usr/sbin/smbd
module support no
host CPU x86_64
host big endian no
target list x86_64-softmmu aarch64-softmmu
tcg debug enabled no
gprof enabled no
sparse enabled no
strip binaries yes
profiler no
static build no
pixman system
SDL support yes (1.2.14)
GTK support no
GTK GL support no
VTE support no
TLS priority NORMAL
GNUTLS support no
GNUTLS rnd no
libgcrypt no
libgcrypt kdf no
nettle no
nettle kdf no
libtasn1 no
curses support no
virgl support no
curl support no
mingw32 support no
Audio drivers oss
Block whitelist (rw)
Block whitelist (ro)
VirtFS support no
VNC support yes
VNC SASL support no
VNC JPEG support no
VNC PNG support no
xen support no
brlapi support no
bluez support no
Documentation no
PIE yes
vde support no
netmap support no
Linux AIO support no
ATTR/XATTR support yes
Install blobs yes
KVM support yes
COLO support yes
RDMA support no
TCG interpreter no
fdt support yes
preadv support yes
fdatasync yes
madvise yes
posix_madvise yes
libcap-ng support no
vhost-net support yes
vhost-scsi support yes
vhost-vsock support yes
Trace backends log
spice support no
rbd support no
xfsctl support no
smartcard support no
libusb no
usb net redir no
OpenGL support no
OpenGL dmabufs no
libiscsi support no
libnfs support no
build guest agent yes
QGA VSS support no
QGA w32 disk info no
QGA MSI support no
seccomp support no
coroutine backend ucontext
coroutine pool yes
debug stack usage no
GlusterFS support no
Archipelago support no
gcov gcov
gcov enabled no
TPM support yes
libssh2 support no
TPM passthrough yes
QOM debugging yes
lzo support no
snappy support no
bzip2 support no
NUMA host support no
tcmalloc support no
jemalloc support no
avx2 optimization no
replication support yes
GEN x86_64-softmmu/config-devices.mak.tmp
GEN aarch64-softmmu/config-devices.mak.tmp
GEN config-host.h
GEN qemu-options.def
GEN qmp-commands.h
GEN qapi-types.h
GEN qapi-event.h
GEN qapi-visit.h
GEN qmp-introspect.h
GEN x86_64-softmmu/config-devices.mak
GEN aarch64-softmmu/config-devices.mak
GEN module_block.h
GEN tests/test-qmp-commands.h
GEN tests/test-qapi-types.h
GEN tests/test-qapi-visit.h
GEN tests/test-qapi-event.h
GEN tests/test-qmp-introspect.h
GEN trace/generated-tracers.h
GEN trace/generated-tcg-tracers.h
GEN trace/generated-helpers-wrappers.h
GEN trace/generated-helpers.h
GEN config-all-devices.mak
CC tests/qemu-iotests/socket_scm_helper.o
GEN qga/qapi-generated/qga-qapi-types.h
GEN qga/qapi-generated/qga-qapi-visit.h
GEN qga/qapi-generated/qga-qmp-commands.h
GEN qga/qapi-generated/qga-qapi-types.c
GEN qga/qapi-generated/qga-qapi-visit.c
GEN qga/qapi-generated/qga-qmp-marshal.c
GEN qmp-introspect.c
GEN qapi-types.c
GEN qapi-visit.c
GEN qapi-event.c
CC qapi/qapi-visit-core.o
CC qapi/qapi-dealloc-visitor.o
CC qapi/qobject-input-visitor.o
CC qapi/qobject-output-visitor.o
CC qapi/qmp-registry.o
CC qapi/qmp-dispatch.o
CC qapi/string-input-visitor.o
CC qapi/string-output-visitor.o
CC qapi/opts-visitor.o
CC qapi/qapi-clone-visitor.o
CC qapi/qmp-event.o
CC qapi/qapi-util.o
CC qobject/qnull.o
CC qobject/qint.o
CC qobject/qstring.o
CC qobject/qdict.o
CC qobject/qlist.o
CC qobject/qfloat.o
CC qobject/qbool.o
CC qobject/qjson.o
CC qobject/qobject.o
CC qobject/json-lexer.o
CC qobject/json-streamer.o
CC qobject/json-parser.o
GEN trace/generated-tracers.c
CC trace/control.o
CC trace/qmp.o
CC util/osdep.o
CC util/cutils.o
CC util/unicode.o
CC util/qemu-timer-common.o
CC util/bufferiszero.o
CC util/compatfd.o
CC util/event_notifier-posix.o
CC util/mmap-alloc.o
CC util/oslib-posix.o
CC util/qemu-openpty.o
CC util/qemu-thread-posix.o
CC util/memfd.o
CC util/envlist.o
CC util/path.o
CC util/module.o
CC util/bitmap.o
CC util/bitops.o
CC util/fifo8.o
CC util/hbitmap.o
CC util/acl.o
CC util/error.o
CC util/qemu-error.o
CC util/id.o
CC util/iov.o
CC util/qemu-config.o
CC util/qemu-sockets.o
CC util/uri.o
CC util/notify.o
CC util/qemu-option.o
CC util/qemu-progress.o
CC util/hexdump.o
CC util/crc32c.o
CC util/uuid.o
CC util/throttle.o
CC util/getauxval.o
CC util/readline.o
CC util/rcu.o
CC util/qemu-coroutine.o
CC util/qemu-coroutine-lock.o
CC util/qemu-coroutine-io.o
CC util/qemu-coroutine-sleep.o
CC util/coroutine-ucontext.o
CC util/buffer.o
CC util/timed-average.o
CC util/base64.o
CC util/log.o
CC util/qdist.o
CC util/qht.o
CC util/range.o
CC crypto/pbkdf-stub.o
CC stubs/arch-query-cpu-def.o
CC stubs/arch-query-cpu-model-expansion.o
CC stubs/arch-query-cpu-model-comparison.o
CC stubs/arch-query-cpu-model-baseline.o
CC stubs/blk-commit-all.o
CC stubs/bdrv-next-monitor-owned.o
CC stubs/blockdev-close-all-bdrv-states.o
CC stubs/clock-warp.o
CC stubs/cpu-get-clock.o
CC stubs/cpu-get-icount.o
CC stubs/dump.o
CC stubs/error-printf.o
CC stubs/fdset-add-fd.o
CC stubs/fdset-find-fd.o
CC stubs/fdset-get-fd.o
CC stubs/fdset-remove-fd.o
CC stubs/gdbstub.o
CC stubs/get-fd.o
CC stubs/get-next-serial.o
CC stubs/get-vm-name.o
CC stubs/iothread.o
CC stubs/iothread-lock.o
CC stubs/is-daemonized.o
CC stubs/machine-init-done.o
CC stubs/migr-blocker.o
CC stubs/mon-is-qmp.o
CC stubs/monitor-init.o
CC stubs/notify-event.o
CC stubs/qtest.o
CC stubs/replay.o
CC stubs/replay-user.o
CC stubs/reset.o
CC stubs/runstate-check.o
CC stubs/set-fd-handler.o
CC stubs/slirp.o
CC stubs/sysbus.o
CC stubs/trace-control.o
CC stubs/uuid.o
CC stubs/vm-stop.o
CC stubs/vmstate.o
CC stubs/cpus.o
CC stubs/kvm.o
CC stubs/qmp_pc_dimm_device_list.o
CC stubs/target-monitor-defs.o
CC stubs/target-get-monitor-def.o
CC stubs/vhost.o
CC stubs/iohandler.o
CC stubs/smbios_type_38.o
CC stubs/ipmi.o
CC stubs/pc_madt_cpu_entry.o
CC stubs/migration-colo.o
CC contrib/ivshmem-client/ivshmem-client.o
CC contrib/ivshmem-client/main.o
CC contrib/ivshmem-server/ivshmem-server.o
CC contrib/ivshmem-server/main.o
CC qemu-nbd.o
CC async.o
CC thread-pool.o
CC block.o
CC blockjob.o
CC main-loop.o
CC iohandler.o
CC qemu-timer.o
CC aio-posix.o
CC qemu-io-cmds.o
CC replication.o
CC block/raw_bsd.o
CC block/qcow.o
CC block/vdi.o
CC block/vmdk.o
CC block/cloop.o
CC block/bochs.o
CC block/vpc.o
CC block/vvfat.o
CC block/dmg.o
CC block/qcow2.o
CC block/qcow2-refcount.o
CC block/qcow2-cluster.o
CC block/qcow2-snapshot.o
CC block/qcow2-cache.o
CC block/qed.o
CC block/qed-gencb.o
CC block/qed-l2-cache.o
CC block/qed-table.o
CC block/qed-cluster.o
CC block/qed-check.o
CC block/vhdx.o
CC block/vhdx-endian.o
CC block/vhdx-log.o
CC block/quorum.o
CC block/parallels.o
CC block/blkdebug.o
CC block/blkverify.o
CC block/blkreplay.o
CC block/block-backend.o
CC block/snapshot.o
CC block/qapi.o
CC block/raw-posix.o
CC block/null.o
CC block/mirror.o
CC block/commit.o
CC block/io.o
CC block/throttle-groups.o
CC block/nbd.o
CC block/nbd-client.o
CC block/sheepdog.o
CC block/accounting.o
CC block/dirty-bitmap.o
CC block/write-threshold.o
CC block/backup.o
CC block/replication.o
CC block/crypto.o
CC nbd/server.o
CC nbd/client.o
CC nbd/common.o
CC crypto/init.o
CC crypto/hash.o
CC crypto/hash-glib.o
CC crypto/aes.o
CC crypto/desrfb.o
CC crypto/cipher.o
CC crypto/tlscreds.o
CC crypto/tlscredsanon.o
CC crypto/tlscredsx509.o
CC crypto/tlssession.o
CC crypto/secret.o
CC crypto/random-platform.o
CC crypto/pbkdf.o
CC crypto/ivgen.o
CC crypto/ivgen-essiv.o
CC crypto/ivgen-plain.o
CC crypto/ivgen-plain64.o
CC crypto/afsplit.o
CC crypto/xts.o
CC crypto/block.o
CC crypto/block-qcow.o
CC crypto/block-luks.o
CC io/channel.o
CC io/channel-buffer.o
CC io/channel-command.o
CC io/channel-file.o
CC io/channel-socket.o
CC io/channel-tls.o
CC io/channel-watch.o
CC io/channel-websock.o
CC io/channel-util.o
CC io/task.o
CC qom/object.o
CC qom/container.o
CC qom/qom-qobject.o
CC qom/object_interfaces.o
GEN qemu-img-cmds.h
CC qemu-io.o
CC qemu-bridge-helper.o
CC blockdev.o
CC blockdev-nbd.o
CC iothread.o
CC qdev-monitor.o
CC device-hotplug.o
CC os-posix.o
CC qemu-char.o
CC page_cache.o
CC accel.o
CC bt-host.o
CC bt-vhci.o
CC dma-helpers.o
CC vl.o
CC tpm.o
CC device_tree.o
GEN qmp-marshal.c
CC qmp.o
CC hmp.o
CC cpus-common.o
CC audio/audio.o
CC audio/noaudio.o
CC audio/wavaudio.o
CC audio/mixeng.o
CC audio/sdlaudio.o
CC audio/ossaudio.o
CC audio/wavcapture.o
CC backends/rng-egd.o
CC backends/rng.o
CC backends/rng-random.o
CC backends/msmouse.o
CC backends/testdev.o
CC backends/tpm.o
CC backends/hostmem.o
CC backends/hostmem-ram.o
CC backends/hostmem-file.o
CC backends/cryptodev.o
CC block/stream.o
CC backends/cryptodev-builtin.o
CC disas/arm.o
CC disas/i386.o
CC fsdev/qemu-fsdev-dummy.o
CC fsdev/qemu-fsdev-opts.o
CC hw/acpi/core.o
CC hw/acpi/piix4.o
CC hw/acpi/pcihp.o
CC hw/acpi/ich9.o
CC hw/acpi/tco.o
CC hw/acpi/cpu_hotplug.o
CC hw/acpi/memory_hotplug.o
CC hw/acpi/memory_hotplug_acpi_table.o
CC hw/acpi/cpu.o
CC hw/acpi/nvdimm.o
CC hw/acpi/acpi_interface.o
CC hw/acpi/bios-linker-loader.o
CC hw/acpi/aml-build.o
CC hw/acpi/ipmi.o
CC hw/audio/sb16.o
CC hw/audio/es1370.o
CC hw/audio/ac97.o
CC hw/audio/fmopl.o
CC hw/audio/adlib.o
CC hw/audio/gus.o
CC hw/audio/gusemu_hal.o
CC hw/audio/gusemu_mixer.o
CC hw/audio/cs4231a.o
CC hw/audio/intel-hda.o
CC hw/audio/hda-codec.o
CC hw/audio/pcspk.o
CC hw/audio/wm8750.o
CC hw/audio/pl041.o
CC hw/audio/lm4549.o
CC hw/audio/marvell_88w8618.o
CC hw/block/block.o
CC hw/block/cdrom.o
CC hw/block/hd-geometry.o
CC hw/block/fdc.o
CC hw/block/m25p80.o
CC hw/block/nand.o
CC hw/block/pflash_cfi01.o
CC hw/block/pflash_cfi02.o
CC hw/block/ecc.o
CC hw/block/onenand.o
CC hw/block/nvme.o
CC hw/bt/core.o
CC hw/bt/l2cap.o
CC hw/bt/sdp.o
CC hw/bt/hci.o
CC hw/bt/hid.o
CC hw/bt/hci-csr.o
CC hw/char/ipoctal232.o
CC hw/char/parallel.o
CC hw/char/pl011.o
CC hw/char/serial.o
CC hw/char/serial-isa.o
CC hw/char/serial-pci.o
CC hw/char/virtio-console.o
CC hw/char/cadence_uart.o
CC hw/char/debugcon.o
CC hw/core/qdev.o
CC hw/char/imx_serial.o
CC hw/core/qdev-properties.o
CC hw/core/bus.o
CC hw/core/fw-path-provider.o
CC hw/core/irq.o
CC hw/core/hotplug.o
CC hw/core/ptimer.o
CC hw/core/sysbus.o
CC hw/core/null-machine.o
CC hw/core/machine.o
CC hw/core/loader.o
CC hw/core/qdev-properties-system.o
CC hw/core/register.o
CC hw/core/or-irq.o
CC hw/core/platform-bus.o
CC hw/display/ads7846.o
CC hw/display/cirrus_vga.o
CC hw/display/pl110.o
CC hw/display/ssd0323.o
CC hw/display/ssd0303.o
CC hw/display/vga-pci.o
CC hw/display/vga-isa.o
CC hw/display/vmware_vga.o
CC hw/display/blizzard.o
CC hw/display/exynos4210_fimd.o
CC hw/display/framebuffer.o
CC hw/display/tc6393xb.o
CC hw/dma/pl080.o
CC hw/dma/pl330.o
CC hw/dma/i8257.o
CC hw/dma/xlnx-zynq-devcfg.o
CC hw/gpio/max7310.o
CC hw/gpio/pl061.o
CC hw/gpio/zaurus.o
CC hw/gpio/gpio_key.o
CC hw/i2c/core.o
CC hw/i2c/smbus.o
CC hw/i2c/smbus_eeprom.o
CC hw/i2c/versatile_i2c.o
CC hw/i2c/i2c-ddc.o
CC hw/i2c/smbus_ich9.o
CC hw/i2c/pm_smbus.o
CC hw/i2c/bitbang_i2c.o
CC hw/i2c/exynos4210_i2c.o
CC hw/i2c/imx_i2c.o
CC hw/i2c/aspeed_i2c.o
CC hw/ide/core.o
CC hw/ide/atapi.o
CC hw/ide/qdev.o
CC hw/ide/pci.o
CC hw/ide/isa.o
CC hw/ide/piix.o
CC hw/ide/microdrive.o
CC hw/ide/ahci.o
CC hw/ide/ich.o
CC hw/input/hid.o
CC hw/input/lm832x.o
CC hw/input/pckbd.o
CC hw/input/pl050.o
CC hw/input/ps2.o
CC hw/input/stellaris_input.o
CC hw/input/tsc2005.o
CC hw/input/vmmouse.o
CC hw/input/virtio-input.o
CC hw/input/virtio-input-hid.o
CC hw/input/virtio-input-host.o
CC hw/intc/i8259_common.o
CC hw/intc/i8259.o
CC hw/intc/pl190.o
CC hw/intc/imx_avic.o
CC hw/intc/realview_gic.o
CC hw/intc/ioapic_common.o
CC hw/intc/arm_gic_common.o
CC hw/intc/arm_gic.o
CC hw/intc/arm_gicv2m.o
CC hw/intc/arm_gicv3_common.o
CC hw/intc/arm_gicv3.o
CC hw/intc/arm_gicv3_dist.o
CC hw/intc/arm_gicv3_redist.o
CC hw/intc/arm_gicv3_its_common.o
CC hw/intc/intc.o
CC hw/ipack/ipack.o
CC hw/ipack/tpci200.o
CC hw/ipmi/ipmi.o
CC hw/ipmi/ipmi_bmc_sim.o
CC hw/ipmi/ipmi_bmc_extern.o
CC hw/ipmi/isa_ipmi_kcs.o
CC hw/ipmi/isa_ipmi_bt.o
CC hw/isa/isa-bus.o
CC hw/isa/apm.o
CC hw/mem/pc-dimm.o
CC hw/mem/nvdimm.o
CC hw/misc/applesmc.o
CC hw/misc/max111x.o
CC hw/misc/tmp105.o
CC hw/misc/debugexit.o
CC hw/misc/sga.o
CC hw/misc/pc-testdev.o
CC hw/misc/pci-testdev.o
CC hw/misc/arm_l2x0.o
CC hw/misc/arm_integrator_debug.o
CC hw/misc/a9scu.o
CC hw/misc/arm11scu.o
CC hw/net/ne2000.o
CC hw/net/eepro100.o
CC hw/net/pcnet-pci.o
CC hw/net/pcnet.o
CC hw/net/e1000.o
CC hw/net/e1000x_common.o
CC hw/net/net_tx_pkt.o
CC hw/net/net_rx_pkt.o
CC hw/net/e1000e.o
CC hw/net/e1000e_core.o
CC hw/net/rtl8139.o
CC hw/net/vmxnet3.o
CC hw/net/smc91c111.o
CC hw/net/lan9118.o
CC hw/net/ne2000-isa.o
CC hw/net/xgmac.o
CC hw/net/allwinner_emac.o
CC hw/net/imx_fec.o
CC hw/net/cadence_gem.o
CC hw/net/stellaris_enet.o
CC hw/net/rocker/rocker.o
CC hw/net/rocker/rocker_fp.o
CC hw/net/rocker/rocker_desc.o
CC hw/net/rocker/rocker_world.o
CC hw/net/rocker/rocker_of_dpa.o
CC hw/nvram/eeprom93xx.o
CC hw/nvram/fw_cfg.o
CC hw/nvram/chrp_nvram.o
CC hw/pci-bridge/pci_bridge_dev.o
CC hw/pci-bridge/pci_expander_bridge.o
CC hw/pci-bridge/xio3130_upstream.o
CC hw/pci-bridge/xio3130_downstream.o
CC hw/pci-bridge/ioh3420.o
CC hw/pci-bridge/i82801b11.o
CC hw/pci-host/pam.o
CC hw/pci-host/versatile.o
CC hw/pci-host/piix.o
CC hw/pci-host/q35.o
CC hw/pci-host/gpex.o
CC hw/pci/pci.o
CC hw/pci/pci_bridge.o
CC hw/pci/msix.o
CC hw/pci/msi.o
CC hw/pci/shpc.o
CC hw/pci/slotid_cap.o
CC hw/pci/pci_host.o
CC hw/pci/pcie_host.o
CC hw/pci/pcie.o
CC hw/pci/pcie_aer.o
CC hw/pci/pcie_port.o
CC hw/pci/pci-stub.o
CC hw/pcmcia/pcmcia.o
CC hw/scsi/scsi-disk.o
CC hw/scsi/scsi-generic.o
CC hw/scsi/scsi-bus.o
CC hw/scsi/lsi53c895a.o
/tmp/qemu-test/src/hw/nvram/fw_cfg.c: In function ‘fw_cfg_dma_transfer’:
/tmp/qemu-test/src/hw/nvram/fw_cfg.c:329: warning: ‘read’ may be used uninitialized in this function
CC hw/scsi/mptsas.o
CC hw/scsi/mptconfig.o
CC hw/scsi/mptendian.o
CC hw/scsi/megasas.o
CC hw/scsi/vmw_pvscsi.o
CC hw/scsi/esp.o
CC hw/scsi/esp-pci.o
CC hw/sd/pl181.o
CC hw/sd/ssi-sd.o
CC hw/sd/sd.o
CC hw/sd/core.o
CC hw/sd/sdhci.o
CC hw/smbios/smbios.o
CC hw/smbios/smbios_type_38.o
CC hw/ssi/pl022.o
CC hw/ssi/ssi.o
CC hw/ssi/xilinx_spips.o
CC hw/ssi/aspeed_smc.o
CC hw/ssi/stm32f2xx_spi.o
CC hw/timer/arm_timer.o
CC hw/timer/arm_mptimer.o
CC hw/timer/a9gtimer.o
CC hw/timer/cadence_ttc.o
CC hw/timer/ds1338.o
CC hw/timer/hpet.o
CC hw/timer/i8254_common.o
CC hw/timer/i8254.o
CC hw/timer/pl031.o
CC hw/timer/twl92230.o
CC hw/timer/imx_epit.o
CC hw/timer/imx_gpt.o
CC hw/timer/stm32f2xx_timer.o
CC hw/timer/aspeed_timer.o
CC hw/tpm/tpm_tis.o
CC hw/tpm/tpm_passthrough.o
CC hw/tpm/tpm_util.o
CC hw/usb/core.o
CC hw/usb/combined-packet.o
CC hw/usb/bus.o
CC hw/usb/libhw.o
CC hw/usb/desc.o
CC hw/usb/desc-msos.o
CC hw/usb/hcd-uhci.o
CC hw/usb/hcd-ohci.o
CC hw/usb/hcd-ehci.o
CC hw/usb/hcd-ehci-pci.o
CC hw/usb/hcd-ehci-sysbus.o
CC hw/usb/hcd-xhci.o
CC hw/usb/hcd-musb.o
CC hw/usb/dev-hub.o
CC hw/usb/dev-hid.o
CC hw/usb/dev-wacom.o
CC hw/usb/dev-storage.o
CC hw/usb/dev-uas.o
CC hw/usb/dev-audio.o
CC hw/usb/dev-serial.o
CC hw/usb/dev-network.o
CC hw/usb/dev-bluetooth.o
CC hw/usb/dev-smartcard-reader.o
CC hw/usb/dev-mtp.o
CC hw/usb/host-stub.o
CC hw/virtio/virtio-rng.o
CC hw/virtio/virtio-pci.o
CC hw/virtio/virtio-bus.o
CC hw/virtio/virtio-mmio.o
CC hw/watchdog/watchdog.o
CC hw/watchdog/wdt_i6300esb.o
CC hw/watchdog/wdt_ib700.o
CC migration/migration.o
CC migration/socket.o
CC migration/fd.o
CC migration/exec.o
CC migration/tls.o
CC migration/colo-comm.o
CC migration/colo.o
CC migration/colo-failover.o
CC migration/vmstate.o
CC migration/qemu-file.o
CC migration/qemu-file-channel.o
CC migration/xbzrle.o
CC migration/postcopy-ram.o
CC migration/qjson.o
CC migration/block.o
CC net/net.o
CC net/queue.o
CC net/checksum.o
CC net/util.o
CC net/hub.o
CC net/socket.o
CC net/dump.o
CC net/eth.o
CC net/l2tpv3.o
CC net/tap.o
CC net/vhost-user.o
CC net/tap-linux.o
CC net/slirp.o
CC net/filter.o
CC net/filter-buffer.o
CC net/filter-mirror.o
CC net/colo-compare.o
CC net/colo.o
CC net/filter-rewriter.o
CC qom/cpu.o
CC replay/replay.o
CC replay/replay-internal.o
CC replay/replay-events.o
CC replay/replay-time.o
CC replay/replay-input.o
CC replay/replay-char.o
CC replay/replay-snapshot.o
CC slirp/cksum.o
CC slirp/if.o
CC slirp/ip_icmp.o
CC slirp/ip6_icmp.o
/tmp/qemu-test/src/replay/replay-internal.c: In function ‘replay_put_array’:
/tmp/qemu-test/src/replay/replay-internal.c:65: warning: ignoring return value of ‘fwrite’, declared with attribute warn_unused_result
CC slirp/ip6_output.o
CC slirp/ip6_input.o
CC slirp/ip_input.o
CC slirp/ip_output.o
CC slirp/dnssearch.o
CC slirp/dhcpv6.o
CC slirp/slirp.o
CC slirp/mbuf.o
CC slirp/misc.o
CC slirp/sbuf.o
CC slirp/socket.o
CC slirp/tcp_input.o
CC slirp/tcp_subr.o
CC slirp/tcp_output.o
CC slirp/udp.o
CC slirp/tcp_timer.o
CC slirp/udp6.o
CC slirp/bootp.o
CC slirp/tftp.o
CC slirp/arp_table.o
CC slirp/ndp_table.o
CC ui/keymaps.o
CC ui/console.o
CC ui/cursor.o
CC ui/qemu-pixman.o
CC ui/input.o
CC ui/input-keymap.o
CC ui/input-legacy.o
CC ui/input-linux.o
CC ui/sdl.o
CC ui/sdl_zoom.o
CC ui/x_keymap.o
CC ui/vnc.o
/tmp/qemu-test/src/slirp/tcp_input.c: In function ‘tcp_input’:
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_p’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_len’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_tos’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_id’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_off’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_ttl’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_sum’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_src.s_addr’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_dst.s_addr’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:220: warning: ‘save_ip6.ip_nh’ may be used uninitialized in this function
CC ui/vnc-enc-zlib.o
CC ui/vnc-enc-hextile.o
CC ui/vnc-enc-tight.o
CC ui/vnc-palette.o
CC ui/vnc-enc-zrle.o
CC ui/vnc-auth-vencrypt.o
CC ui/vnc-ws.o
CC ui/vnc-jobs.o
LINK tests/qemu-iotests/socket_scm_helper
CC qga/commands.o
CC qga/guest-agent-command-state.o
CC qga/main.o
AS optionrom/multiboot.o
AS optionrom/linuxboot.o
CC qga/commands-posix.o
CC optionrom/linuxboot_dma.o
cc: unrecognized option '-no-integrated-as'
cc: unrecognized option '-no-integrated-as'
AS optionrom/kvmvapic.o
CC qga/channel-posix.o
BUILD optionrom/multiboot.img
BUILD optionrom/linuxboot.img
BUILD optionrom/linuxboot_dma.img
BUILD optionrom/kvmvapic.img
BUILD optionrom/multiboot.raw
BUILD optionrom/linuxboot.raw
BUILD optionrom/linuxboot_dma.raw
BUILD optionrom/kvmvapic.raw
CC qga/qapi-generated/qga-qapi-types.o
SIGN optionrom/multiboot.bin
SIGN optionrom/linuxboot.bin
SIGN optionrom/linuxboot_dma.bin
CC qga/qapi-generated/qga-qapi-visit.o
SIGN optionrom/kvmvapic.bin
CC qga/qapi-generated/qga-qmp-marshal.o
CC qmp-introspect.o
CC qapi-types.o
CC qapi-visit.o
CC qapi-event.o
AR libqemustub.a
CC qemu-img.o
CC qmp-marshal.o
CC trace/generated-tracers.o
AR libqemuutil.a
LINK qemu-ga
LINK ivshmem-client
LINK ivshmem-server
LINK qemu-nbd
LINK qemu-img
LINK qemu-io
LINK qemu-bridge-helper
GEN aarch64-softmmu/hmp-commands.h
GEN aarch64-softmmu/hmp-commands-info.h
GEN aarch64-softmmu/config-target.h
GEN x86_64-softmmu/config-target.h
GEN x86_64-softmmu/hmp-commands.h
GEN x86_64-softmmu/hmp-commands-info.h
CC aarch64-softmmu/cpu-exec.o
CC aarch64-softmmu/exec.o
CC aarch64-softmmu/translate-common.o
CC aarch64-softmmu/translate-all.o
CC aarch64-softmmu/cpu-exec-common.o
CC aarch64-softmmu/tcg/tcg.o
CC aarch64-softmmu/tcg/tcg-op.o
CC aarch64-softmmu/tcg/optimize.o
CC aarch64-softmmu/tcg/tcg-common.o
CC aarch64-softmmu/disas.o
CC aarch64-softmmu/fpu/softfloat.o
CC aarch64-softmmu/tcg-runtime.o
GEN aarch64-softmmu/gdbstub-xml.c
CC aarch64-softmmu/kvm-stub.o
CC aarch64-softmmu/arch_init.o
CC aarch64-softmmu/cpus.o
CC x86_64-softmmu/exec.o
CC aarch64-softmmu/monitor.o
CC x86_64-softmmu/translate-all.o
CC aarch64-softmmu/gdbstub.o
CC x86_64-softmmu/cpu-exec.o
CC x86_64-softmmu/translate-common.o
CC x86_64-softmmu/cpu-exec-common.o
CC x86_64-softmmu/tcg/tcg.o
CC aarch64-softmmu/balloon.o
CC x86_64-softmmu/tcg/tcg-op.o
CC x86_64-softmmu/tcg/optimize.o
CC aarch64-softmmu/ioport.o
CC aarch64-softmmu/numa.o
CC x86_64-softmmu/tcg/tcg-common.o
CC aarch64-softmmu/qtest.o
CC aarch64-softmmu/bootdevice.o
CC x86_64-softmmu/fpu/softfloat.o
CC aarch64-softmmu/memory.o
CC x86_64-softmmu/disas.o
CC x86_64-softmmu/tcg-runtime.o
CC aarch64-softmmu/cputlb.o
CC aarch64-softmmu/memory_mapping.o
CC aarch64-softmmu/dump.o
CC aarch64-softmmu/migration/ram.o
CC aarch64-softmmu/migration/savevm.o
CC x86_64-softmmu/arch_init.o
CC x86_64-softmmu/cpus.o
CC x86_64-softmmu/monitor.o
CC x86_64-softmmu/gdbstub.o
CC aarch64-softmmu/xen-common-stub.o
CC aarch64-softmmu/xen-hvm-stub.o
CC x86_64-softmmu/balloon.o
CC x86_64-softmmu/ioport.o
CC aarch64-softmmu/hw/adc/stm32f2xx_adc.o
CC aarch64-softmmu/hw/block/virtio-blk.o
CC aarch64-softmmu/hw/block/dataplane/virtio-blk.o
CC aarch64-softmmu/hw/char/exynos4210_uart.o
CC aarch64-softmmu/hw/char/omap_uart.o
CC x86_64-softmmu/numa.o
CC aarch64-softmmu/hw/char/digic-uart.o
CC x86_64-softmmu/qtest.o
CC aarch64-softmmu/hw/char/stm32f2xx_usart.o
CC aarch64-softmmu/hw/char/bcm2835_aux.o
CC x86_64-softmmu/bootdevice.o
CC x86_64-softmmu/kvm-all.o
CC x86_64-softmmu/memory.o
CC aarch64-softmmu/hw/char/virtio-serial-bus.o
CC x86_64-softmmu/cputlb.o
CC x86_64-softmmu/memory_mapping.o
CC aarch64-softmmu/hw/core/nmi.o
CC aarch64-softmmu/hw/core/generic-loader.o
CC x86_64-softmmu/dump.o
CC x86_64-softmmu/migration/ram.o
CC aarch64-softmmu/hw/cpu/arm11mpcore.o
CC aarch64-softmmu/hw/cpu/realview_mpcore.o
CC x86_64-softmmu/migration/savevm.o
CC aarch64-softmmu/hw/cpu/a9mpcore.o
CC aarch64-softmmu/hw/cpu/a15mpcore.o
CC x86_64-softmmu/xen-common-stub.o
CC x86_64-softmmu/xen-hvm-stub.o
CC x86_64-softmmu/hw/block/virtio-blk.o
CC x86_64-softmmu/hw/block/dataplane/virtio-blk.o
CC x86_64-softmmu/hw/char/virtio-serial-bus.o
CC aarch64-softmmu/hw/cpu/core.o
CC x86_64-softmmu/hw/core/nmi.o
CC x86_64-softmmu/hw/core/generic-loader.o
CC aarch64-softmmu/hw/display/omap_dss.o
CC aarch64-softmmu/hw/display/omap_lcdc.o
CC aarch64-softmmu/hw/display/pxa2xx_lcd.o
CC x86_64-softmmu/hw/cpu/core.o
CC x86_64-softmmu/hw/display/vga.o
CC aarch64-softmmu/hw/display/bcm2835_fb.o
CC x86_64-softmmu/hw/display/virtio-gpu.o
CC aarch64-softmmu/hw/display/vga.o
CC aarch64-softmmu/hw/display/virtio-gpu.o
CC aarch64-softmmu/hw/display/virtio-gpu-3d.o
CC aarch64-softmmu/hw/display/dpcd.o
CC aarch64-softmmu/hw/display/virtio-gpu-pci.o
CC aarch64-softmmu/hw/display/xlnx_dp.o
CC aarch64-softmmu/hw/dma/xlnx_dpdma.o
CC aarch64-softmmu/hw/dma/omap_dma.o
CC aarch64-softmmu/hw/dma/soc_dma.o
CC aarch64-softmmu/hw/dma/pxa2xx_dma.o
CC aarch64-softmmu/hw/dma/bcm2835_dma.o
CC x86_64-softmmu/hw/display/virtio-gpu-3d.o
CC aarch64-softmmu/hw/gpio/omap_gpio.o
CC x86_64-softmmu/hw/display/virtio-gpu-pci.o
CC aarch64-softmmu/hw/gpio/imx_gpio.o
CC x86_64-softmmu/hw/display/virtio-vga.o
CC x86_64-softmmu/hw/intc/apic.o
CC x86_64-softmmu/hw/intc/apic_common.o
CC x86_64-softmmu/hw/intc/ioapic.o
CC x86_64-softmmu/hw/isa/lpc_ich9.o
CC aarch64-softmmu/hw/i2c/omap_i2c.o
CC x86_64-softmmu/hw/misc/vmport.o
CC x86_64-softmmu/hw/misc/ivshmem.o
CC x86_64-softmmu/hw/misc/pvpanic.o
CC aarch64-softmmu/hw/input/pxa2xx_keypad.o
CC aarch64-softmmu/hw/input/tsc210x.o
CC x86_64-softmmu/hw/misc/edu.o
CC aarch64-softmmu/hw/intc/armv7m_nvic.o
CC aarch64-softmmu/hw/intc/exynos4210_gic.o
CC x86_64-softmmu/hw/misc/hyperv_testdev.o
CC aarch64-softmmu/hw/intc/exynos4210_combiner.o
CC x86_64-softmmu/hw/net/virtio-net.o
CC x86_64-softmmu/hw/net/vhost_net.o
CC x86_64-softmmu/hw/scsi/virtio-scsi.o
CC aarch64-softmmu/hw/intc/omap_intc.o
CC x86_64-softmmu/hw/scsi/vhost-scsi.o
CC x86_64-softmmu/hw/scsi/virtio-scsi-dataplane.o
CC x86_64-softmmu/hw/timer/mc146818rtc.o
CC x86_64-softmmu/hw/vfio/common.o
CC x86_64-softmmu/hw/vfio/pci.o
CC x86_64-softmmu/hw/vfio/pci-quirks.o
CC aarch64-softmmu/hw/intc/bcm2835_ic.o
CC x86_64-softmmu/hw/vfio/platform.o
CC aarch64-softmmu/hw/intc/bcm2836_control.o
CC aarch64-softmmu/hw/intc/aspeed_vic.o
CC aarch64-softmmu/hw/intc/allwinner-a10-pic.o
CC aarch64-softmmu/hw/intc/arm_gicv3_cpuif.o
CC aarch64-softmmu/hw/misc/ivshmem.o
CC aarch64-softmmu/hw/misc/arm_sysctl.o
CC aarch64-softmmu/hw/misc/cbus.o
CC aarch64-softmmu/hw/misc/exynos4210_pmu.o
CC aarch64-softmmu/hw/misc/imx_ccm.o
CC x86_64-softmmu/hw/vfio/calxeda-xgmac.o
CC aarch64-softmmu/hw/misc/imx31_ccm.o
CC x86_64-softmmu/hw/vfio/amd-xgbe.o
CC aarch64-softmmu/hw/misc/imx25_ccm.o
CC x86_64-softmmu/hw/vfio/spapr.o
CC aarch64-softmmu/hw/misc/imx6_ccm.o
CC x86_64-softmmu/hw/virtio/virtio.o
CC x86_64-softmmu/hw/virtio/virtio-balloon.o
CC x86_64-softmmu/hw/virtio/vhost.o
CC aarch64-softmmu/hw/misc/imx6_src.o
CC x86_64-softmmu/hw/virtio/vhost-backend.o
CC aarch64-softmmu/hw/misc/mst_fpga.o
CC x86_64-softmmu/hw/virtio/vhost-user.o
CC aarch64-softmmu/hw/misc/omap_clk.o
CC aarch64-softmmu/hw/misc/omap_gpmc.o
CC x86_64-softmmu/hw/virtio/vhost-vsock.o
CC x86_64-softmmu/hw/virtio/virtio-crypto.o
CC x86_64-softmmu/hw/virtio/virtio-crypto-pci.o
CC x86_64-softmmu/hw/i386/multiboot.o
CC aarch64-softmmu/hw/misc/omap_l4.o
CC aarch64-softmmu/hw/misc/omap_sdrc.o
CC x86_64-softmmu/hw/i386/pc.o
CC aarch64-softmmu/hw/misc/omap_tap.o
CC x86_64-softmmu/hw/i386/pc_piix.o
CC aarch64-softmmu/hw/misc/bcm2835_mbox.o
CC x86_64-softmmu/hw/i386/pc_q35.o
CC aarch64-softmmu/hw/misc/bcm2835_property.o
CC aarch64-softmmu/hw/misc/zynq_slcr.o
CC x86_64-softmmu/hw/i386/pc_sysfw.o
CC aarch64-softmmu/hw/misc/zynq-xadc.o
CC x86_64-softmmu/hw/i386/x86-iommu.o
CC aarch64-softmmu/hw/misc/stm32f2xx_syscfg.o
CC x86_64-softmmu/hw/i386/intel_iommu.o
CC aarch64-softmmu/hw/misc/edu.o
CC aarch64-softmmu/hw/misc/auxbus.o
CC x86_64-softmmu/hw/i386/amd_iommu.o
CC aarch64-softmmu/hw/misc/aspeed_scu.o
CC x86_64-softmmu/hw/i386/kvmvapic.o
CC x86_64-softmmu/hw/i386/acpi-build.o
CC x86_64-softmmu/hw/i386/pci-assign-load-rom.o
CC aarch64-softmmu/hw/misc/aspeed_sdmc.o
CC aarch64-softmmu/hw/net/virtio-net.o
CC aarch64-softmmu/hw/net/vhost_net.o
CC aarch64-softmmu/hw/pcmcia/pxa2xx.o
CC aarch64-softmmu/hw/scsi/virtio-scsi.o
CC x86_64-softmmu/hw/i386/kvm/clock.o
CC x86_64-softmmu/hw/i386/kvm/apic.o
CC x86_64-softmmu/hw/i386/kvm/i8259.o
CC aarch64-softmmu/hw/scsi/virtio-scsi-dataplane.o
CC aarch64-softmmu/hw/scsi/vhost-scsi.o
/tmp/qemu-test/src/hw/i386/pc_piix.c: In function ‘igd_passthrough_isa_bridge_create’:
/tmp/qemu-test/src/hw/i386/pc_piix.c:1051: warning: ‘pch_rev_id’ may be used uninitialized in this function
CC aarch64-softmmu/hw/sd/omap_mmc.o
CC aarch64-softmmu/hw/sd/pxa2xx_mmci.o
CC aarch64-softmmu/hw/ssi/omap_spi.o
CC x86_64-softmmu/hw/i386/kvm/ioapic.o
CC x86_64-softmmu/hw/i386/kvm/i8254.o
CC x86_64-softmmu/hw/i386/kvm/pci-assign.o
CC aarch64-softmmu/hw/ssi/imx_spi.o
CC aarch64-softmmu/hw/timer/exynos4210_mct.o
CC x86_64-softmmu/target-i386/translate.o
CC aarch64-softmmu/hw/timer/exynos4210_pwm.o
CC aarch64-softmmu/hw/timer/exynos4210_rtc.o
CC x86_64-softmmu/target-i386/helper.o
CC aarch64-softmmu/hw/timer/omap_gptimer.o
CC x86_64-softmmu/target-i386/cpu.o
CC x86_64-softmmu/target-i386/bpt_helper.o
CC x86_64-softmmu/target-i386/excp_helper.o
CC aarch64-softmmu/hw/timer/omap_synctimer.o
/tmp/qemu-test/src/hw/i386/acpi-build.c: In function ‘build_append_pci_bus_devices’:
/tmp/qemu-test/src/hw/i386/acpi-build.c:501: warning: ‘notify_method’ may be used uninitialized in this function
CC aarch64-softmmu/hw/timer/pxa2xx_timer.o
CC x86_64-softmmu/target-i386/fpu_helper.o
CC x86_64-softmmu/target-i386/cc_helper.o
CC aarch64-softmmu/hw/timer/digic-timer.o
CC x86_64-softmmu/target-i386/int_helper.o
CC aarch64-softmmu/hw/timer/allwinner-a10-pit.o
CC aarch64-softmmu/hw/usb/tusb6010.o
CC x86_64-softmmu/target-i386/svm_helper.o
CC aarch64-softmmu/hw/vfio/common.o
CC x86_64-softmmu/target-i386/smm_helper.o
CC x86_64-softmmu/target-i386/misc_helper.o
CC aarch64-softmmu/hw/vfio/pci.o
CC aarch64-softmmu/hw/vfio/pci-quirks.o
CC aarch64-softmmu/hw/vfio/platform.o
CC x86_64-softmmu/target-i386/mem_helper.o
CC aarch64-softmmu/hw/vfio/calxeda-xgmac.o
CC aarch64-softmmu/hw/vfio/amd-xgbe.o
CC aarch64-softmmu/hw/vfio/spapr.o
CC x86_64-softmmu/target-i386/seg_helper.o
CC aarch64-softmmu/hw/virtio/virtio.o
CC aarch64-softmmu/hw/virtio/virtio-balloon.o
CC aarch64-softmmu/hw/virtio/vhost.o
CC x86_64-softmmu/target-i386/mpx_helper.o
CC x86_64-softmmu/target-i386/gdbstub.o
CC aarch64-softmmu/hw/virtio/vhost-backend.o
CC x86_64-softmmu/target-i386/machine.o
CC aarch64-softmmu/hw/virtio/vhost-user.o
CC x86_64-softmmu/target-i386/arch_memory_mapping.o
CC x86_64-softmmu/target-i386/arch_dump.o
CC x86_64-softmmu/target-i386/monitor.o
CC x86_64-softmmu/target-i386/kvm.o
CC aarch64-softmmu/hw/virtio/vhost-vsock.o
CC x86_64-softmmu/target-i386/hyperv.o
CC aarch64-softmmu/hw/virtio/virtio-crypto.o
GEN trace/generated-helpers.c
CC x86_64-softmmu/trace/control-target.o
CC aarch64-softmmu/hw/virtio/virtio-crypto-pci.o
CC aarch64-softmmu/hw/arm/boot.o
CC aarch64-softmmu/hw/arm/collie.o
CC aarch64-softmmu/hw/arm/exynos4_boards.o
CC aarch64-softmmu/hw/arm/gumstix.o
CC aarch64-softmmu/hw/arm/highbank.o
CC aarch64-softmmu/hw/arm/digic_boards.o
CC aarch64-softmmu/hw/arm/integratorcp.o
CC x86_64-softmmu/trace/generated-helpers.o
CC aarch64-softmmu/hw/arm/mainstone.o
CC aarch64-softmmu/hw/arm/musicpal.o
CC aarch64-softmmu/hw/arm/nseries.o
CC aarch64-softmmu/hw/arm/omap_sx1.o
CC aarch64-softmmu/hw/arm/palm.o
CC aarch64-softmmu/hw/arm/realview.o
CC aarch64-softmmu/hw/arm/spitz.o
CC aarch64-softmmu/hw/arm/stellaris.o
CC aarch64-softmmu/hw/arm/tosa.o
CC aarch64-softmmu/hw/arm/versatilepb.o
CC aarch64-softmmu/hw/arm/vexpress.o
CC aarch64-softmmu/hw/arm/virt.o
CC aarch64-softmmu/hw/arm/xilinx_zynq.o
CC aarch64-softmmu/hw/arm/z2.o
CC aarch64-softmmu/hw/arm/netduino2.o
CC aarch64-softmmu/hw/arm/sysbus-fdt.o
CC aarch64-softmmu/hw/arm/virt-acpi-build.o
CC aarch64-softmmu/hw/arm/armv7m.o
CC aarch64-softmmu/hw/arm/exynos4210.o
CC aarch64-softmmu/hw/arm/pxa2xx.o
CC aarch64-softmmu/hw/arm/pxa2xx_gpio.o
CC aarch64-softmmu/hw/arm/pxa2xx_pic.o
CC aarch64-softmmu/hw/arm/digic.o
CC aarch64-softmmu/hw/arm/omap1.o
CC aarch64-softmmu/hw/arm/omap2.o
CC aarch64-softmmu/hw/arm/strongarm.o
CC aarch64-softmmu/hw/arm/allwinner-a10.o
CC aarch64-softmmu/hw/arm/cubieboard.o
CC aarch64-softmmu/hw/arm/bcm2835_peripherals.o
CC aarch64-softmmu/hw/arm/bcm2836.o
CC aarch64-softmmu/hw/arm/raspi.o
CC aarch64-softmmu/hw/arm/stm32f205_soc.o
CC aarch64-softmmu/hw/arm/xlnx-zynqmp.o
CC aarch64-softmmu/hw/arm/xlnx-ep108.o
CC aarch64-softmmu/hw/arm/fsl-imx25.o
CC aarch64-softmmu/hw/arm/imx25_pdk.o
CC aarch64-softmmu/hw/arm/fsl-imx31.o
CC aarch64-softmmu/hw/arm/kzm.o
CC aarch64-softmmu/hw/arm/fsl-imx6.o
CC aarch64-softmmu/hw/arm/sabrelite.o
CC aarch64-softmmu/hw/arm/aspeed_soc.o
CC aarch64-softmmu/hw/arm/aspeed.o
CC aarch64-softmmu/target-arm/arm-semi.o
CC aarch64-softmmu/target-arm/machine.o
CC aarch64-softmmu/target-arm/psci.o
CC aarch64-softmmu/target-arm/arch_dump.o
CC aarch64-softmmu/target-arm/monitor.o
CC aarch64-softmmu/target-arm/kvm-stub.o
CC aarch64-softmmu/target-arm/translate.o
CC aarch64-softmmu/target-arm/op_helper.o
CC aarch64-softmmu/target-arm/helper.o
CC aarch64-softmmu/target-arm/cpu.o
CC aarch64-softmmu/target-arm/neon_helper.o
CC aarch64-softmmu/target-arm/iwmmxt_helper.o
CC aarch64-softmmu/target-arm/gdbstub.o
CC aarch64-softmmu/target-arm/cpu64.o
CC aarch64-softmmu/target-arm/translate-a64.o
CC aarch64-softmmu/target-arm/helper-a64.o
CC aarch64-softmmu/target-arm/gdbstub64.o
CC aarch64-softmmu/target-arm/crypto_helper.o
CC aarch64-softmmu/target-arm/arm-powerctl.o
GEN trace/generated-helpers.c
CC aarch64-softmmu/trace/control-target.o
CC aarch64-softmmu/gdbstub-xml.o
CC aarch64-softmmu/trace/generated-helpers.o
LINK x86_64-softmmu/qemu-system-x86_64
/tmp/qemu-test/src/target-arm/translate-a64.c: In function ‘handle_shri_with_rndacc’:
/tmp/qemu-test/src/target-arm/translate-a64.c:6395: warning: ‘tcg_src_hi’ may be used uninitialized in this function
/tmp/qemu-test/src/target-arm/translate-a64.c: In function ‘disas_simd_scalar_two_reg_misc’:
/tmp/qemu-test/src/target-arm/translate-a64.c:8122: warning: ‘rmode’ may be used uninitialized in this function
LINK aarch64-softmmu/qemu-system-aarch64
TEST tests/qapi-schema/alternate-any.out
TEST tests/qapi-schema/alternate-array.out
TEST tests/qapi-schema/alternate-base.out
TEST tests/qapi-schema/alternate-clash.out
TEST tests/qapi-schema/alternate-conflict-dict.out
TEST tests/qapi-schema/alternate-nested.out
TEST tests/qapi-schema/alternate-conflict-string.out
TEST tests/qapi-schema/alternate-empty.out
TEST tests/qapi-schema/alternate-unknown.out
TEST tests/qapi-schema/args-any.out
TEST tests/qapi-schema/args-alternate.out
TEST tests/qapi-schema/args-array-empty.out
TEST tests/qapi-schema/args-array-unknown.out
TEST tests/qapi-schema/args-bad-boxed.out
TEST tests/qapi-schema/args-boxed-anon.out
TEST tests/qapi-schema/args-boxed-empty.out
TEST tests/qapi-schema/args-boxed-string.out
TEST tests/qapi-schema/args-int.out
TEST tests/qapi-schema/args-invalid.out
TEST tests/qapi-schema/args-member-array-bad.out
TEST tests/qapi-schema/args-member-case.out
TEST tests/qapi-schema/args-member-unknown.out
TEST tests/qapi-schema/args-name-clash.out
TEST tests/qapi-schema/args-union.out
TEST tests/qapi-schema/args-unknown.out
TEST tests/qapi-schema/bad-base.out
TEST tests/qapi-schema/bad-data.out
TEST tests/qapi-schema/bad-ident.out
TEST tests/qapi-schema/bad-type-bool.out
TEST tests/qapi-schema/bad-type-dict.out
TEST tests/qapi-schema/bad-type-int.out
TEST tests/qapi-schema/base-cycle-direct.out
TEST tests/qapi-schema/base-cycle-indirect.out
TEST tests/qapi-schema/command-int.out
TEST tests/qapi-schema/comments.out
TEST tests/qapi-schema/double-data.out
TEST tests/qapi-schema/double-type.out
TEST tests/qapi-schema/duplicate-key.out
TEST tests/qapi-schema/empty.out
TEST tests/qapi-schema/enum-bad-name.out
TEST tests/qapi-schema/enum-bad-prefix.out
TEST tests/qapi-schema/enum-clash-member.out
TEST tests/qapi-schema/enum-dict-member.out
TEST tests/qapi-schema/enum-int-member.out
TEST tests/qapi-schema/enum-member-case.out
TEST tests/qapi-schema/enum-missing-data.out
TEST tests/qapi-schema/enum-wrong-data.out
TEST tests/qapi-schema/escape-outside-string.out
TEST tests/qapi-schema/escape-too-big.out
TEST tests/qapi-schema/escape-too-short.out
TEST tests/qapi-schema/event-boxed-empty.out
TEST tests/qapi-schema/event-case.out
TEST tests/qapi-schema/event-nest-struct.out
TEST tests/qapi-schema/flat-union-array-branch.out
TEST tests/qapi-schema/flat-union-bad-base.out
TEST tests/qapi-schema/flat-union-bad-discriminator.out
TEST tests/qapi-schema/flat-union-base-any.out
TEST tests/qapi-schema/flat-union-base-union.out
TEST tests/qapi-schema/flat-union-clash-member.out
TEST tests/qapi-schema/flat-union-empty.out
TEST tests/qapi-schema/flat-union-incomplete-branch.out
TEST tests/qapi-schema/flat-union-inline.out
TEST tests/qapi-schema/flat-union-int-branch.out
TEST tests/qapi-schema/flat-union-invalid-branch-key.out
TEST tests/qapi-schema/flat-union-invalid-discriminator.out
TEST tests/qapi-schema/flat-union-no-base.out
TEST tests/qapi-schema/flat-union-optional-discriminator.out
TEST tests/qapi-schema/flat-union-string-discriminator.out
TEST tests/qapi-schema/funny-char.out
TEST tests/qapi-schema/ident-with-escape.out
TEST tests/qapi-schema/include-before-err.out
TEST tests/qapi-schema/include-cycle.out
TEST tests/qapi-schema/include-format-err.out
TEST tests/qapi-schema/include-nested-err.out
TEST tests/qapi-schema/include-no-file.out
TEST tests/qapi-schema/include-non-file.out
TEST tests/qapi-schema/include-relpath.out
TEST tests/qapi-schema/include-repetition.out
TEST tests/qapi-schema/include-self-cycle.out
TEST tests/qapi-schema/include-simple.out
TEST tests/qapi-schema/indented-expr.out
TEST tests/qapi-schema/leading-comma-list.out
TEST tests/qapi-schema/leading-comma-object.out
TEST tests/qapi-schema/missing-colon.out
TEST tests/qapi-schema/missing-comma-list.out
TEST tests/qapi-schema/missing-comma-object.out
TEST tests/qapi-schema/missing-type.out
TEST tests/qapi-schema/nested-struct-data.out
TEST tests/qapi-schema/qapi-schema-test.out
TEST tests/qapi-schema/quoted-structural-chars.out
TEST tests/qapi-schema/non-objects.out
TEST tests/qapi-schema/redefined-command.out
TEST tests/qapi-schema/redefined-builtin.out
TEST tests/qapi-schema/redefined-event.out
TEST tests/qapi-schema/redefined-type.out
TEST tests/qapi-schema/reserved-command-q.out
TEST tests/qapi-schema/reserved-enum-q.out
TEST tests/qapi-schema/reserved-member-has.out
TEST tests/qapi-schema/reserved-member-q.out
TEST tests/qapi-schema/reserved-member-u.out
TEST tests/qapi-schema/reserved-member-underscore.out
TEST tests/qapi-schema/reserved-type-kind.out
TEST tests/qapi-schema/reserved-type-list.out
TEST tests/qapi-schema/returns-alternate.out
TEST tests/qapi-schema/returns-array-bad.out
TEST tests/qapi-schema/returns-dict.out
TEST tests/qapi-schema/returns-unknown.out
TEST tests/qapi-schema/returns-whitelist.out
TEST tests/qapi-schema/struct-base-clash-deep.out
TEST tests/qapi-schema/struct-base-clash.out
TEST tests/qapi-schema/struct-data-invalid.out
TEST tests/qapi-schema/struct-member-invalid.out
TEST tests/qapi-schema/trailing-comma-list.out
TEST tests/qapi-schema/trailing-comma-object.out
TEST tests/qapi-schema/type-bypass-bad-gen.out
TEST tests/qapi-schema/unclosed-list.out
TEST tests/qapi-schema/unclosed-object.out
TEST tests/qapi-schema/unclosed-string.out
TEST tests/qapi-schema/unicode-str.out
TEST tests/qapi-schema/union-base-no-discriminator.out
TEST tests/qapi-schema/union-branch-case.out
TEST tests/qapi-schema/union-clash-branches.out
TEST tests/qapi-schema/union-empty.out
TEST tests/qapi-schema/union-invalid-base.out
TEST tests/qapi-schema/union-optional-branch.out
TEST tests/qapi-schema/union-unknown.out
TEST tests/qapi-schema/unknown-escape.out
TEST tests/qapi-schema/unknown-expr-key.out
CC tests/check-qdict.o
CC tests/test-char.o
CC tests/check-qfloat.o
CC tests/check-qint.o
CC tests/check-qstring.o
CC tests/check-qlist.o
CC tests/check-qnull.o
CC tests/check-qjson.o
CC tests/test-qobject-output-visitor.o
GEN tests/test-qapi-visit.c
GEN tests/test-qapi-types.c
GEN tests/test-qapi-event.c
GEN tests/test-qmp-introspect.c
CC tests/test-clone-visitor.o
CC tests/test-qobject-input-visitor.o
CC tests/test-qobject-input-strict.o
CC tests/test-qmp-commands.o
GEN tests/test-qmp-marshal.c
CC tests/test-string-input-visitor.o
CC tests/test-string-output-visitor.o
CC tests/test-qmp-event.o
CC tests/test-opts-visitor.o
CC tests/test-coroutine.o
CC tests/test-visitor-serialization.o
CC tests/test-iov.o
CC tests/test-aio.o
CC tests/test-throttle.o
CC tests/test-thread-pool.o
CC tests/test-hbitmap.o
CC tests/test-blockjob.o
CC tests/test-blockjob-txn.o
CC tests/test-x86-cpuid.o
CC tests/test-xbzrle.o
CC tests/test-vmstate.o
CC tests/test-cutils.o
CC tests/test-mul64.o
CC tests/test-int128.o
CC tests/rcutorture.o
CC tests/test-rcu-list.o
CC tests/test-qdist.o
/tmp/qemu-test/src/tests/test-int128.c:180: warning: ‘__noclone__’ attribute directive ignored
CC tests/test-qht.o
CC tests/qht-bench.o
CC tests/test-qht-par.o
CC tests/test-bitops.o
CC tests/check-qom-interface.o
CC tests/check-qom-proplist.o
CC tests/test-qemu-opts.o
CC tests/test-write-threshold.o
CC tests/test-crypto-hash.o
CC tests/test-crypto-cipher.o
CC tests/test-crypto-secret.o
CC tests/test-qga.o
CC tests/libqtest.o
CC tests/test-timed-average.o
CC tests/test-io-task.o
CC tests/test-io-channel-socket.o
CC tests/io-channel-helpers.o
CC tests/test-io-channel-file.o
CC tests/test-io-channel-command.o
CC tests/test-io-channel-buffer.o
CC tests/test-base64.o
CC tests/test-crypto-ivgen.o
CC tests/test-crypto-afsplit.o
CC tests/test-crypto-xts.o
CC tests/test-crypto-block.o
CC tests/test-logging.o
CC tests/test-bufferiszero.o
CC tests/test-replication.o
CC tests/test-uuid.o
CC tests/ptimer-test.o
CC tests/ptimer-test-stubs.o
CC tests/vhost-user-test.o
CC tests/libqos/pci.o
CC tests/libqos/fw_cfg.o
CC tests/libqos/malloc.o
CC tests/libqos/i2c.o
CC tests/libqos/libqos.o
CC tests/libqos/malloc-spapr.o
CC tests/libqos/libqos-spapr.o
CC tests/libqos/rtas.o
CC tests/libqos/pci-spapr.o
CC tests/libqos/pci-pc.o
CC tests/libqos/malloc-pc.o
CC tests/libqos/libqos-pc.o
CC tests/libqos/ahci.o
CC tests/libqos/virtio.o
CC tests/libqos/virtio-pci.o
CC tests/libqos/virtio-mmio.o
CC tests/libqos/malloc-generic.o
CC tests/endianness-test.o
CC tests/fdc-test.o
CC tests/ide-test.o
CC tests/ahci-test.o
CC tests/hd-geo-test.o
CC tests/boot-order-test.o
CC tests/bios-tables-test.o
CC tests/boot-sector.o
CC tests/boot-serial-test.o
CC tests/pxe-test.o
CC tests/rtc-test.o
CC tests/ipmi-kcs-test.o
CC tests/ipmi-bt-test.o
CC tests/i440fx-test.o
CC tests/fw_cfg-test.o
CC tests/drive_del-test.o
CC tests/wdt_ib700-test.o
CC tests/tco-test.o
CC tests/e1000-test.o
CC tests/e1000e-test.o
/tmp/qemu-test/src/tests/ide-test.c: In function ‘cdrom_pio_impl’:
/tmp/qemu-test/src/tests/ide-test.c:791: warning: ignoring return value of ‘fwrite’, declared with attribute warn_unused_result
/tmp/qemu-test/src/tests/ide-test.c: In function ‘test_cdrom_dma’:
/tmp/qemu-test/src/tests/ide-test.c:886: warning: ignoring return value of ‘fwrite’, declared with attribute warn_unused_result
CC tests/rtl8139-test.o
CC tests/pcnet-test.o
CC tests/eepro100-test.o
CC tests/ne2000-test.o
CC tests/nvme-test.o
CC tests/ac97-test.o
CC tests/es1370-test.o
CC tests/virtio-net-test.o
CC tests/virtio-balloon-test.o
CC tests/virtio-blk-test.o
CC tests/virtio-rng-test.o
CC tests/virtio-serial-test.o
CC tests/virtio-scsi-test.o
CC tests/virtio-console-test.o
CC tests/tpci200-test.o
CC tests/ipoctal232-test.o
CC tests/display-vga-test.o
CC tests/intel-hda-test.o
CC tests/ivshmem-test.o
CC tests/vmxnet3-test.o
CC tests/pvpanic-test.o
CC tests/i82801b11-test.o
CC tests/ioh3420-test.o
CC tests/usb-hcd-ohci-test.o
CC tests/libqos/usb.o
CC tests/usb-hcd-uhci-test.o
CC tests/usb-hcd-ehci-test.o
CC tests/usb-hcd-xhci-test.o
CC tests/pc-cpu-test.o
CC tests/q35-test.o
CC tests/test-netfilter.o
CC tests/test-filter-mirror.o
CC tests/test-filter-redirector.o
CC tests/postcopy-test.o
CC tests/test-x86-cpuid-compat.o
CC tests/device-introspect-test.o
make: *** No rule to make target `check-simpleqtest-x86_64', needed by `check-simpleqtest'. Stop.
make: *** Waiting for unfinished jobs....
CC tests/qom-test.o
make[1]: *** [docker-run] Error 2
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-fmoi6289/src'
make: *** [docker-run-test-quick@centos6] Error 2
=== OUTPUT END ===
Test command exited with code: 2
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-devel@freelists.org
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines'
2016-11-22 1:11 [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Eduardo Habkost
` (16 preceding siblings ...)
2016-11-22 1:36 ` no-reply
@ 2016-11-22 8:18 ` David Hildenbrand
2016-11-22 13:09 ` Eduardo Habkost
2016-11-22 22:34 ` Eduardo Habkost
2016-11-23 16:43 ` [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Marcel Apfelbaum
19 siblings, 1 reply; 43+ messages in thread
From: David Hildenbrand @ 2016-11-22 8:18 UTC (permalink / raw)
To: Eduardo Habkost, qemu-devel, Markus Armbruster, Marcel Apfelbaum,
Michael S. Tsirkin
Cc: libvir-list, Laine Stump
>
> Considered alternatives
> =======================
>
> Indirect mapping (machine => bus => device)
> -------------------------------------------
>
> This RFC implements a mechanism to implement ax
> machine-type => supported-device-types
> mapping. An alternative solution I considered was to expose an
> indirect mapping:
> machine-type => default-bus-types
> followed by
> bus-type => supported-device-types.
>
> But exposing only the resulting supported device-types list
> imposes less restrictions on how the device and bus type
> hierarchy is implemented inside QEMU. There's still a
> machine-type => bus-type => device-type
> mapping implemented internally, but it is an implementation
> detail on the current version, and not part of the
> externally-visible interface.
>
> The Implementation
> ==================
>
> This add a new field to MachineClass: default_bus_types, and a
> new field to BusClass: supported_device_type.
Is it possible to modify a machine (setting some properties e.g. on the
command line), that suddenly more devices are supported? Something like
enabling an additional bus? (I assume so, because it is called "default
bus types" :) )
If so, the indirect mapping could be of more benefit in the long run.
Thinking about my machine at home:
I just care about the available buses. If my machine doesn't have USB,
but PCI, I can buy a USB PCI card and make it support USB. Then I can
happily plug in USB devices. So the "default" state might at least
no longer be sufficient when wanting to plug in a USB fan on a hot
summer day ;) .
But, with the indirect mapping, I guess we would need yet another qmp
command ...
--
David
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines'
2016-11-22 8:18 ` David Hildenbrand
@ 2016-11-22 13:09 ` Eduardo Habkost
0 siblings, 0 replies; 43+ messages in thread
From: Eduardo Habkost @ 2016-11-22 13:09 UTC (permalink / raw)
To: David Hildenbrand
Cc: qemu-devel, Markus Armbruster, Marcel Apfelbaum,
Michael S. Tsirkin, libvir-list, Laine Stump
On Tue, Nov 22, 2016 at 09:18:21AM +0100, David Hildenbrand wrote:
>
> >
> > Considered alternatives
> > =======================
> >
> > Indirect mapping (machine => bus => device)
> > -------------------------------------------
> >
> > This RFC implements a mechanism to implement ax
> > machine-type => supported-device-types
> > mapping. An alternative solution I considered was to expose an
> > indirect mapping:
> > machine-type => default-bus-types
> > followed by
> > bus-type => supported-device-types.
> >
> > But exposing only the resulting supported device-types list
> > imposes less restrictions on how the device and bus type
> > hierarchy is implemented inside QEMU. There's still a
> > machine-type => bus-type => device-type
> > mapping implemented internally, but it is an implementation
> > detail on the current version, and not part of the
> > externally-visible interface.
> >
> > The Implementation
> > ==================
> >
> > This add a new field to MachineClass: default_bus_types, and a
> > new field to BusClass: supported_device_type.
>
> Is it possible to modify a machine (setting some properties e.g. on the
> command line), that suddenly more devices are supported? Something like
> enabling an additional bus? (I assume so, because it is called "default
> bus types" :) )
Yes. See the "Out of scope: Configurable buses" section on the
cover letter.
>
> If so, the indirect mapping could be of more benefit in the long run.
Yes, a new mapping may be necessary to find out which options
(e.g. "usb=on") or device-types (e.g. "-device isa-fdc", "-device
piix3-usb-uhci") will add new buses and make new device-types
supported by the machine. But this will probably require new QMP
commands, and I still want to keep the default case simple.
>
> Thinking about my machine at home:
>
> I just care about the available buses. If my machine doesn't have USB,
> but PCI, I can buy a USB PCI card and make it support USB. Then I can
> happily plug in USB devices. So the "default" state might at least
> no longer be sufficient when wanting to plug in a USB fan on a hot
> summer day ;) .
>
> But, with the indirect mapping, I guess we would need yet another qmp
> command ...
>
> --
>
> David
--
Eduardo
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] [RFC 05/15] tests: Add rules to non-gtester qtest test cases
2016-11-22 1:12 ` [Qemu-devel] [RFC 05/15] tests: Add rules to non-gtester qtest test cases Eduardo Habkost
@ 2016-11-22 13:34 ` Eduardo Habkost
0 siblings, 0 replies; 43+ messages in thread
From: Eduardo Habkost @ 2016-11-22 13:34 UTC (permalink / raw)
To: qemu-devel, Markus Armbruster, Marcel Apfelbaum, Michael S. Tsirkin
On Mon, Nov 21, 2016 at 11:12:03PM -0200, Eduardo Habkost wrote:
[...]
> +define qtest-target =
This breaks on old GNU Make versions. Both patchew and travis-ci reported
similar errors:
make: *** No rule to make target `check-simpleqtest-x86_64', needed by
`check-simpleqtest'. Stop.
Old make versions don't seem to like the "=" operator after "define VAR".
Fixed by:
diff --git a/tests/Makefile.include b/tests/Makefile.include
index 7016737..2799b16 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -808,7 +808,7 @@ SIMPLETEST_OPTIONS = $(if $(V),--verbose,--quiet)
# $(check-simpleqtest-$(ARCH)-y) automatically includes
# $(check-simpleqtest-generic-y)
-define qtest-target =
+define qtest-target
check-simpleqtest-$(1)-y += $$(check-simpleqtest-generic-y)
--
Eduardo
^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines'
2016-11-22 1:11 [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Eduardo Habkost
` (17 preceding siblings ...)
2016-11-22 8:18 ` David Hildenbrand
@ 2016-11-22 22:34 ` Eduardo Habkost
2016-11-23 17:10 ` [Qemu-devel] -nodefaults and available buses (was Re: [RFC 00/15] qmp: Report supported device types on 'query-machines') Eduardo Habkost
2016-11-23 16:43 ` [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Marcel Apfelbaum
19 siblings, 1 reply; 43+ messages in thread
From: Eduardo Habkost @ 2016-11-22 22:34 UTC (permalink / raw)
To: qemu-devel, Markus Armbruster, Marcel Apfelbaum, Michael S. Tsirkin
Cc: Alexey Kardashevskiy, Andrea Bolognani, David Gibson,
Michael Roth, libvir-list, Greg Kurz, Alex Williamson, qemu-ppc,
Paolo Bonzini, Laine Stump, Eric Blake
(CCing people from the spapr PCI-express thread)
On Mon, Nov 21, 2016 at 11:11:58PM -0200, Eduardo Habkost wrote:
> The Problem
> ===========
>
> Currently management software has no way to find out which device
> types can be plugged in a machine, unless the machine is already
> initialized.
>
> Even after the machine is initialized, there's no way to map
> existing bus types to supported device types unless management
> software hardcodes the mapping between bus types and device
> types.
>
> Example: floppy support on q35 vs i440fx
> ----------------------------------------
>
> There's no way for libvirt to find out that there's no floppy
> controller on pc-q35-* machine-types by default.
>
> With this series, pc-i440fx-* will report "floppy" as a supported
> device type, but pc-q35-* will not.
>
> Example: Legacy PCI vs vs PCIe devices
> --------------------------------------
>
> Some devices require a PCIe bus to be available, others work on
> both legacy PCI and PCIe, while others work only on a legacy PCI
> bus.
>
> Currently management software has no way to know which devices
> can be added to a given machine, unless it hardcodes machine-type
> names and device-types names.
Another example:
spapr and PCIe root bus
-----------------------
See the thread at:
Subject: [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default
If we mak new spapr machine-type versions create a PCIe root bus,
management software will need a way to find out:
1) The type of the default bus for the machine type;
2) The ID of the default bus for the machine type.
Otherwise, management software will have to hardcode it based on
machine-type version. The proposed interface should solve this
problem.
There are other comment below, at "Limitations" section:
>
> The Proposed Interface
> ======================
>
> This series adds a new field to the output of 'query-machines':
> 'supported-device-types'. It will contain a list of QOM type
> names, that can be used to find the list of device types that can
> be plugged in the machine by default. The type names reported on
> the new field can then be used as the 'implements' argument on
> the 'qom-list-types' command, to find out which device types can
> be plugged on the machine.
>
> Example output
> --------------
>
> (QEMU) query-machines
> {
> "return": [
> [...]
> {
> "supported-device-types": [
> "sys-bus-device"
> ],
> "cpu-max": 1,
> "hotpluggable-cpus": false,
> "name": "none"
> },
> [...]
> {
> "supported-device-types": [
> "sys-bus-device"
> ],
> "cpu-max": 1,
> "hotpluggable-cpus": false,
> "name": "xenpv"
> },
> [...]
> {
> "supported-device-types": [
> "sys-bus-device",
> "floppy",
> "i2c-slave",
> "pci-device",
> "isa-device",
> "ide-device"
> ],
> "name": "pc-i440fx-2.8",
> "alias": "pc",
> "is-default": true,
> "cpu-max": 255,
> "hotpluggable-cpus": true
> },
> [...]
> {
> "supported-device-types": [
> "sys-bus-device",
> "floppy",
> "isa-device",
> "ide-device"
> ],
> "cpu-max": 1,
> "hotpluggable-cpus": true,
> "name": "isapc"
> },
> [...]
> {
> "supported-device-types": [
> "sys-bus-device",
> "floppy",
> "i2c-slave",
> "pci-device",
> "isa-device",
> "ide-device"
> ],
> "cpu-max": 128,
> "hotpluggable-cpus": true,
> "name": "xenfv"
> },
> [...]
> {
> "alias": "q35",
> "supported-device-types": [
> "sys-bus-device",
> "i2c-slave",
> "PCIE-device",
> "isa-device",
> "ide-device"
> ],
> "cpu-max": 288,
> "hotpluggable-cpus": true,
> "name": "pc-q35-2.8"
> },
> [...]
> ]
> }
>
> Considered alternatives
> =======================
>
> Indirect mapping (machine => bus => device)
> -------------------------------------------
>
> This RFC implements a mechanism to implement ax
> machine-type => supported-device-types
> mapping. An alternative solution I considered was to expose an
> indirect mapping:
> machine-type => default-bus-types
> followed by
> bus-type => supported-device-types.
>
> But exposing only the resulting supported device-types list
> imposes less restrictions on how the device and bus type
> hierarchy is implemented inside QEMU. There's still a
> machine-type => bus-type => device-type
> mapping implemented internally, but it is an implementation
> detail on the current version, and not part of the
> externally-visible interface.
>
> The Implementation
> ==================
>
> This add a new field to MachineClass: default_bus_types, and a
> new field to BusClass: supported_device_type.
>
> The two fields are used to build the list of supported device
> types for a given machine. On most cases, the normal QOM type
> hierarchy is used to define the set of supported devices for a
> bus. On the case of PCIe buses, a INTERFACE_PCIE_DEVICE interface
> name was introduced, to indicate PCIe-capable devices.
>
> This means we are duplicating information in some cases:
>
> * BusClass::supported_device_type duplicates knowlege that is
> already encoded in DeviceClass::bus_type.
>
> To make sure both fields agree with each other, a new
> device_class_set_bus_type() wrapper was added, to perform
> additional validation.
>
> * MachineClass::default_bus_type duplicates knowledge that is
> already encoded in the machine init function.
>
> To make sure the information is correct, a qmp-machine-info.py
> test case is added, that will validate the
> supported-device-types field based on the buses created by the
> machine.
>
> * PCIDeviceClass::is_express and INTERFACE_PCIE_DEVICE
> both encode the same information about a PCI device class.
>
> A future version of this series may include a
> class_base_post_init hook that will allow TYPE_PCI_DEVICE to
> validate/update is_express and the interface list to ensure
> both are always consistent.
>
> Test Code
> ---------
>
> qdev-based test code for the new field was implemented in a
> Python script. Some extra support was implemented in
> tests/Makefile.include, scripts/qemu.py and scripts/qtest.py to
> allow the test to be implemented.
>
> Limitations
> ===========
>
"default defaults" vs "-nodefault defaults"
-------------------------------------------
Two bad news:
1) We need to differentiate buses created by the machine with
"-nodefaults" and buses that are created only without
"-nodefaults".
libvirt use -nodefaults when starting QEMU, so knowing which
buses are available when using -nodefaults is more interesting
for them.
Other software, on the other hand, might be interested in the
results without -nodefaults.
We need to be able model both cases in the new interface.
Suggestions are welcome.
2) A lot of machine-types won't start if using
"-nodefaults -machine <machine>" without any extra devices or
drives.
Lots of machines require some drives or devices to be created
(especially ARM machines that require a SD drive to be
available).
Some machines will make QEMU exit, some of them simply segfault.
I am looking for ways to work around it so we can still validate
-nodefaults-based info on the test code.
Out of scope (in this version): bus IDs
---------------------------------------
This series only returns info about supported device-types, but I
plan to also report the bus IDs on a new version of this series.
Knowing the bus IDs for a machine is also important for
management software. (See spapr + PCIe root bus
example above.)
Additional comment about PCIe below:
> TYPE_SYS_BUS_DEVICE is too generic
> ----------------------------------
>
> Currently all machines have a TYPE_SYS_BUS bus, meaning all
> TYPE_SYS_BUS_DEVICE subclasses are reported as supported.
>
> The current solution in this series is to report
> TYPE_SYS_BUS_DEVICE as supported by all machines. But we could
> gradually add arch-specific or machine-family-specific interface
> names that can be used on devices that are meant to work with
> only a subset of TYPE_SYS_BUS_DEVICE subclasses.
>
> A future version of this series may remove TYPE_SYS_BUS_DEVICE
> from the supported-device-types output, and return a
> arch-specific or machine-family-specific interface name to
> restrict management software to a subset of TYPE_SYS_BUS_DEVICE
> subclasses.
>
> PCI vs PCIe
> -----------
>
> Machines with PCIe buses will report INTERFACE_PCIE_DEVICE on
> supported-device-types.
>
> Machines with legacy PCI buses will report TYPE_PCI_DEVICE on
> supported-device-types.
>
> The problem with the current approach is that PCIe devices are
> TYPE_PCI_DEVICE subclasses. The allows PCI device classes to
> indicate they are PCIe-capable, but there's no obvious way to
> indicate that a device is PCIe-only. This needs to be addressed
> in a future version of this series.
>
> Suggestions are welcome.
I found out that this is a bit more complicated: not all
TYPE_PCIE_BUS instances are created equal. Some of them will
accept only PCIe devices, some of them can accept legacy PCI
devices.
The QMP interface I'm proposing shouldn't be affected by this,
but the implementation needs to be changed, as it is currently
based on an indirect
machine-type => bus-types => device-types
mapping, and a simple bus-type => device-type mapping won't work
for PCIe. Probably I will replace MachineClass::default_buses
with a MachineClass::default_device_types field. The
'device-type' QOM property behavior will probably change too, so
each PCIe bus can report an appropriate device type as supported.
>
> Incomplete bus lists on some machines
> -------------------------------------
>
> With this series, not all machines classes are changed to add the
> full list of device types on the 'supported-device-types'. To
> allow the code to be updated gradually, qmp-machine-info.py has a
> STRICT_ARCHES variable, that will make the test code require a
> complete device type list only on some architectures.
>
> Out of scope: Configurable buses
> --------------------------------
>
> There's no way to map machine options like "usb=on|off" to
> device-types or buses. I plan to propose a new interface that
> allows machine options to be mapped to buses/device-types later.
>
> Out of scope: Deciding where to plug devices
> --------------------------------------------
>
> Once management software discovers which devices can be plugged
> to a machine, it still has to discover or define where devices
> can/should/will be plugged. This is out of the scope of this
> series.
>
> Out of scope: Hotplug
> ---------------------
>
> The proposed interface is supposed to help management software
> find which device types can be used when creating the VM. Device
> hotplug is out of the scope of this series. However, the new
> 'device-types' QOM property on bus objects could be used to find
> out which device types can be plugged on the existing buses.
>
> ---
> Cc: libvir-list@redhat.com
> Cc: Laine Stump <laine@redhat.com>
>
> Eduardo Habkost (15):
> qemu.py: Make logging optional
> qtest.py: Support QTEST_LOG environment variable
> qtest.py: make logging optional
> qtest.py: Make 'binary' parameter optional
> tests: Add rules to non-gtester qtest test cases
> qdev: Add device_type field to BusClass
> machine: Add MachineClass::default_buses field
> qmp: Add 'supported-device-types' field to 'query-machines'
> pci: Introduce INTERFACE_PCIE_DEVICE interface name
> pc: Initialize default bus lists
> s390x: Initialize default bus lists
> arm: Initialize default bus lists
> mips: Initialize default bus lists
> ppc: Initialize default bus lists
> qdev: Add device_class_set_bus_type() function
>
> hw/arm/aspeed.c | 2 +
> hw/arm/collie.c | 1 +
> hw/arm/cubieboard.c | 1 +
> hw/arm/exynos4_boards.c | 5 ++
> hw/arm/gumstix.c | 7 ++
> hw/arm/highbank.c | 4 ++
> hw/arm/imx25_pdk.c | 1 +
> hw/arm/kzm.c | 1 +
> hw/arm/musicpal.c | 1 +
> hw/arm/nseries.c | 2 +
> hw/arm/palm.c | 1 +
> hw/arm/realview.c | 1 +
> hw/arm/spitz.c | 10 +++
> hw/arm/stellaris.c | 4 ++
> hw/audio/intel-hda.c | 9 ++-
> hw/block/fdc.c | 17 +++--
> hw/block/nvme.c | 4 ++
> hw/char/virtio-serial-bus.c | 3 +-
> hw/core/bus.c | 9 +++
> hw/core/machine.c | 18 ++++-
> hw/core/qdev.c | 8 +++
> hw/core/sysbus.c | 3 +-
> hw/i2c/core.c | 9 ++-
> hw/i386/pc_piix.c | 13 ++++
> hw/i386/pc_q35.c | 4 ++
> hw/ide/qdev.c | 3 +-
> hw/input/adb.c | 9 ++-
> hw/ipack/ipack.c | 9 ++-
> hw/isa/isa-bus.c | 3 +-
> hw/mips/mips_malta.c | 7 ++
> hw/mips/mips_r4k.c | 2 +
> hw/misc/auxbus.c | 3 +-
> hw/net/e1000e.c | 4 ++
> hw/net/vmxnet3.c | 4 ++
> hw/pci-bridge/ioh3420.c | 4 ++
> hw/pci-bridge/xio3130_downstream.c | 4 ++
> hw/pci/pci.c | 16 ++++-
> hw/ppc/e500plat.c | 3 +
> hw/ppc/mac_newworld.c | 4 ++
> hw/ppc/mac_oldworld.c | 3 +
> hw/ppc/mpc8544ds.c | 4 ++
> hw/ppc/ppc440_bamboo.c | 1 +
> hw/ppc/prep.c | 4 ++
> hw/ppc/spapr_vio.c | 3 +-
> hw/s390x/css-bridge.c | 2 +
> hw/s390x/event-facility.c | 3 +-
> hw/s390x/s390-pci-bus.c | 9 ++-
> hw/s390x/s390-virtio-ccw.c | 6 ++
> hw/s390x/virtio-ccw.c | 2 +-
> hw/scsi/megasas.c | 7 ++
> hw/scsi/scsi-bus.c | 3 +-
> hw/scsi/vmw_pvscsi.c | 1 +
> hw/sd/core.c | 7 ++
> hw/sd/sd.c | 2 +-
> hw/ssi/ssi.c | 9 ++-
> hw/usb/bus.c | 3 +-
> hw/usb/dev-smartcard-reader.c | 9 ++-
> hw/usb/hcd-xhci.c | 4 ++
> hw/vfio/pci.c | 4 ++
> hw/virtio/virtio-bus.c | 1 +
> hw/virtio/virtio-pci.c | 4 ++
> hw/virtio/virtio.c | 2 +-
> include/hw/boards.h | 5 ++
> include/hw/pci/pci.h | 3 +
> include/hw/qdev-core.h | 4 ++
> qapi-schema.json | 9 ++-
> scripts/qemu.py | 25 +++++--
> scripts/qtest.py | 15 +++-
> tests/Makefile.include | 39 ++++++++++-
> tests/qmp-machine-info.py | 138 +++++++++++++++++++++++++++++++++++++
> vl.c | 11 +++
> 71 files changed, 518 insertions(+), 37 deletions(-)
> create mode 100755 tests/qmp-machine-info.py
>
> --
> 2.7.4
>
--
Eduardo
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] [RFC 14/15] ppc: Initialize default bus lists
2016-11-22 1:12 ` [Qemu-devel] [RFC 14/15] ppc: " Eduardo Habkost
@ 2016-11-23 3:42 ` Alexey Kardashevskiy
0 siblings, 0 replies; 43+ messages in thread
From: Alexey Kardashevskiy @ 2016-11-23 3:42 UTC (permalink / raw)
To: Eduardo Habkost, qemu-devel, Markus Armbruster, Marcel Apfelbaum,
Michael S. Tsirkin
Cc: Scott Wood, qemu-ppc, Alexander Graf, David Gibson
On 22/11/16 12:12, Eduardo Habkost wrote:
> Populate default_bus_types for some machines. Work in progress, I
> didn't check if all machines were converted (so we could enable
Yup, pseries is missed here.
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index c3269c7..ab5939e 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2692,6 +2692,9 @@ static void spapr_machine_class_init(ObjectClass *oc,
void *data)
fwc->get_dev_path = spapr_get_fw_dev_path;
nc->nmi_monitor_handler = spapr_nmi;
smc->phb_placement = spapr_phb_placement;
+
+ machine_class_add_default_bus(mc, TYPE_PCI_BUS);
+ machine_class_add_default_bus(mc, TYPE_SPAPR_VIO_BUS);
}
static const TypeInfo spapr_machine_info = {
> strict mode for ppci in qmp-machine-info.py).
>
> Cc: Alexander Graf <agraf@suse.de>
> Cc: Scott Wood <scottwood@freescale.com>
> Cc: David Gibson <david@gibson.dropbear.id.au>
> Cc: qemu-ppc@nongnu.org
> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> ---
> hw/ppc/e500plat.c | 3 +++
> hw/ppc/mac_newworld.c | 4 ++++
> hw/ppc/mac_oldworld.c | 3 +++
> hw/ppc/mpc8544ds.c | 4 ++++
> hw/ppc/ppc440_bamboo.c | 1 +
> hw/ppc/prep.c | 4 ++++
> 6 files changed, 19 insertions(+)
--
Alexey
^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines'
2016-11-22 1:11 [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Eduardo Habkost
` (18 preceding siblings ...)
2016-11-22 22:34 ` Eduardo Habkost
@ 2016-11-23 16:43 ` Marcel Apfelbaum
2016-11-23 17:35 ` Eduardo Habkost
19 siblings, 1 reply; 43+ messages in thread
From: Marcel Apfelbaum @ 2016-11-23 16:43 UTC (permalink / raw)
To: Eduardo Habkost, qemu-devel, Markus Armbruster, Michael S. Tsirkin
Cc: libvir-list, Laine Stump
On 11/22/2016 03:11 AM, Eduardo Habkost wrote:
> The Problem
> ===========
>
> Currently management software has no way to find out which device
> types can be plugged in a machine, unless the machine is already
> initialized.
>
Hi Eduardo,
Thank you for this interesting series. I think this is a problem
worth addressing.
> Even after the machine is initialized, there's no way to map
> existing bus types to supported device types unless management
> software hardcodes the mapping between bus types and device
> types.
>
Here I am a little lost.
We are going for machine => supported devices or
bus-type => supported devices?
> Example: floppy support on q35 vs i440fx
> ----------------------------------------
>
> There's no way for libvirt to find out that there's no floppy
> controller on pc-q35-* machine-types by default.
>
Again "by default". So do we want to query the init state of a machine?
What devices are there? Or what devices *can be* there?
> With this series, pc-i440fx-* will report "floppy" as a supported
> device type, but pc-q35-* will not.
>
> Example: Legacy PCI vs vs PCIe devices
> --------------------------------------
>
> Some devices require a PCIe bus to be available, others work on
> both legacy PCI and PCIe, while others work only on a legacy PCI
> bus.
>
> Currently management software has no way to know which devices
> can be added to a given machine, unless it hardcodes machine-type
> names and device-types names.
>
Again it seems a double problem, machine => devices vs pci/pcie bus => devices.
The bus => devices match is not related to a machine type.
> The Proposed Interface
> ======================
>
> This series adds a new field to the output of 'query-machines':
> 'supported-device-types'. It will contain a list of QOM type
> names, that can be used to find the list of device types that can
> be plugged in the machine by default.
What do you mean "by default"? Without bridges or part of the machine itself?
The type names reported on
> the new field can then be used as the 'implements' argument on
> the 'qom-list-types' command, to find out which device types can
> be plugged on the machine.
>
> Example output
> --------------
>
> (QEMU) query-machines
> {
> "return": [
> [...]
> {
> "supported-device-types": [
> "sys-bus-device"
I don't know how "sys-bus-device" can help us... :)
> ],
> "cpu-max": 1,
> "hotpluggable-cpus": false,
> "name": "none"
> },
> [...]
> {
> "supported-device-types": [
> "sys-bus-device"
> ],
> "cpu-max": 1,
> "hotpluggable-cpus": false,
> "name": "xenpv"
> },
> [...]
> {
> "supported-device-types": [
> "sys-bus-device",
> "floppy",
> "i2c-slave",
> "pci-device",
> "isa-device",
> "ide-device"
Is don't know is this high level classification is useful,
here is an example:
pvi-device is supported => then we look for all pci devices?
But what if some pci devices make sense on a machine type,
but not on another?
> ],
> "name": "pc-i440fx-2.8",
> "alias": "pc",
> "is-default": true,
> "cpu-max": 255,
> "hotpluggable-cpus": true
> },
> [...]
> {
> "supported-device-types": [
> "sys-bus-device",
> "floppy",
> "isa-device",
> "ide-device"
> ],
> "cpu-max": 1,
> "hotpluggable-cpus": true,
> "name": "isapc"
> },
> [...]
> {
> "supported-device-types": [
> "sys-bus-device",
> "floppy",
> "i2c-slave",
> "pci-device",
> "isa-device",
> "ide-device"
> ],
> "cpu-max": 128,
> "hotpluggable-cpus": true,
> "name": "xenfv"
> },
> [...]
> {
> "alias": "q35",
> "supported-device-types": [
> "sys-bus-device",
> "i2c-slave",
> "PCIE-device",
> "isa-device",
> "ide-device"
> ],
> "cpu-max": 288,
> "hotpluggable-cpus": true,
> "name": "pc-q35-2.8"
> },
> [...]
> ]
> }
>
> Considered alternatives
> =======================
>
> Indirect mapping (machine => bus => device)
> -------------------------------------------
>
> This RFC implements a mechanism to implement ax
> machine-type => supported-device-types
> mapping. An alternative solution I considered was to expose an
> indirect mapping:
> machine-type => default-bus-types
> followed by
> bus-type => supported-device-types.
>
As I previously stated, I don't know if it helps. bus-type
can support different devices on different archs.
> But exposing only the resulting supported device-types list
> imposes less restrictions on how the device and bus type
> hierarchy is implemented inside QEMU. There's still a
> machine-type => bus-type => device-type
> mapping implemented internally, but it is an implementation
> detail on the current version, and not part of the
> externally-visible interface.
>
Good, I personally don't like this "pass".
> The Implementation
> ==================
>
> This add a new field to MachineClass: default_bus_types, and a
> new field to BusClass: supported_device_type.
>
> The two fields are used to build the list of supported device
> types for a given machine. On most cases, the normal QOM type
> hierarchy is used to define the set of supported devices for a
> bus. On the case of PCIe buses, a INTERFACE_PCIE_DEVICE interface
> name was introduced, to indicate PCIe-capable devices.
>
> This means we are duplicating information in some cases:
>
> * BusClass::supported_device_type duplicates knowlege that is
> already encoded in DeviceClass::bus_type.
>
> To make sure both fields agree with each other, a new
> device_class_set_bus_type() wrapper was added, to perform
> additional validation.
>
> * MachineClass::default_bus_type duplicates knowledge that is
> already encoded in the machine init function.
>
> To make sure the information is correct, a qmp-machine-info.py
> test case is added, that will validate the
> supported-device-types field based on the buses created by the
> machine.
>
> * PCIDeviceClass::is_express and INTERFACE_PCIE_DEVICE
> both encode the same information about a PCI device class.
>
> A future version of this series may include a
> class_base_post_init hook that will allow TYPE_PCI_DEVICE to
> validate/update is_express and the interface list to ensure
> both are always consistent.
>
> Test Code
> ---------
>
> qdev-based test code for the new field was implemented in a
> Python script. Some extra support was implemented in
> tests/Makefile.include, scripts/qemu.py and scripts/qtest.py to
> allow the test to be implemented.
>
> Limitations
> ===========
>
> TYPE_SYS_BUS_DEVICE is too generic
> ----------------------------------
>
> Currently all machines have a TYPE_SYS_BUS bus, meaning all
> TYPE_SYS_BUS_DEVICE subclasses are reported as supported.
>
Agreed, this is a problem.
> The current solution in this series is to report
> TYPE_SYS_BUS_DEVICE as supported by all machines. But we could
> gradually add arch-specific or machine-family-specific interface
> names that can be used on devices that are meant to work with
> only a subset of TYPE_SYS_BUS_DEVICE subclasses.
>
> A future version of this series may remove TYPE_SYS_BUS_DEVICE
> from the supported-device-types output, and return a
> arch-specific or machine-family-specific interface name to
> restrict management software to a subset of TYPE_SYS_BUS_DEVICE
> subclasses.
>
> PCI vs PCIe
> -----------
>
> Machines with PCIe buses will report INTERFACE_PCIE_DEVICE on
> supported-device-types.
>
> Machines with legacy PCI buses will report TYPE_PCI_DEVICE on
> supported-device-types.
>
> The problem with the current approach is that PCIe devices are
> TYPE_PCI_DEVICE subclasses. The allows PCI device classes to
> indicate they are PCIe-capable, but there's no obvious way to
> indicate that a device is PCIe-only. This needs to be addressed
> in a future version of this series.
>
> Suggestions are welcome.
As we talked offline, I personally like an interface IPCIType
with a field having 3 possible values {pci/pcie/hybrid}
To understand how hybrid works we need some rules, like
"pci on pci bus/pcie on pcie bus"
"pcie on a non-root pcie bus/pcie otherwise
I don't think we'll have a lot of rules, simple boolean fields
for the interface should be enough.
This still does not solve the problem that some devices makes
sense only on a specific arch.
>
> Incomplete bus lists on some machines
> -------------------------------------
>
> With this series, not all machines classes are changed to add the
> full list of device types on the 'supported-device-types'. To
> allow the code to be updated gradually, qmp-machine-info.py has a
> STRICT_ARCHES variable, that will make the test code require a
> complete device type list only on some architectures.
>
> Out of scope: Configurable buses
> --------------------------------
>
> There's no way to map machine options like "usb=on|off" to
> device-types or buses. I plan to propose a new interface that
> allows machine options to be mapped to buses/device-types later.
>
> Out of scope: Deciding where to plug devices
> --------------------------------------------
>
> Once management software discovers which devices can be plugged
> to a machine, it still has to discover or define where devices
> can/should/will be plugged. This is out of the scope of this
> series.
>
That's a pitty :(
I was hoping this series will solve this issue. But if it prepares
the grounds for it is also a good step .
Thanks,
Marcel
> Out of scope: Hotplug
> ---------------------
>
> The proposed interface is supposed to help management software
> find which device types can be used when creating the VM. Device
> hotplug is out of the scope of this series. However, the new
> 'device-types' QOM property on bus objects could be used to find
> out which device types can be plugged on the existing buses.
>
> ---
> Cc: libvir-list@redhat.com
> Cc: Laine Stump <laine@redhat.com>
>
> Eduardo Habkost (15):
> qemu.py: Make logging optional
> qtest.py: Support QTEST_LOG environment variable
> qtest.py: make logging optional
> qtest.py: Make 'binary' parameter optional
> tests: Add rules to non-gtester qtest test cases
> qdev: Add device_type field to BusClass
> machine: Add MachineClass::default_buses field
> qmp: Add 'supported-device-types' field to 'query-machines'
> pci: Introduce INTERFACE_PCIE_DEVICE interface name
> pc: Initialize default bus lists
> s390x: Initialize default bus lists
> arm: Initialize default bus lists
> mips: Initialize default bus lists
> ppc: Initialize default bus lists
> qdev: Add device_class_set_bus_type() function
>
> hw/arm/aspeed.c | 2 +
> hw/arm/collie.c | 1 +
> hw/arm/cubieboard.c | 1 +
> hw/arm/exynos4_boards.c | 5 ++
> hw/arm/gumstix.c | 7 ++
> hw/arm/highbank.c | 4 ++
> hw/arm/imx25_pdk.c | 1 +
> hw/arm/kzm.c | 1 +
> hw/arm/musicpal.c | 1 +
> hw/arm/nseries.c | 2 +
> hw/arm/palm.c | 1 +
> hw/arm/realview.c | 1 +
> hw/arm/spitz.c | 10 +++
> hw/arm/stellaris.c | 4 ++
> hw/audio/intel-hda.c | 9 ++-
> hw/block/fdc.c | 17 +++--
> hw/block/nvme.c | 4 ++
> hw/char/virtio-serial-bus.c | 3 +-
> hw/core/bus.c | 9 +++
> hw/core/machine.c | 18 ++++-
> hw/core/qdev.c | 8 +++
> hw/core/sysbus.c | 3 +-
> hw/i2c/core.c | 9 ++-
> hw/i386/pc_piix.c | 13 ++++
> hw/i386/pc_q35.c | 4 ++
> hw/ide/qdev.c | 3 +-
> hw/input/adb.c | 9 ++-
> hw/ipack/ipack.c | 9 ++-
> hw/isa/isa-bus.c | 3 +-
> hw/mips/mips_malta.c | 7 ++
> hw/mips/mips_r4k.c | 2 +
> hw/misc/auxbus.c | 3 +-
> hw/net/e1000e.c | 4 ++
> hw/net/vmxnet3.c | 4 ++
> hw/pci-bridge/ioh3420.c | 4 ++
> hw/pci-bridge/xio3130_downstream.c | 4 ++
> hw/pci/pci.c | 16 ++++-
> hw/ppc/e500plat.c | 3 +
> hw/ppc/mac_newworld.c | 4 ++
> hw/ppc/mac_oldworld.c | 3 +
> hw/ppc/mpc8544ds.c | 4 ++
> hw/ppc/ppc440_bamboo.c | 1 +
> hw/ppc/prep.c | 4 ++
> hw/ppc/spapr_vio.c | 3 +-
> hw/s390x/css-bridge.c | 2 +
> hw/s390x/event-facility.c | 3 +-
> hw/s390x/s390-pci-bus.c | 9 ++-
> hw/s390x/s390-virtio-ccw.c | 6 ++
> hw/s390x/virtio-ccw.c | 2 +-
> hw/scsi/megasas.c | 7 ++
> hw/scsi/scsi-bus.c | 3 +-
> hw/scsi/vmw_pvscsi.c | 1 +
> hw/sd/core.c | 7 ++
> hw/sd/sd.c | 2 +-
> hw/ssi/ssi.c | 9 ++-
> hw/usb/bus.c | 3 +-
> hw/usb/dev-smartcard-reader.c | 9 ++-
> hw/usb/hcd-xhci.c | 4 ++
> hw/vfio/pci.c | 4 ++
> hw/virtio/virtio-bus.c | 1 +
> hw/virtio/virtio-pci.c | 4 ++
> hw/virtio/virtio.c | 2 +-
> include/hw/boards.h | 5 ++
> include/hw/pci/pci.h | 3 +
> include/hw/qdev-core.h | 4 ++
> qapi-schema.json | 9 ++-
> scripts/qemu.py | 25 +++++--
> scripts/qtest.py | 15 +++-
> tests/Makefile.include | 39 ++++++++++-
> tests/qmp-machine-info.py | 138 +++++++++++++++++++++++++++++++++++++
> vl.c | 11 +++
> 71 files changed, 518 insertions(+), 37 deletions(-)
> create mode 100755 tests/qmp-machine-info.py
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Qemu-devel] -nodefaults and available buses (was Re: [RFC 00/15] qmp: Report supported device types on 'query-machines')
2016-11-22 22:34 ` Eduardo Habkost
@ 2016-11-23 17:10 ` Eduardo Habkost
2016-11-24 1:51 ` David Gibson
2016-11-24 13:39 ` Markus Armbruster
0 siblings, 2 replies; 43+ messages in thread
From: Eduardo Habkost @ 2016-11-23 17:10 UTC (permalink / raw)
To: qemu-devel, Markus Armbruster, Marcel Apfelbaum, Michael S. Tsirkin
Cc: Laine Stump, Alexey Kardashevskiy, Michael Roth, Greg Kurz,
libvir-list, Alex Williamson, qemu-ppc, Andrea Bolognani,
Paolo Bonzini, David Gibson, qemu-arm, Beniamino Galvani,
Edgar E. Iglesias, Jia Liu, Mark Cave-Ayland, Artyom Tarasenko,
Peter Maydell
(CCing the maintainers of the machines that crash when using
-nodefaults)
On Tue, Nov 22, 2016 at 08:34:50PM -0200, Eduardo Habkost wrote:
[...]
> "default defaults" vs "-nodefault defaults"
> -------------------------------------------
>
> Two bad news:
>
> 1) We need to differentiate buses created by the machine with
> "-nodefaults" and buses that are created only without
> "-nodefaults".
>
> libvirt use -nodefaults when starting QEMU, so knowing which
> buses are available when using -nodefaults is more interesting
> for them.
>
> Other software, on the other hand, might be interested in the
> results without -nodefaults.
>
> We need to be able model both cases in the new interface.
> Suggestions are welcome.
The good news is that the list is short. The only[1] machines
where the list of buses seem to change when using -nodefaults
are:
* mpc8544ds
* ppce500
* mpc8544ds
* ppce500
* s390-ccw-virtio-*
On all cases above, the only difference is that a virtio bus is
available if not using -nodefaults.
Considering that the list is short, I plan to rename
'supported-device-types' to 'always-available-buses', and
document that it will include only the buses that are not
disabled by -nodefaults.
[1] I mean, the only ones from the set that don't crash with
-nodefaults. The ones below could not be tested:
> 2) A lot of machine-types won't start if using
> "-nodefaults -machine <machine>" without any extra devices or
> drives.
>
> Lots of machines require some drives or devices to be created
> (especially ARM machines that require a SD drive to be
> available).
>
> Some machines will make QEMU exit, some of them simply segfault.
> I am looking for ways to work around it so we can still validate
> -nodefaults-based info on the test code.
The following machines won't work with -nodefaults:
These make QEMU segfault:
* cubieboard
* petalogix-ml605
* or32-sim
* virtex-ml507
* Niagara
These exit with a "missing SecureDigital device" error:
* akita
* borzoi
* cheetah
* connex
* mainstone
* n800
* n810
* spitz
* sx1
* sx1-v1
* terrier
* tosa
* verdex
* z2
--
Eduardo
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines'
2016-11-23 16:43 ` [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Marcel Apfelbaum
@ 2016-11-23 17:35 ` Eduardo Habkost
2016-11-24 9:34 ` Marcel Apfelbaum
2016-11-24 13:34 ` Markus Armbruster
0 siblings, 2 replies; 43+ messages in thread
From: Eduardo Habkost @ 2016-11-23 17:35 UTC (permalink / raw)
To: Marcel Apfelbaum
Cc: qemu-devel, Markus Armbruster, Michael S. Tsirkin, libvir-list,
Laine Stump
On Wed, Nov 23, 2016 at 06:43:16PM +0200, Marcel Apfelbaum wrote:
> On 11/22/2016 03:11 AM, Eduardo Habkost wrote:
> > The Problem
> > ===========
> >
> > Currently management software has no way to find out which device
> > types can be plugged in a machine, unless the machine is already
> > initialized.
> >
>
> Hi Eduardo,
> Thank you for this interesting series. I think this is a problem
> worth addressing.
>
> > Even after the machine is initialized, there's no way to map
> > existing bus types to supported device types unless management
> > software hardcodes the mapping between bus types and device
> > types.
> >
>
> Here I am a little lost.
>
> We are going for machine => supported devices or
> bus-type => supported devices?
On this series, we go for machine-type => supported-devices.
A bus-type => supported-devices map wouldn't work because
different PCIe bus instances might accept different types of
devices (so supported-devices depend on the specific bus
instance, not only on the bus-type).
v2 will probably be more detailed. I plan to change it to:
query-machine(machine-type) => list of BusInfo
BusInfo would contain:
* bus-type
* bus-path
* accepted-device-types (list of type/interface names)
>
> > Example: floppy support on q35 vs i440fx
> > ----------------------------------------
> >
> > There's no way for libvirt to find out that there's no floppy
> > controller on pc-q35-* machine-types by default.
> >
>
> Again "by default". So do we want to query the init state of a machine?
> What devices are there? Or what devices *can be* there?
"by default" means what's present when using "-machine <machine>"
with no extra -device arguments.
We want to know what _buses_ are always there. Which in turn lets
management know which _device_ types _can_ be plugged.
>
> > With this series, pc-i440fx-* will report "floppy" as a supported
> > device type, but pc-q35-* will not.
> >
> > Example: Legacy PCI vs vs PCIe devices
> > --------------------------------------
> >
> > Some devices require a PCIe bus to be available, others work on
> > both legacy PCI and PCIe, while others work only on a legacy PCI
> > bus.
> >
> > Currently management software has no way to know which devices
> > can be added to a given machine, unless it hardcodes machine-type
> > names and device-types names.
> >
>
> Again it seems a double problem, machine => devices vs pci/pcie bus => devices.
> The bus => devices match is not related to a machine type.
A bus-type => device-type match would not depend on the
machine-type, but it would not be useful: different bus instances
can accept different device-types (and the way the bus topology
is configured depend on the machine-type).
>
> > The Proposed Interface
> > ======================
> >
> > This series adds a new field to the output of 'query-machines':
> > 'supported-device-types'. It will contain a list of QOM type
> > names, that can be used to find the list of device types that can
> > be plugged in the machine by default.
>
> What do you mean "by default"? Without bridges or part of the machine itself?
I mean "when you just run -machine with no extra -device
arguments".
>
> The type names reported on
> > the new field can then be used as the 'implements' argument on
> > the 'qom-list-types' command, to find out which device types can
> > be plugged on the machine.
> >
> > Example output
> > --------------
> >
> > (QEMU) query-machines
> > {
> > "return": [
> > [...]
> > {
> > "supported-device-types": [
> > "sys-bus-device"
>
>
> I don't know how "sys-bus-device" can help us... :)
Yes, I added comments about it below. :)
>
> > ],
> > "cpu-max": 1,
> > "hotpluggable-cpus": false,
> > "name": "none"
> > },
> > [...]
> > {
> > "supported-device-types": [
> > "sys-bus-device"
> > ],
> > "cpu-max": 1,
> > "hotpluggable-cpus": false,
> > "name": "xenpv"
> > },
> > [...]
> > {
> > "supported-device-types": [
> > "sys-bus-device",
> > "floppy",
> > "i2c-slave",
> > "pci-device",
> > "isa-device",
> > "ide-device"
>
> Is don't know is this high level classification is useful,
> here is an example:
>
> pvi-device is supported => then we look for all pci devices?
> But what if some pci devices make sense on a machine type,
> but not on another?
If not all pci devices are supported, then the machine must not
return "pci-device" as supported. We need to define a new
type/interface name that would be implemented only by the
supported devices. e.g. "legacy-pci-device".
>
>
>
> > ],
> > "name": "pc-i440fx-2.8",
> > "alias": "pc",
> > "is-default": true,
> > "cpu-max": 255,
> > "hotpluggable-cpus": true
> > },
> > [...]
> > {
> > "supported-device-types": [
> > "sys-bus-device",
> > "floppy",
> > "isa-device",
> > "ide-device"
> > ],
> > "cpu-max": 1,
> > "hotpluggable-cpus": true,
> > "name": "isapc"
> > },
> > [...]
> > {
> > "supported-device-types": [
> > "sys-bus-device",
> > "floppy",
> > "i2c-slave",
> > "pci-device",
> > "isa-device",
> > "ide-device"
> > ],
> > "cpu-max": 128,
> > "hotpluggable-cpus": true,
> > "name": "xenfv"
> > },
> > [...]
> > {
> > "alias": "q35",
> > "supported-device-types": [
> > "sys-bus-device",
> > "i2c-slave",
> > "PCIE-device",
> > "isa-device",
> > "ide-device"
> > ],
> > "cpu-max": 288,
> > "hotpluggable-cpus": true,
> > "name": "pc-q35-2.8"
> > },
> > [...]
> > ]
> > }
> >
> > Considered alternatives
> > =======================
> >
> > Indirect mapping (machine => bus => device)
> > -------------------------------------------
> >
> > This RFC implements a mechanism to implement ax
> > machine-type => supported-device-types
> > mapping. An alternative solution I considered was to expose an
> > indirect mapping:
> > machine-type => default-bus-types
> > followed by
> > bus-type => supported-device-types.
> >
>
> As I previously stated, I don't know if it helps. bus-type
> can support different devices on different archs.
Yes. After learning a bit more about PCIe, I am convinced that a
bus->type => device-types mapping won't help.
>
> > But exposing only the resulting supported device-types list
> > imposes less restrictions on how the device and bus type
> > hierarchy is implemented inside QEMU. There's still a
> > machine-type => bus-type => device-type
> > mapping implemented internally, but it is an implementation
> > detail on the current version, and not part of the
> > externally-visible interface.
> >
>
> Good, I personally don't like this "pass".
>
> > The Implementation
> > ==================
> >
> > This add a new field to MachineClass: default_bus_types, and a
> > new field to BusClass: supported_device_type.
> >
> > The two fields are used to build the list of supported device
> > types for a given machine. On most cases, the normal QOM type
> > hierarchy is used to define the set of supported devices for a
> > bus. On the case of PCIe buses, a INTERFACE_PCIE_DEVICE interface
> > name was introduced, to indicate PCIe-capable devices.
> >
> > This means we are duplicating information in some cases:
> >
> > * BusClass::supported_device_type duplicates knowlege that is
> > already encoded in DeviceClass::bus_type.
> >
> > To make sure both fields agree with each other, a new
> > device_class_set_bus_type() wrapper was added, to perform
> > additional validation.
> >
> > * MachineClass::default_bus_type duplicates knowledge that is
> > already encoded in the machine init function.
> >
> > To make sure the information is correct, a qmp-machine-info.py
> > test case is added, that will validate the
> > supported-device-types field based on the buses created by the
> > machine.
> >
> > * PCIDeviceClass::is_express and INTERFACE_PCIE_DEVICE
> > both encode the same information about a PCI device class.
> >
> > A future version of this series may include a
> > class_base_post_init hook that will allow TYPE_PCI_DEVICE to
> > validate/update is_express and the interface list to ensure
> > both are always consistent.
> >
> > Test Code
> > ---------
> >
> > qdev-based test code for the new field was implemented in a
> > Python script. Some extra support was implemented in
> > tests/Makefile.include, scripts/qemu.py and scripts/qtest.py to
> > allow the test to be implemented.
> >
> > Limitations
> > ===========
> >
> > TYPE_SYS_BUS_DEVICE is too generic
> > ----------------------------------
> >
> > Currently all machines have a TYPE_SYS_BUS bus, meaning all
> > TYPE_SYS_BUS_DEVICE subclasses are reported as supported.
> >
>
> Agreed, this is a problem.
>
> > The current solution in this series is to report
> > TYPE_SYS_BUS_DEVICE as supported by all machines. But we could
> > gradually add arch-specific or machine-family-specific interface
> > names that can be used on devices that are meant to work with
> > only a subset of TYPE_SYS_BUS_DEVICE subclasses.
> >
> > A future version of this series may remove TYPE_SYS_BUS_DEVICE
> > from the supported-device-types output, and return a
> > arch-specific or machine-family-specific interface name to
> > restrict management software to a subset of TYPE_SYS_BUS_DEVICE
> > subclasses.
> >
> > PCI vs PCIe
> > -----------
> >
> > Machines with PCIe buses will report INTERFACE_PCIE_DEVICE on
> > supported-device-types.
> >
> > Machines with legacy PCI buses will report TYPE_PCI_DEVICE on
> > supported-device-types.
> >
> > The problem with the current approach is that PCIe devices are
> > TYPE_PCI_DEVICE subclasses. The allows PCI device classes to
> > indicate they are PCIe-capable, but there's no obvious way to
> > indicate that a device is PCIe-only. This needs to be addressed
> > in a future version of this series.
> >
> > Suggestions are welcome.
>
>
> As we talked offline, I personally like an interface IPCIType
> with a field having 3 possible values {pci/pcie/hybrid}
>
> To understand how hybrid works we need some rules, like
> "pci on pci bus/pcie on pcie bus"
> "pcie on a non-root pcie bus/pcie otherwise
>
> I don't think we'll have a lot of rules, simple boolean fields
> for the interface should be enough.
What you propose makes sense, the only difference is that the
boolean fields would be just interface names that can be used as
the "implements" argument on qom-list-types.
e.g.:
* Hybrid PCI device-types would implement both "legacy-pci-device" and
"pcie-device" interfaces.
* PCIe-only device-types would implement only the "pcie-device"
interface.
* Legacy-PCI-only device-types would implement only the
"legacy-pci-device" interface.
Then, the bus instances would have a 'accepted-device-types'
field:
* A legacy PCI bus would accept only "legacy-pci-device" devices.
* A PCIe-only bus would accept only "pcie-device" devices.
* A PCIe bus that accepts legacy PCI devices (the root bus?)
would accept both "legacy-pci-device" and "pcie-device"
devices.
Then, query-machines would return the list of bus instances that
machine init creates, containing the bus ID, bus type, and
accepted-device-types.
Does that make sense?
>
> This still does not solve the problem that some devices makes
> sense only on a specific arch.
Right now, we can simply compile out arch-specific devices that
can never be plugged in a QEMU binary. But if we still want them
compiled in for some reason, we can categorize them on a
different type/interface name, and the corresponding machine-type
would tell management that their buses accept only the
arch-specific type/interface name.
>
> >
> > Incomplete bus lists on some machines
> > -------------------------------------
> >
> > With this series, not all machines classes are changed to add the
> > full list of device types on the 'supported-device-types'. To
> > allow the code to be updated gradually, qmp-machine-info.py has a
> > STRICT_ARCHES variable, that will make the test code require a
> > complete device type list only on some architectures.
> >
> > Out of scope: Configurable buses
> > --------------------------------
> >
> > There's no way to map machine options like "usb=on|off" to
> > device-types or buses. I plan to propose a new interface that
> > allows machine options to be mapped to buses/device-types later.
> >
> > Out of scope: Deciding where to plug devices
> > --------------------------------------------
> >
> > Once management software discovers which devices can be plugged
> > to a machine, it still has to discover or define where devices
> > can/should/will be plugged. This is out of the scope of this
> > series.
> >
>
> That's a pitty :(
> I was hoping this series will solve this issue. But if it prepares
> the grounds for it is also a good step .
The bus ID will be in the scope of v2.
>
>
>
> Thanks,
> Marcel
>
> > Out of scope: Hotplug
> > ---------------------
> >
> > The proposed interface is supposed to help management software
> > find which device types can be used when creating the VM. Device
> > hotplug is out of the scope of this series. However, the new
> > 'device-types' QOM property on bus objects could be used to find
> > out which device types can be plugged on the existing buses.
> >
> > ---
> > Cc: libvir-list@redhat.com
> > Cc: Laine Stump <laine@redhat.com>
> >
> > Eduardo Habkost (15):
> > qemu.py: Make logging optional
> > qtest.py: Support QTEST_LOG environment variable
> > qtest.py: make logging optional
> > qtest.py: Make 'binary' parameter optional
> > tests: Add rules to non-gtester qtest test cases
> > qdev: Add device_type field to BusClass
> > machine: Add MachineClass::default_buses field
> > qmp: Add 'supported-device-types' field to 'query-machines'
> > pci: Introduce INTERFACE_PCIE_DEVICE interface name
> > pc: Initialize default bus lists
> > s390x: Initialize default bus lists
> > arm: Initialize default bus lists
> > mips: Initialize default bus lists
> > ppc: Initialize default bus lists
> > qdev: Add device_class_set_bus_type() function
> >
> > hw/arm/aspeed.c | 2 +
> > hw/arm/collie.c | 1 +
> > hw/arm/cubieboard.c | 1 +
> > hw/arm/exynos4_boards.c | 5 ++
> > hw/arm/gumstix.c | 7 ++
> > hw/arm/highbank.c | 4 ++
> > hw/arm/imx25_pdk.c | 1 +
> > hw/arm/kzm.c | 1 +
> > hw/arm/musicpal.c | 1 +
> > hw/arm/nseries.c | 2 +
> > hw/arm/palm.c | 1 +
> > hw/arm/realview.c | 1 +
> > hw/arm/spitz.c | 10 +++
> > hw/arm/stellaris.c | 4 ++
> > hw/audio/intel-hda.c | 9 ++-
> > hw/block/fdc.c | 17 +++--
> > hw/block/nvme.c | 4 ++
> > hw/char/virtio-serial-bus.c | 3 +-
> > hw/core/bus.c | 9 +++
> > hw/core/machine.c | 18 ++++-
> > hw/core/qdev.c | 8 +++
> > hw/core/sysbus.c | 3 +-
> > hw/i2c/core.c | 9 ++-
> > hw/i386/pc_piix.c | 13 ++++
> > hw/i386/pc_q35.c | 4 ++
> > hw/ide/qdev.c | 3 +-
> > hw/input/adb.c | 9 ++-
> > hw/ipack/ipack.c | 9 ++-
> > hw/isa/isa-bus.c | 3 +-
> > hw/mips/mips_malta.c | 7 ++
> > hw/mips/mips_r4k.c | 2 +
> > hw/misc/auxbus.c | 3 +-
> > hw/net/e1000e.c | 4 ++
> > hw/net/vmxnet3.c | 4 ++
> > hw/pci-bridge/ioh3420.c | 4 ++
> > hw/pci-bridge/xio3130_downstream.c | 4 ++
> > hw/pci/pci.c | 16 ++++-
> > hw/ppc/e500plat.c | 3 +
> > hw/ppc/mac_newworld.c | 4 ++
> > hw/ppc/mac_oldworld.c | 3 +
> > hw/ppc/mpc8544ds.c | 4 ++
> > hw/ppc/ppc440_bamboo.c | 1 +
> > hw/ppc/prep.c | 4 ++
> > hw/ppc/spapr_vio.c | 3 +-
> > hw/s390x/css-bridge.c | 2 +
> > hw/s390x/event-facility.c | 3 +-
> > hw/s390x/s390-pci-bus.c | 9 ++-
> > hw/s390x/s390-virtio-ccw.c | 6 ++
> > hw/s390x/virtio-ccw.c | 2 +-
> > hw/scsi/megasas.c | 7 ++
> > hw/scsi/scsi-bus.c | 3 +-
> > hw/scsi/vmw_pvscsi.c | 1 +
> > hw/sd/core.c | 7 ++
> > hw/sd/sd.c | 2 +-
> > hw/ssi/ssi.c | 9 ++-
> > hw/usb/bus.c | 3 +-
> > hw/usb/dev-smartcard-reader.c | 9 ++-
> > hw/usb/hcd-xhci.c | 4 ++
> > hw/vfio/pci.c | 4 ++
> > hw/virtio/virtio-bus.c | 1 +
> > hw/virtio/virtio-pci.c | 4 ++
> > hw/virtio/virtio.c | 2 +-
> > include/hw/boards.h | 5 ++
> > include/hw/pci/pci.h | 3 +
> > include/hw/qdev-core.h | 4 ++
> > qapi-schema.json | 9 ++-
> > scripts/qemu.py | 25 +++++--
> > scripts/qtest.py | 15 +++-
> > tests/Makefile.include | 39 ++++++++++-
> > tests/qmp-machine-info.py | 138 +++++++++++++++++++++++++++++++++++++
> > vl.c | 11 +++
> > 71 files changed, 518 insertions(+), 37 deletions(-)
> > create mode 100755 tests/qmp-machine-info.py
> >
>
>
--
Eduardo
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] -nodefaults and available buses (was Re: [RFC 00/15] qmp: Report supported device types on 'query-machines')
2016-11-23 17:10 ` [Qemu-devel] -nodefaults and available buses (was Re: [RFC 00/15] qmp: Report supported device types on 'query-machines') Eduardo Habkost
@ 2016-11-24 1:51 ` David Gibson
2016-11-24 16:30 ` Cornelia Huck
2016-11-24 13:39 ` Markus Armbruster
1 sibling, 1 reply; 43+ messages in thread
From: David Gibson @ 2016-11-24 1:51 UTC (permalink / raw)
To: Eduardo Habkost
Cc: qemu-devel, Markus Armbruster, Marcel Apfelbaum,
Michael S. Tsirkin, Laine Stump, Alexey Kardashevskiy,
Michael Roth, Greg Kurz, libvir-list, Alex Williamson, qemu-ppc,
Andrea Bolognani, Paolo Bonzini, qemu-arm, Beniamino Galvani,
Edgar E. Iglesias, Jia Liu, Mark Cave-Ayland, Artyom Tarasenko,
Peter Maydell
[-- Attachment #1: Type: text/plain, Size: 2953 bytes --]
On Wed, Nov 23, 2016 at 03:10:47PM -0200, Eduardo Habkost wrote:
> (CCing the maintainers of the machines that crash when using
> -nodefaults)
>
> On Tue, Nov 22, 2016 at 08:34:50PM -0200, Eduardo Habkost wrote:
> [...]
> > "default defaults" vs "-nodefault defaults"
> > -------------------------------------------
> >
> > Two bad news:
> >
> > 1) We need to differentiate buses created by the machine with
> > "-nodefaults" and buses that are created only without
> > "-nodefaults".
> >
> > libvirt use -nodefaults when starting QEMU, so knowing which
> > buses are available when using -nodefaults is more interesting
> > for them.
> >
> > Other software, on the other hand, might be interested in the
> > results without -nodefaults.
> >
> > We need to be able model both cases in the new interface.
> > Suggestions are welcome.
>
> The good news is that the list is short. The only[1] machines
> where the list of buses seem to change when using -nodefaults
> are:
>
> * mpc8544ds
> * ppce500
> * mpc8544ds
> * ppce500
> * s390-ccw-virtio-*
>
> On all cases above, the only difference is that a virtio bus is
> available if not using -nodefaults.
Hrm.. that's odd. Well, it makes sense for the s390 which has special
virtio arrangements. However, the others are all embedded ppc
machines, whose virtio should be bog-standard virtio-pci. I'm
wondering if the addition of the virtio "bus" is a side-effect of the
NIC or storage device created without -nodefaults being virtio.
> Considering that the list is short, I plan to rename
> 'supported-device-types' to 'always-available-buses', and
> document that it will include only the buses that are not
> disabled by -nodefaults.
>
> [1] I mean, the only ones from the set that don't crash with
> -nodefaults. The ones below could not be tested:
>
> > 2) A lot of machine-types won't start if using
> > "-nodefaults -machine <machine>" without any extra devices or
> > drives.
> >
> > Lots of machines require some drives or devices to be created
> > (especially ARM machines that require a SD drive to be
> > available).
> >
> > Some machines will make QEMU exit, some of them simply segfault.
> > I am looking for ways to work around it so we can still validate
> > -nodefaults-based info on the test code.
>
> The following machines won't work with -nodefaults:
>
> These make QEMU segfault:
> * cubieboard
> * petalogix-ml605
> * or32-sim
> * virtex-ml507
> * Niagara
>
> These exit with a "missing SecureDigital device" error:
> * akita
> * borzoi
> * cheetah
> * connex
> * mainstone
> * n800
> * n810
> * spitz
> * sx1
> * sx1-v1
> * terrier
> * tosa
> * verdex
> * z2
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines'
2016-11-23 17:35 ` Eduardo Habkost
@ 2016-11-24 9:34 ` Marcel Apfelbaum
2016-11-24 13:34 ` Markus Armbruster
1 sibling, 0 replies; 43+ messages in thread
From: Marcel Apfelbaum @ 2016-11-24 9:34 UTC (permalink / raw)
To: Eduardo Habkost
Cc: qemu-devel, Markus Armbruster, Michael S. Tsirkin, libvir-list,
Laine Stump
On 11/23/2016 07:35 PM, Eduardo Habkost wrote:
> On Wed, Nov 23, 2016 at 06:43:16PM +0200, Marcel Apfelbaum wrote:
>> On 11/22/2016 03:11 AM, Eduardo Habkost wrote:
>>> The Problem
>>> ===========
>>>
>>> Currently management software has no way to find out which device
>>> types can be plugged in a machine, unless the machine is already
>>> initialized.
>>>
>>
>> Hi Eduardo,
>> Thank you for this interesting series. I think this is a problem
>> worth addressing.
>>
[...]
>>>
>>> PCI vs PCIe
>>> -----------
>>>
>>> Machines with PCIe buses will report INTERFACE_PCIE_DEVICE on
>>> supported-device-types.
>>>
>>> Machines with legacy PCI buses will report TYPE_PCI_DEVICE on
>>> supported-device-types.
>>>
>>> The problem with the current approach is that PCIe devices are
>>> TYPE_PCI_DEVICE subclasses. The allows PCI device classes to
>>> indicate they are PCIe-capable, but there's no obvious way to
>>> indicate that a device is PCIe-only. This needs to be addressed
>>> in a future version of this series.
>>>
>>> Suggestions are welcome.
>>
>>
>> As we talked offline, I personally like an interface IPCIType
>> with a field having 3 possible values {pci/pcie/hybrid}
>>
>> To understand how hybrid works we need some rules, like
>> "pci on pci bus/pcie on pcie bus"
>> "pcie on a non-root pcie bus/pcie otherwise
>>
>> I don't think we'll have a lot of rules, simple boolean fields
>> for the interface should be enough.
>
> What you propose makes sense, the only difference is that the
> boolean fields would be just interface names that can be used as
> the "implements" argument on qom-list-types.
>
> e.g.:
>
> * Hybrid PCI device-types would implement both "legacy-pci-device" and
> "pcie-device" interfaces.
> * PCIe-only device-types would implement only the "pcie-device"
> interface.
> * Legacy-PCI-only device-types would implement only the
> "legacy-pci-device" interface.
>
> Then, the bus instances would have a 'accepted-device-types'
> field:
>
> * A legacy PCI bus would accept only "legacy-pci-device" devices.
> * A PCIe-only bus would accept only "pcie-device" devices.
> * A PCIe bus that accepts legacy PCI devices (the root bus?)
> would accept both "legacy-pci-device" and "pcie-device"
> devices.
>
> Then, query-machines would return the list of bus instances that
> machine init creates, containing the bus ID, bus type, and
> accepted-device-types.
>
> Does that make sense?
>
Sure, the described approach solves the problem.
>>
>> This still does not solve the problem that some devices makes
>> sense only on a specific arch.
>
> Right now, we can simply compile out arch-specific devices that
> can never be plugged in a QEMU binary. But if we still want them
> compiled in for some reason, we can categorize them on a
> different type/interface name, and the corresponding machine-type
> would tell management that their buses accept only the
> arch-specific type/interface name.
>
Adding an Interface for each arch could work, yes.
>>
>>>
>>> Incomplete bus lists on some machines
>>> -------------------------------------
>>>
>>> With this series, not all machines classes are changed to add the
>>> full list of device types on the 'supported-device-types'. To
>>> allow the code to be updated gradually, qmp-machine-info.py has a
>>> STRICT_ARCHES variable, that will make the test code require a
>>> complete device type list only on some architectures.
>>>
>>> Out of scope: Configurable buses
>>> --------------------------------
>>>
>>> There's no way to map machine options like "usb=on|off" to
>>> device-types or buses. I plan to propose a new interface that
>>> allows machine options to be mapped to buses/device-types later.
>>>
>>> Out of scope: Deciding where to plug devices
>>> --------------------------------------------
>>>
>>> Once management software discovers which devices can be plugged
>>> to a machine, it still has to discover or define where devices
>>> can/should/will be plugged. This is out of the scope of this
>>> series.
>>>
>>
>> That's a pitty :(
>> I was hoping this series will solve this issue. But if it prepares
>> the grounds for it is also a good step .
>
> The bus ID will be in the scope of v2.
>
Thanks,
Marcel
>>
>>
>>
>> Thanks,
>> Marcel
>>
[...]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines'
2016-11-23 17:35 ` Eduardo Habkost
2016-11-24 9:34 ` Marcel Apfelbaum
@ 2016-11-24 13:34 ` Markus Armbruster
2016-11-24 14:12 ` Eduardo Habkost
2016-11-24 14:22 ` Marcel Apfelbaum
1 sibling, 2 replies; 43+ messages in thread
From: Markus Armbruster @ 2016-11-24 13:34 UTC (permalink / raw)
To: Eduardo Habkost
Cc: Marcel Apfelbaum, libvir-list, Michael S. Tsirkin, qemu-devel,
Laine Stump
Eduardo Habkost <ehabkost@redhat.com> writes:
> On Wed, Nov 23, 2016 at 06:43:16PM +0200, Marcel Apfelbaum wrote:
>> On 11/22/2016 03:11 AM, Eduardo Habkost wrote:
>> > The Problem
>> > ===========
>> >
>> > Currently management software has no way to find out which device
>> > types can be plugged in a machine, unless the machine is already
>> > initialized.
I doubt it can find the precise list of device types even for an
initialized machine.
>> Hi Eduardo,
>> Thank you for this interesting series. I think this is a problem
>> worth addressing.
>>
>> > Even after the machine is initialized, there's no way to map
>> > existing bus types to supported device types unless management
>> > software hardcodes the mapping between bus types and device
>> > types.
>> >
>>
>> Here I am a little lost.
>>
>> We are going for machine => supported devices or
>> bus-type => supported devices?
>
> On this series, we go for machine-type => supported-devices.
>
> A bus-type => supported-devices map wouldn't work because
> different PCIe bus instances might accept different types of
> devices (so supported-devices depend on the specific bus
> instance, not only on the bus-type).
>
> v2 will probably be more detailed. I plan to change it to:
>
> query-machine(machine-type) => list of BusInfo
>
> BusInfo would contain:
> * bus-type
> * bus-path
> * accepted-device-types (list of type/interface names)
Let me take a step back and explore what questions a management
application may want to ask. I think the basic questions are:
* Which devices models could be plugged now?
"Now" means in the current state of the machine. Depending on "now",
this could be hot- or cold-plug.
* Into which sockets could device model T be plugged now?
Mind, I wrote "socket", not bus. Buses provide sockets, but they are
not the only provider of sockets.
We need a way to name sockets. (QOM path to device or bus, socket
address on device or bus) could work.
Are we on the same page so far?
Related: same questions with "newly created machine of machine type M"
instead of "now". This isn't basic, because you could always create the
machine, then ask the basic question. But not having to create the
machine is convenient, in particular as long as a single QEMU process
can only ever create one machine.
Related: same, with creation options.
Your series provides a solution for a special non-basic case: newly
created machine of machine type M with no optional parts, i.e. with
-nodefaults and nothing else. Or maybe with the default set of optional
parts, i.e. without -nodefaults, not sure.
I'm not demanding you provide a solution for the general case first. It
would be nice, but it could be too complex for a first step. I do
recommend you design your solution for the special case with the general
case in mind. Say, by trying to ensure the special case query returns
something that will do or can be evolved to do for the general case,
too.
>> > Example: floppy support on q35 vs i440fx
>> > ----------------------------------------
>> >
>> > There's no way for libvirt to find out that there's no floppy
>> > controller on pc-q35-* machine-types by default.
>> >
>>
>> Again "by default". So do we want to query the init state of a machine?
>> What devices are there? Or what devices *can be* there?
>
> "by default" means what's present when using "-machine <machine>"
> with no extra -device arguments.
Not just -device. Some legacy options can also create buses. For
instance, -device if=scsi,... creates a SCSI bus.
> We want to know what _buses_ are always there. Which in turn lets
> management know which _device_ types _can_ be plugged.
>
>>
>> > With this series, pc-i440fx-* will report "floppy" as a supported
>> > device type, but pc-q35-* will not.
>> >
>> > Example: Legacy PCI vs vs PCIe devices
>> > --------------------------------------
>> >
>> > Some devices require a PCIe bus to be available, others work on
>> > both legacy PCI and PCIe, while others work only on a legacy PCI
>> > bus.
>> >
>> > Currently management software has no way to know which devices
>> > can be added to a given machine, unless it hardcodes machine-type
>> > names and device-types names.
>> >
>>
>> Again it seems a double problem, machine => devices vs pci/pcie bus => devices.
>> The bus => devices match is not related to a machine type.
>
> A bus-type => device-type match would not depend on the
> machine-type, but it would not be useful: different bus instances
> can accept different device-types (and the way the bus topology
> is configured depend on the machine-type).
>
>
>>
>> > The Proposed Interface
>> > ======================
>> >
>> > This series adds a new field to the output of 'query-machines':
>> > 'supported-device-types'. It will contain a list of QOM type
>> > names, that can be used to find the list of device types that can
>> > be plugged in the machine by default.
>>
>> What do you mean "by default"? Without bridges or part of the machine itself?
>
> I mean "when you just run -machine with no extra -device
> arguments".
>
>>
>> The type names reported on
>> > the new field can then be used as the 'implements' argument on
>> > the 'qom-list-types' command, to find out which device types can
>> > be plugged on the machine.
>> >
>> > Example output
>> > --------------
>> >
>> > (QEMU) query-machines
>> > {
>> > "return": [
>> > [...]
>> > {
>> > "supported-device-types": [
>> > "sys-bus-device"
>>
>>
>> I don't know how "sys-bus-device" can help us... :)
>
> Yes, I added comments about it below. :)
The sysbus has always been a cop-out. It's a catch-all pseudo-bus. The
only thing sysbus devices really have in common is that they can't plug
into any real bus.
This used to be an academic issue until Alex made some sysbus devices
pluggable. Before, "sysbus device" told you everything about
pluggability you needed to know: not pluggable. Since then, it tells
you nothing. We'll have to address this regression eventually. See
"TYPE_SYS_BUS_DEVICE is too generic" below.
>> > ],
>> > "cpu-max": 1,
>> > "hotpluggable-cpus": false,
>> > "name": "none"
>> > },
>> > [...]
>> > {
>> > "supported-device-types": [
>> > "sys-bus-device"
>> > ],
>> > "cpu-max": 1,
>> > "hotpluggable-cpus": false,
>> > "name": "xenpv"
>> > },
>> > [...]
>> > {
>> > "supported-device-types": [
>> > "sys-bus-device",
>> > "floppy",
>> > "i2c-slave",
>> > "pci-device",
>> > "isa-device",
>> > "ide-device"
>>
>> Is don't know is this high level classification is useful,
>> here is an example:
>>
>> pvi-device is supported => then we look for all pci devices?
>> But what if some pci devices make sense on a machine type,
>> but not on another?
>
> If not all pci devices are supported, then the machine must not
> return "pci-device" as supported. We need to define a new
> type/interface name that would be implemented only by the
> supported devices. e.g. "legacy-pci-device".
Before PCIe, "PCI device" told you everything about pluggability you
needed to know: can be plugged into a PCI bus. Since PCIe, it doesn't.
We'll have to address this regression, too. See "PCI vs PCIe" below.
>> > ],
>> > "name": "pc-i440fx-2.8",
>> > "alias": "pc",
>> > "is-default": true,
>> > "cpu-max": 255,
>> > "hotpluggable-cpus": true
>> > },
>> > [...]
>> > {
>> > "supported-device-types": [
>> > "sys-bus-device",
>> > "floppy",
>> > "isa-device",
>> > "ide-device"
>> > ],
>> > "cpu-max": 1,
>> > "hotpluggable-cpus": true,
>> > "name": "isapc"
>> > },
>> > [...]
>> > {
>> > "supported-device-types": [
>> > "sys-bus-device",
>> > "floppy",
>> > "i2c-slave",
>> > "pci-device",
>> > "isa-device",
>> > "ide-device"
>> > ],
>> > "cpu-max": 128,
>> > "hotpluggable-cpus": true,
>> > "name": "xenfv"
>> > },
>> > [...]
>> > {
>> > "alias": "q35",
>> > "supported-device-types": [
>> > "sys-bus-device",
>> > "i2c-slave",
>> > "PCIE-device",
>> > "isa-device",
>> > "ide-device"
>> > ],
>> > "cpu-max": 288,
>> > "hotpluggable-cpus": true,
>> > "name": "pc-q35-2.8"
>> > },
>> > [...]
>> > ]
>> > }
>> >
>> > Considered alternatives
>> > =======================
>> >
>> > Indirect mapping (machine => bus => device)
>> > -------------------------------------------
>> >
>> > This RFC implements a mechanism to implement ax
>> > machine-type => supported-device-types
>> > mapping. An alternative solution I considered was to expose an
>> > indirect mapping:
>> > machine-type => default-bus-types
>> > followed by
>> > bus-type => supported-device-types.
>> >
>>
>> As I previously stated, I don't know if it helps. bus-type
>> can support different devices on different archs.
>
> Yes. After learning a bit more about PCIe, I am convinced that a
> bus->type => device-types mapping won't help.
>
>>
>> > But exposing only the resulting supported device-types list
>> > imposes less restrictions on how the device and bus type
>> > hierarchy is implemented inside QEMU. There's still a
>> > machine-type => bus-type => device-type
>> > mapping implemented internally, but it is an implementation
>> > detail on the current version, and not part of the
>> > externally-visible interface.
>> >
>>
>> Good, I personally don't like this "pass".
Point taken.
The core idea here seems to be using the QOM type hierarchy for
representing "pluggability".
>> > The Implementation
>> > ==================
[Skipping for now...]
>> >
>> > Limitations
>> > ===========
>> >
>> > TYPE_SYS_BUS_DEVICE is too generic
>> > ----------------------------------
>> >
>> > Currently all machines have a TYPE_SYS_BUS bus, meaning all
>> > TYPE_SYS_BUS_DEVICE subclasses are reported as supported.
>> >
>>
>> Agreed, this is a problem.
>>
>> > The current solution in this series is to report
>> > TYPE_SYS_BUS_DEVICE as supported by all machines.
Because all machines have this catch-all pseudo-bus. Reporting it
exists is correct, but as is the information is useless.
>> > But we could
>> > gradually add arch-specific or machine-family-specific interface
>> > names that can be used on devices that are meant to work with
>> > only a subset of TYPE_SYS_BUS_DEVICE subclasses.
Basically, encode pluggability information in the QOM type hierarchy.
To gauge whether that would work I'd have to actually understand how
exactly pluggable sysbus devices work, in particular what the conditions
for accepting a plug are.
>> > A future version of this series may remove TYPE_SYS_BUS_DEVICE
>> > from the supported-device-types output, and return a
>> > arch-specific or machine-family-specific interface name to
>> > restrict management software to a subset of TYPE_SYS_BUS_DEVICE
>> > subclasses.
>> >
>> > PCI vs PCIe
>> > -----------
>> >
>> > Machines with PCIe buses will report INTERFACE_PCIE_DEVICE on
>> > supported-device-types.
>> >
>> > Machines with legacy PCI buses will report TYPE_PCI_DEVICE on
>> > supported-device-types.
>> >
>> > The problem with the current approach is that PCIe devices are
>> > TYPE_PCI_DEVICE subclasses. The allows PCI device classes to
>> > indicate they are PCIe-capable, but there's no obvious way to
>> > indicate that a device is PCIe-only. This needs to be addressed
>> > in a future version of this series.
>> >
>> > Suggestions are welcome.
>>
>>
>> As we talked offline, I personally like an interface IPCIType
>> with a field having 3 possible values {pci/pcie/hybrid}
>>
>> To understand how hybrid works we need some rules, like
>> "pci on pci bus/pcie on pcie bus"
>> "pcie on a non-root pcie bus/pcie otherwise
>>
>> I don't think we'll have a lot of rules, simple boolean fields
>> for the interface should be enough.
>
> What you propose makes sense, the only difference is that the
> boolean fields would be just interface names that can be used as
> the "implements" argument on qom-list-types.
>
> e.g.:
>
> * Hybrid PCI device-types would implement both "legacy-pci-device" and
> "pcie-device" interfaces.
> * PCIe-only device-types would implement only the "pcie-device"
> interface.
> * Legacy-PCI-only device-types would implement only the
> "legacy-pci-device" interface.
In other words, encode "pluggability" in the QOM type hierarchy.
> Then, the bus instances would have a 'accepted-device-types'
> field:
>
> * A legacy PCI bus would accept only "legacy-pci-device" devices.
> * A PCIe-only bus would accept only "pcie-device" devices.
> * A PCIe bus that accepts legacy PCI devices (the root bus?)
> would accept both "legacy-pci-device" and "pcie-device"
> devices.
>
> Then, query-machines would return the list of bus instances that
> machine init creates, containing the bus ID, bus type, and
> accepted-device-types.
>
> Does that make sense?
Yes.
Our decision to have hybrid PCI/PCIe devices and buses breeds
considerable complexity. I wish we had avoided them, but I believe it's
too late to change now.
>> This still does not solve the problem that some devices makes
>> sense only on a specific arch.
Examples?
> Right now, we can simply compile out arch-specific devices that
> can never be plugged in a QEMU binary. But if we still want them
> compiled in for some reason, we can categorize them on a
> different type/interface name, and the corresponding machine-type
> would tell management that their buses accept only the
> arch-specific type/interface name.
Could become messy. Can't say without looking at examples.
>> > Incomplete bus lists on some machines
>> > -------------------------------------
>> >
>> > With this series, not all machines classes are changed to add the
>> > full list of device types on the 'supported-device-types'. To
>> > allow the code to be updated gradually, qmp-machine-info.py has a
>> > STRICT_ARCHES variable, that will make the test code require a
>> > complete device type list only on some architectures.
Ideally, pluggability information would be derived from QOM. I figure
that's the only practical way to solve the general case.
For the special case "newly created machine", deriving from QOM may be
impractical, say because you'd have to create the machine. Then you
have to hard-code the result somehow. Tests to validate the hardcoded
results match the results you get when you actually create the machine
would be required, at least once you *can* get results for a created
machine.
>> > Out of scope: Configurable buses
>> > --------------------------------
>> >
>> > There's no way to map machine options like "usb=on|off" to
>> > device-types or buses. I plan to propose a new interface that
>> > allows machine options to be mapped to buses/device-types later.
>> >
>> > Out of scope: Deciding where to plug devices
>> > --------------------------------------------
>> >
>> > Once management software discovers which devices can be plugged
>> > to a machine, it still has to discover or define where devices
>> > can/should/will be plugged. This is out of the scope of this
>> > series.
>> >
>>
>> That's a pitty :(
>> I was hoping this series will solve this issue. But if it prepares
>> the grounds for it is also a good step .
>
> The bus ID will be in the scope of v2.
I'm afraid "bus" is insufficiently general.
>> Thanks,
>> Marcel
>>
>> > Out of scope: Hotplug
>> > ---------------------
>> >
>> > The proposed interface is supposed to help management software
>> > find which device types can be used when creating the VM. Device
>> > hotplug is out of the scope of this series. However, the new
>> > 'device-types' QOM property on bus objects could be used to find
>> > out which device types can be plugged on the existing buses.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] -nodefaults and available buses (was Re: [RFC 00/15] qmp: Report supported device types on 'query-machines')
2016-11-23 17:10 ` [Qemu-devel] -nodefaults and available buses (was Re: [RFC 00/15] qmp: Report supported device types on 'query-machines') Eduardo Habkost
2016-11-24 1:51 ` David Gibson
@ 2016-11-24 13:39 ` Markus Armbruster
1 sibling, 0 replies; 43+ messages in thread
From: Markus Armbruster @ 2016-11-24 13:39 UTC (permalink / raw)
To: Eduardo Habkost
Cc: qemu-devel, Marcel Apfelbaum, Michael S. Tsirkin, Peter Maydell,
Jia Liu, Alexey Kardashevskiy, Mark Cave-Ayland, Michael Roth,
Greg Kurz, Beniamino Galvani, libvir-list, Alex Williamson,
qemu-arm, qemu-ppc, Laine Stump, Edgar E. Iglesias,
Paolo Bonzini, Andrea Bolognani, Artyom Tarasenko, David Gibson
Eduardo Habkost <ehabkost@redhat.com> writes:
> (CCing the maintainers of the machines that crash when using
> -nodefaults)
>
> On Tue, Nov 22, 2016 at 08:34:50PM -0200, Eduardo Habkost wrote:
> [...]
>> "default defaults" vs "-nodefault defaults"
>> -------------------------------------------
>>
>> Two bad news:
>>
>> 1) We need to differentiate buses created by the machine with
>> "-nodefaults" and buses that are created only without
>> "-nodefaults".
>>
>> libvirt use -nodefaults when starting QEMU, so knowing which
>> buses are available when using -nodefaults is more interesting
>> for them.
Yes.
>> Other software, on the other hand, might be interested in the
>> results without -nodefaults.
Maybe.
Related: other machine options, such as usb=on.
>> We need to be able model both cases in the new interface.
>> Suggestions are welcome.
>
> The good news is that the list is short. The only[1] machines
> where the list of buses seem to change when using -nodefaults
> are:
>
> * mpc8544ds
> * ppce500
> * mpc8544ds
> * ppce500
> * s390-ccw-virtio-*
>
> On all cases above, the only difference is that a virtio bus is
> available if not using -nodefaults.
>
> Considering that the list is short, I plan to rename
> 'supported-device-types' to 'always-available-buses', and
> document that it will include only the buses that are not
> disabled by -nodefaults.
>
> [1] I mean, the only ones from the set that don't crash with
> -nodefaults. The ones below could not be tested:
>
>> 2) A lot of machine-types won't start if using
>> "-nodefaults -machine <machine>" without any extra devices or
>> drives.
>>
>> Lots of machines require some drives or devices to be created
>> (especially ARM machines that require a SD drive to be
>> available).
>>
>> Some machines will make QEMU exit, some of them simply segfault.
>> I am looking for ways to work around it so we can still validate
>> -nodefaults-based info on the test code.
>
> The following machines won't work with -nodefaults:
>
> These make QEMU segfault:
> * cubieboard
> * petalogix-ml605
> * or32-sim
> * virtex-ml507
> * Niagara
Bugs.
> These exit with a "missing SecureDigital device" error:
> * akita
> * borzoi
> * cheetah
> * connex
> * mainstone
> * n800
> * n810
> * spitz
> * sx1
> * sx1-v1
> * terrier
> * tosa
> * verdex
> * z2
Bugs only if there is no other way to provide the SD device. I believe
some variation if -drive if=sd,... should do fine.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines'
2016-11-24 13:34 ` Markus Armbruster
@ 2016-11-24 14:12 ` Eduardo Habkost
2016-11-24 14:55 ` Markus Armbruster
2016-11-24 14:22 ` Marcel Apfelbaum
1 sibling, 1 reply; 43+ messages in thread
From: Eduardo Habkost @ 2016-11-24 14:12 UTC (permalink / raw)
To: Markus Armbruster
Cc: Marcel Apfelbaum, libvir-list, Michael S. Tsirkin, qemu-devel,
Laine Stump
On Thu, Nov 24, 2016 at 02:34:05PM +0100, Markus Armbruster wrote:
> Eduardo Habkost <ehabkost@redhat.com> writes:
>
> > On Wed, Nov 23, 2016 at 06:43:16PM +0200, Marcel Apfelbaum wrote:
> >> On 11/22/2016 03:11 AM, Eduardo Habkost wrote:
> >> > The Problem
> >> > ===========
> >> >
> >> > Currently management software has no way to find out which device
> >> > types can be plugged in a machine, unless the machine is already
> >> > initialized.
>
> I doubt it can find the precise list of device types even for an
> initialized machine.
My plan is to make it possible. See:
[RFC 06/15] qdev: Add device_type field to BusClass
I will change how it looks like on v2 (mostly due to the PCI/PCIe
issues), but basically it makes all bus objects able to tell
which device types they accept.
>
> >> Hi Eduardo,
> >> Thank you for this interesting series. I think this is a problem
> >> worth addressing.
> >>
> >> > Even after the machine is initialized, there's no way to map
> >> > existing bus types to supported device types unless management
> >> > software hardcodes the mapping between bus types and device
> >> > types.
> >> >
> >>
> >> Here I am a little lost.
> >>
> >> We are going for machine => supported devices or
> >> bus-type => supported devices?
> >
> > On this series, we go for machine-type => supported-devices.
> >
> > A bus-type => supported-devices map wouldn't work because
> > different PCIe bus instances might accept different types of
> > devices (so supported-devices depend on the specific bus
> > instance, not only on the bus-type).
> >
> > v2 will probably be more detailed. I plan to change it to:
> >
> > query-machine(machine-type) => list of BusInfo
> >
> > BusInfo would contain:
> > * bus-type
> > * bus-path
> > * accepted-device-types (list of type/interface names)
>
> Let me take a step back and explore what questions a management
> application may want to ask. I think the basic questions are:
>
> * Which devices models could be plugged now?
>
> "Now" means in the current state of the machine. Depending on "now",
> this could be hot- or cold-plug.
Yes.
>
> * Into which sockets could device model T be plugged now?
>
> Mind, I wrote "socket", not bus. Buses provide sockets, but they are
> not the only provider of sockets.
>
> We need a way to name sockets. (QOM path to device or bus, socket
> address on device or bus) could work.
Naming "sockets" was not on my model, but I think we can do that.
I will probably send RFC v2 without any socket abstraction, so
other conceptual changes I am introducing can be reviewed
(especially the PCI/PCIe mess I am diving into, right now). But I
will try to document how the design can evolve to handle sockets.
>
> Are we on the same page so far?
Yes.
>
> Related: same questions with "newly created machine of machine type M"
> instead of "now". This isn't basic, because you could always create the
> machine, then ask the basic question. But not having to create the
> machine is convenient, in particular as long as a single QEMU process
> can only ever create one machine.
>
> Related: same, with creation options.
>
> Your series provides a solution for a special non-basic case: newly
> created machine of machine type M with no optional parts, i.e. with
> -nodefaults and nothing else. Or maybe with the default set of optional
> parts, i.e. without -nodefaults, not sure.
>
> I'm not demanding you provide a solution for the general case first. It
> would be nice, but it could be too complex for a first step. I do
> recommend you design your solution for the special case with the general
> case in mind. Say, by trying to ensure the special case query returns
> something that will do or can be evolved to do for the general case,
> too.
Yep. I will keep that in mind.
>
> >> > Example: floppy support on q35 vs i440fx
> >> > ----------------------------------------
> >> >
> >> > There's no way for libvirt to find out that there's no floppy
> >> > controller on pc-q35-* machine-types by default.
> >> >
> >>
> >> Again "by default". So do we want to query the init state of a machine?
> >> What devices are there? Or what devices *can be* there?
> >
> > "by default" means what's present when using "-machine <machine>"
> > with no extra -device arguments.
>
> Not just -device. Some legacy options can also create buses. For
> instance, -device if=scsi,... creates a SCSI bus.
Right. I found that out when debugging the -nodefaults issues.
>
> > We want to know what _buses_ are always there. Which in turn lets
> > management know which _device_ types _can_ be plugged.
> >
> >>
> >> > With this series, pc-i440fx-* will report "floppy" as a supported
> >> > device type, but pc-q35-* will not.
> >> >
> >> > Example: Legacy PCI vs vs PCIe devices
> >> > --------------------------------------
> >> >
> >> > Some devices require a PCIe bus to be available, others work on
> >> > both legacy PCI and PCIe, while others work only on a legacy PCI
> >> > bus.
> >> >
> >> > Currently management software has no way to know which devices
> >> > can be added to a given machine, unless it hardcodes machine-type
> >> > names and device-types names.
> >> >
> >>
> >> Again it seems a double problem, machine => devices vs pci/pcie bus => devices.
> >> The bus => devices match is not related to a machine type.
> >
> > A bus-type => device-type match would not depend on the
> > machine-type, but it would not be useful: different bus instances
> > can accept different device-types (and the way the bus topology
> > is configured depend on the machine-type).
> >
> >
> >>
> >> > The Proposed Interface
> >> > ======================
> >> >
> >> > This series adds a new field to the output of 'query-machines':
> >> > 'supported-device-types'. It will contain a list of QOM type
> >> > names, that can be used to find the list of device types that can
> >> > be plugged in the machine by default.
> >>
> >> What do you mean "by default"? Without bridges or part of the machine itself?
> >
> > I mean "when you just run -machine with no extra -device
> > arguments".
> >
> >>
> >> The type names reported on
> >> > the new field can then be used as the 'implements' argument on
> >> > the 'qom-list-types' command, to find out which device types can
> >> > be plugged on the machine.
> >> >
> >> > Example output
> >> > --------------
> >> >
> >> > (QEMU) query-machines
> >> > {
> >> > "return": [
> >> > [...]
> >> > {
> >> > "supported-device-types": [
> >> > "sys-bus-device"
> >>
> >>
> >> I don't know how "sys-bus-device" can help us... :)
> >
> > Yes, I added comments about it below. :)
>
> The sysbus has always been a cop-out. It's a catch-all pseudo-bus. The
> only thing sysbus devices really have in common is that they can't plug
> into any real bus.
>
> This used to be an academic issue until Alex made some sysbus devices
> pluggable. Before, "sysbus device" told you everything about
> pluggability you needed to know: not pluggable. Since then, it tells
> you nothing. We'll have to address this regression eventually. See
> "TYPE_SYS_BUS_DEVICE is too generic" below.
>
> >> > ],
> >> > "cpu-max": 1,
> >> > "hotpluggable-cpus": false,
> >> > "name": "none"
> >> > },
> >> > [...]
> >> > {
> >> > "supported-device-types": [
> >> > "sys-bus-device"
> >> > ],
> >> > "cpu-max": 1,
> >> > "hotpluggable-cpus": false,
> >> > "name": "xenpv"
> >> > },
> >> > [...]
> >> > {
> >> > "supported-device-types": [
> >> > "sys-bus-device",
> >> > "floppy",
> >> > "i2c-slave",
> >> > "pci-device",
> >> > "isa-device",
> >> > "ide-device"
> >>
> >> Is don't know is this high level classification is useful,
> >> here is an example:
> >>
> >> pvi-device is supported => then we look for all pci devices?
> >> But what if some pci devices make sense on a machine type,
> >> but not on another?
> >
> > If not all pci devices are supported, then the machine must not
> > return "pci-device" as supported. We need to define a new
> > type/interface name that would be implemented only by the
> > supported devices. e.g. "legacy-pci-device".
>
> Before PCIe, "PCI device" told you everything about pluggability you
> needed to know: can be plugged into a PCI bus. Since PCIe, it doesn't.
> We'll have to address this regression, too. See "PCI vs PCIe" below.
I am trying to clean up the PCI/PCIe mess right now, for v2.
>
> >> > ],
> >> > "name": "pc-i440fx-2.8",
> >> > "alias": "pc",
> >> > "is-default": true,
> >> > "cpu-max": 255,
> >> > "hotpluggable-cpus": true
> >> > },
> >> > [...]
> >> > {
> >> > "supported-device-types": [
> >> > "sys-bus-device",
> >> > "floppy",
> >> > "isa-device",
> >> > "ide-device"
> >> > ],
> >> > "cpu-max": 1,
> >> > "hotpluggable-cpus": true,
> >> > "name": "isapc"
> >> > },
> >> > [...]
> >> > {
> >> > "supported-device-types": [
> >> > "sys-bus-device",
> >> > "floppy",
> >> > "i2c-slave",
> >> > "pci-device",
> >> > "isa-device",
> >> > "ide-device"
> >> > ],
> >> > "cpu-max": 128,
> >> > "hotpluggable-cpus": true,
> >> > "name": "xenfv"
> >> > },
> >> > [...]
> >> > {
> >> > "alias": "q35",
> >> > "supported-device-types": [
> >> > "sys-bus-device",
> >> > "i2c-slave",
> >> > "PCIE-device",
> >> > "isa-device",
> >> > "ide-device"
> >> > ],
> >> > "cpu-max": 288,
> >> > "hotpluggable-cpus": true,
> >> > "name": "pc-q35-2.8"
> >> > },
> >> > [...]
> >> > ]
> >> > }
> >> >
> >> > Considered alternatives
> >> > =======================
> >> >
> >> > Indirect mapping (machine => bus => device)
> >> > -------------------------------------------
> >> >
> >> > This RFC implements a mechanism to implement ax
> >> > machine-type => supported-device-types
> >> > mapping. An alternative solution I considered was to expose an
> >> > indirect mapping:
> >> > machine-type => default-bus-types
> >> > followed by
> >> > bus-type => supported-device-types.
> >> >
> >>
> >> As I previously stated, I don't know if it helps. bus-type
> >> can support different devices on different archs.
> >
> > Yes. After learning a bit more about PCIe, I am convinced that a
> > bus->type => device-types mapping won't help.
> >
> >>
> >> > But exposing only the resulting supported device-types list
> >> > imposes less restrictions on how the device and bus type
> >> > hierarchy is implemented inside QEMU. There's still a
> >> > machine-type => bus-type => device-type
> >> > mapping implemented internally, but it is an implementation
> >> > detail on the current version, and not part of the
> >> > externally-visible interface.
> >> >
> >>
> >> Good, I personally don't like this "pass".
>
> Point taken.
>
> The core idea here seems to be using the QOM type hierarchy for
> representing "pluggability".
Exactly.
>
> >> > The Implementation
> >> > ==================
> [Skipping for now...]
> >> >
> >> > Limitations
> >> > ===========
> >> >
> >> > TYPE_SYS_BUS_DEVICE is too generic
> >> > ----------------------------------
> >> >
> >> > Currently all machines have a TYPE_SYS_BUS bus, meaning all
> >> > TYPE_SYS_BUS_DEVICE subclasses are reported as supported.
> >> >
> >>
> >> Agreed, this is a problem.
> >>
> >> > The current solution in this series is to report
> >> > TYPE_SYS_BUS_DEVICE as supported by all machines.
>
> Because all machines have this catch-all pseudo-bus. Reporting it
> exists is correct, but as is the information is useless.
I will probably keep returning it by default (to make the
existing information correct), but provide mechanisms for
machine-types to return more precise information.
>
> >> > But we could
> >> > gradually add arch-specific or machine-family-specific interface
> >> > names that can be used on devices that are meant to work with
> >> > only a subset of TYPE_SYS_BUS_DEVICE subclasses.
>
> Basically, encode pluggability information in the QOM type hierarchy.
>
> To gauge whether that would work I'd have to actually understand how
> exactly pluggable sysbus devices work, in particular what the conditions
> for accepting a plug are.
I can't evaluate that, either.
But note that covering 100% of the pluggability decisions for
sysbus is not one of the problems I am trying to solve right now.
I mean: if the new mechanisms can cover it too, great, but they
don't (and there's no obvious solution for it), it is out of
scope.
>
> >> > A future version of this series may remove TYPE_SYS_BUS_DEVICE
> >> > from the supported-device-types output, and return a
> >> > arch-specific or machine-family-specific interface name to
> >> > restrict management software to a subset of TYPE_SYS_BUS_DEVICE
> >> > subclasses.
> >> >
> >> > PCI vs PCIe
> >> > -----------
> >> >
> >> > Machines with PCIe buses will report INTERFACE_PCIE_DEVICE on
> >> > supported-device-types.
> >> >
> >> > Machines with legacy PCI buses will report TYPE_PCI_DEVICE on
> >> > supported-device-types.
> >> >
> >> > The problem with the current approach is that PCIe devices are
> >> > TYPE_PCI_DEVICE subclasses. The allows PCI device classes to
> >> > indicate they are PCIe-capable, but there's no obvious way to
> >> > indicate that a device is PCIe-only. This needs to be addressed
> >> > in a future version of this series.
> >> >
> >> > Suggestions are welcome.
> >>
> >>
> >> As we talked offline, I personally like an interface IPCIType
> >> with a field having 3 possible values {pci/pcie/hybrid}
> >>
> >> To understand how hybrid works we need some rules, like
> >> "pci on pci bus/pcie on pcie bus"
> >> "pcie on a non-root pcie bus/pcie otherwise
> >>
> >> I don't think we'll have a lot of rules, simple boolean fields
> >> for the interface should be enough.
> >
> > What you propose makes sense, the only difference is that the
> > boolean fields would be just interface names that can be used as
> > the "implements" argument on qom-list-types.
> >
> > e.g.:
> >
> > * Hybrid PCI device-types would implement both "legacy-pci-device" and
> > "pcie-device" interfaces.
> > * PCIe-only device-types would implement only the "pcie-device"
> > interface.
> > * Legacy-PCI-only device-types would implement only the
> > "legacy-pci-device" interface.
>
> In other words, encode "pluggability" in the QOM type hierarchy.
>
> > Then, the bus instances would have a 'accepted-device-types'
> > field:
> >
> > * A legacy PCI bus would accept only "legacy-pci-device" devices.
> > * A PCIe-only bus would accept only "pcie-device" devices.
> > * A PCIe bus that accepts legacy PCI devices (the root bus?)
> > would accept both "legacy-pci-device" and "pcie-device"
> > devices.
> >
> > Then, query-machines would return the list of bus instances that
> > machine init creates, containing the bus ID, bus type, and
> > accepted-device-types.
> >
> > Does that make sense?
>
> Yes.
>
> Our decision to have hybrid PCI/PCIe devices and buses breeds
> considerable complexity. I wish we had avoided them, but I believe it's
> too late to change now.
I'm diving into it right now. v2 will have some attempts to sort
it out.
>
> >> This still does not solve the problem that some devices makes
> >> sense only on a specific arch.
>
> Examples?
>
> > Right now, we can simply compile out arch-specific devices that
> > can never be plugged in a QEMU binary. But if we still want them
> > compiled in for some reason, we can categorize them on a
> > different type/interface name, and the corresponding machine-type
> > would tell management that their buses accept only the
> > arch-specific type/interface name.
>
> Could become messy. Can't say without looking at examples.
Can't say, either.
>
> >> > Incomplete bus lists on some machines
> >> > -------------------------------------
> >> >
> >> > With this series, not all machines classes are changed to add the
> >> > full list of device types on the 'supported-device-types'. To
> >> > allow the code to be updated gradually, qmp-machine-info.py has a
> >> > STRICT_ARCHES variable, that will make the test code require a
> >> > complete device type list only on some architectures.
>
> Ideally, pluggability information would be derived from QOM. I figure
> that's the only practical way to solve the general case.
>
> For the special case "newly created machine", deriving from QOM may be
> impractical, say because you'd have to create the machine. Then you
> have to hard-code the result somehow. Tests to validate the hardcoded
> results match the results you get when you actually create the machine
> would be required, at least once you *can* get results for a created
> machine.
Tests were implemented, see
[RFC 08/15] qmp: Add 'supported-device-types' field to 'query-machines'.
>
> >> > Out of scope: Configurable buses
> >> > --------------------------------
> >> >
> >> > There's no way to map machine options like "usb=on|off" to
> >> > device-types or buses. I plan to propose a new interface that
> >> > allows machine options to be mapped to buses/device-types later.
> >> >
> >> > Out of scope: Deciding where to plug devices
> >> > --------------------------------------------
> >> >
> >> > Once management software discovers which devices can be plugged
> >> > to a machine, it still has to discover or define where devices
> >> > can/should/will be plugged. This is out of the scope of this
> >> > series.
> >> >
> >>
> >> That's a pitty :(
> >> I was hoping this series will solve this issue. But if it prepares
> >> the grounds for it is also a good step .
> >
> > The bus ID will be in the scope of v2.
>
> I'm afraid "bus" is insufficiently general.
Does "socket" sound general enough?
>
> >> Thanks,
> >> Marcel
> >>
> >> > Out of scope: Hotplug
> >> > ---------------------
> >> >
> >> > The proposed interface is supposed to help management software
> >> > find which device types can be used when creating the VM. Device
> >> > hotplug is out of the scope of this series. However, the new
> >> > 'device-types' QOM property on bus objects could be used to find
> >> > out which device types can be plugged on the existing buses.
--
Eduardo
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines'
2016-11-24 13:34 ` Markus Armbruster
2016-11-24 14:12 ` Eduardo Habkost
@ 2016-11-24 14:22 ` Marcel Apfelbaum
2016-11-24 15:41 ` Markus Armbruster
1 sibling, 1 reply; 43+ messages in thread
From: Marcel Apfelbaum @ 2016-11-24 14:22 UTC (permalink / raw)
To: Markus Armbruster, Eduardo Habkost
Cc: libvir-list, Michael S. Tsirkin, qemu-devel, Laine Stump
On 11/24/2016 03:34 PM, Markus Armbruster wrote:
> Eduardo Habkost <ehabkost@redhat.com> writes:
>
>> On Wed, Nov 23, 2016 at 06:43:16PM +0200, Marcel Apfelbaum wrote:
>>> On 11/22/2016 03:11 AM, Eduardo Habkost wrote:
>>>> The Problem
>>
[...]
> Our decision to have hybrid PCI/PCIe devices and buses breeds
> considerable complexity. I wish we had avoided them, but I believe it's
> too late to change now.
>
>>> This still does not solve the problem that some devices makes
>>> sense only on a specific arch.
>
Hi Markus,
> Examples?
>
One quick example would be that we don't want to see
Intel's IOH 3420 PCIe Root Port in an ARM machine,
or a pxb on a Q35 machine (in this case we want pxb-pcie)
I do believe there are other examples, I'll try to think of more.
Thanks,
Marcel
[...]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines'
2016-11-24 14:12 ` Eduardo Habkost
@ 2016-11-24 14:55 ` Markus Armbruster
0 siblings, 0 replies; 43+ messages in thread
From: Markus Armbruster @ 2016-11-24 14:55 UTC (permalink / raw)
To: Eduardo Habkost
Cc: Marcel Apfelbaum, libvir-list, qemu-devel, Laine Stump,
Michael S. Tsirkin
Eduardo Habkost <ehabkost@redhat.com> writes:
> On Thu, Nov 24, 2016 at 02:34:05PM +0100, Markus Armbruster wrote:
>> Eduardo Habkost <ehabkost@redhat.com> writes:
>>
>> > On Wed, Nov 23, 2016 at 06:43:16PM +0200, Marcel Apfelbaum wrote:
>> >> On 11/22/2016 03:11 AM, Eduardo Habkost wrote:
>> >> > The Problem
>> >> > ===========
>> >> >
>> >> > Currently management software has no way to find out which device
>> >> > types can be plugged in a machine, unless the machine is already
>> >> > initialized.
>>
>> I doubt it can find the precise list of device types even for an
>> initialized machine.
>
> My plan is to make it possible. See:
> [RFC 06/15] qdev: Add device_type field to BusClass
>
> I will change how it looks like on v2 (mostly due to the PCI/PCIe
> issues), but basically it makes all bus objects able to tell
> which device types they accept.
Sounds like a step forward.
>> >> Hi Eduardo,
>> >> Thank you for this interesting series. I think this is a problem
>> >> worth addressing.
>> >>
>> >> > Even after the machine is initialized, there's no way to map
>> >> > existing bus types to supported device types unless management
>> >> > software hardcodes the mapping between bus types and device
>> >> > types.
>> >> >
>> >>
>> >> Here I am a little lost.
>> >>
>> >> We are going for machine => supported devices or
>> >> bus-type => supported devices?
>> >
>> > On this series, we go for machine-type => supported-devices.
>> >
>> > A bus-type => supported-devices map wouldn't work because
>> > different PCIe bus instances might accept different types of
>> > devices (so supported-devices depend on the specific bus
>> > instance, not only on the bus-type).
>> >
>> > v2 will probably be more detailed. I plan to change it to:
>> >
>> > query-machine(machine-type) => list of BusInfo
>> >
>> > BusInfo would contain:
>> > * bus-type
>> > * bus-path
>> > * accepted-device-types (list of type/interface names)
>>
>> Let me take a step back and explore what questions a management
>> application may want to ask. I think the basic questions are:
>>
>> * Which devices models could be plugged now?
>>
>> "Now" means in the current state of the machine. Depending on "now",
>> this could be hot- or cold-plug.
>
> Yes.
>
>>
>> * Into which sockets could device model T be plugged now?
>>
>> Mind, I wrote "socket", not bus. Buses provide sockets, but they are
>> not the only provider of sockets.
>>
>> We need a way to name sockets. (QOM path to device or bus, socket
>> address on device or bus) could work.
>
> Naming "sockets" was not on my model, but I think we can do that.
>
> I will probably send RFC v2 without any socket abstraction, so
> other conceptual changes I am introducing can be reviewed
> (especially the PCI/PCIe mess I am diving into, right now). But I
> will try to document how the design can evolve to handle sockets.
Makes sense.
>> Are we on the same page so far?
>
> Yes.
>
>>
>> Related: same questions with "newly created machine of machine type M"
>> instead of "now". This isn't basic, because you could always create the
>> machine, then ask the basic question. But not having to create the
>> machine is convenient, in particular as long as a single QEMU process
>> can only ever create one machine.
>>
>> Related: same, with creation options.
>>
>> Your series provides a solution for a special non-basic case: newly
>> created machine of machine type M with no optional parts, i.e. with
>> -nodefaults and nothing else. Or maybe with the default set of optional
>> parts, i.e. without -nodefaults, not sure.
>>
>> I'm not demanding you provide a solution for the general case first. It
>> would be nice, but it could be too complex for a first step. I do
>> recommend you design your solution for the special case with the general
>> case in mind. Say, by trying to ensure the special case query returns
>> something that will do or can be evolved to do for the general case,
>> too.
>
> Yep. I will keep that in mind.
>
>>
>> >> > Example: floppy support on q35 vs i440fx
>> >> > ----------------------------------------
>> >> >
>> >> > There's no way for libvirt to find out that there's no floppy
>> >> > controller on pc-q35-* machine-types by default.
>> >> >
>> >>
>> >> Again "by default". So do we want to query the init state of a machine?
>> >> What devices are there? Or what devices *can be* there?
>> >
>> > "by default" means what's present when using "-machine <machine>"
>> > with no extra -device arguments.
>>
>> Not just -device. Some legacy options can also create buses. For
>> instance, -device if=scsi,... creates a SCSI bus.
>
> Right. I found that out when debugging the -nodefaults issues.
>
>>
>> > We want to know what _buses_ are always there. Which in turn lets
>> > management know which _device_ types _can_ be plugged.
>> >
>> >>
>> >> > With this series, pc-i440fx-* will report "floppy" as a supported
>> >> > device type, but pc-q35-* will not.
>> >> >
>> >> > Example: Legacy PCI vs vs PCIe devices
>> >> > --------------------------------------
>> >> >
>> >> > Some devices require a PCIe bus to be available, others work on
>> >> > both legacy PCI and PCIe, while others work only on a legacy PCI
>> >> > bus.
>> >> >
>> >> > Currently management software has no way to know which devices
>> >> > can be added to a given machine, unless it hardcodes machine-type
>> >> > names and device-types names.
>> >> >
>> >>
>> >> Again it seems a double problem, machine => devices vs pci/pcie bus => devices.
>> >> The bus => devices match is not related to a machine type.
>> >
>> > A bus-type => device-type match would not depend on the
>> > machine-type, but it would not be useful: different bus instances
>> > can accept different device-types (and the way the bus topology
>> > is configured depend on the machine-type).
>> >
>> >
>> >>
>> >> > The Proposed Interface
>> >> > ======================
>> >> >
>> >> > This series adds a new field to the output of 'query-machines':
>> >> > 'supported-device-types'. It will contain a list of QOM type
>> >> > names, that can be used to find the list of device types that can
>> >> > be plugged in the machine by default.
>> >>
>> >> What do you mean "by default"? Without bridges or part of the machine itself?
>> >
>> > I mean "when you just run -machine with no extra -device
>> > arguments".
>> >
>> >>
>> >> The type names reported on
>> >> > the new field can then be used as the 'implements' argument on
>> >> > the 'qom-list-types' command, to find out which device types can
>> >> > be plugged on the machine.
>> >> >
>> >> > Example output
>> >> > --------------
>> >> >
>> >> > (QEMU) query-machines
>> >> > {
>> >> > "return": [
>> >> > [...]
>> >> > {
>> >> > "supported-device-types": [
>> >> > "sys-bus-device"
>> >>
>> >>
>> >> I don't know how "sys-bus-device" can help us... :)
>> >
>> > Yes, I added comments about it below. :)
>>
>> The sysbus has always been a cop-out. It's a catch-all pseudo-bus. The
>> only thing sysbus devices really have in common is that they can't plug
>> into any real bus.
>>
>> This used to be an academic issue until Alex made some sysbus devices
>> pluggable. Before, "sysbus device" told you everything about
>> pluggability you needed to know: not pluggable. Since then, it tells
>> you nothing. We'll have to address this regression eventually. See
>> "TYPE_SYS_BUS_DEVICE is too generic" below.
>>
>> >> > ],
>> >> > "cpu-max": 1,
>> >> > "hotpluggable-cpus": false,
>> >> > "name": "none"
>> >> > },
>> >> > [...]
>> >> > {
>> >> > "supported-device-types": [
>> >> > "sys-bus-device"
>> >> > ],
>> >> > "cpu-max": 1,
>> >> > "hotpluggable-cpus": false,
>> >> > "name": "xenpv"
>> >> > },
>> >> > [...]
>> >> > {
>> >> > "supported-device-types": [
>> >> > "sys-bus-device",
>> >> > "floppy",
>> >> > "i2c-slave",
>> >> > "pci-device",
>> >> > "isa-device",
>> >> > "ide-device"
>> >>
>> >> Is don't know is this high level classification is useful,
>> >> here is an example:
>> >>
>> >> pvi-device is supported => then we look for all pci devices?
>> >> But what if some pci devices make sense on a machine type,
>> >> but not on another?
>> >
>> > If not all pci devices are supported, then the machine must not
>> > return "pci-device" as supported. We need to define a new
>> > type/interface name that would be implemented only by the
>> > supported devices. e.g. "legacy-pci-device".
>>
>> Before PCIe, "PCI device" told you everything about pluggability you
>> needed to know: can be plugged into a PCI bus. Since PCIe, it doesn't.
>> We'll have to address this regression, too. See "PCI vs PCIe" below.
>
> I am trying to clean up the PCI/PCIe mess right now, for v2.
>
>>
>> >> > ],
>> >> > "name": "pc-i440fx-2.8",
>> >> > "alias": "pc",
>> >> > "is-default": true,
>> >> > "cpu-max": 255,
>> >> > "hotpluggable-cpus": true
>> >> > },
>> >> > [...]
>> >> > {
>> >> > "supported-device-types": [
>> >> > "sys-bus-device",
>> >> > "floppy",
>> >> > "isa-device",
>> >> > "ide-device"
>> >> > ],
>> >> > "cpu-max": 1,
>> >> > "hotpluggable-cpus": true,
>> >> > "name": "isapc"
>> >> > },
>> >> > [...]
>> >> > {
>> >> > "supported-device-types": [
>> >> > "sys-bus-device",
>> >> > "floppy",
>> >> > "i2c-slave",
>> >> > "pci-device",
>> >> > "isa-device",
>> >> > "ide-device"
>> >> > ],
>> >> > "cpu-max": 128,
>> >> > "hotpluggable-cpus": true,
>> >> > "name": "xenfv"
>> >> > },
>> >> > [...]
>> >> > {
>> >> > "alias": "q35",
>> >> > "supported-device-types": [
>> >> > "sys-bus-device",
>> >> > "i2c-slave",
>> >> > "PCIE-device",
>> >> > "isa-device",
>> >> > "ide-device"
>> >> > ],
>> >> > "cpu-max": 288,
>> >> > "hotpluggable-cpus": true,
>> >> > "name": "pc-q35-2.8"
>> >> > },
>> >> > [...]
>> >> > ]
>> >> > }
>> >> >
>> >> > Considered alternatives
>> >> > =======================
>> >> >
>> >> > Indirect mapping (machine => bus => device)
>> >> > -------------------------------------------
>> >> >
>> >> > This RFC implements a mechanism to implement ax
>> >> > machine-type => supported-device-types
>> >> > mapping. An alternative solution I considered was to expose an
>> >> > indirect mapping:
>> >> > machine-type => default-bus-types
>> >> > followed by
>> >> > bus-type => supported-device-types.
>> >> >
>> >>
>> >> As I previously stated, I don't know if it helps. bus-type
>> >> can support different devices on different archs.
>> >
>> > Yes. After learning a bit more about PCIe, I am convinced that a
>> > bus->type => device-types mapping won't help.
>> >
>> >>
>> >> > But exposing only the resulting supported device-types list
>> >> > imposes less restrictions on how the device and bus type
>> >> > hierarchy is implemented inside QEMU. There's still a
>> >> > machine-type => bus-type => device-type
>> >> > mapping implemented internally, but it is an implementation
>> >> > detail on the current version, and not part of the
>> >> > externally-visible interface.
>> >> >
>> >>
>> >> Good, I personally don't like this "pass".
>>
>> Point taken.
>>
>> The core idea here seems to be using the QOM type hierarchy for
>> representing "pluggability".
>
> Exactly.
>
>>
>> >> > The Implementation
>> >> > ==================
>> [Skipping for now...]
>> >> >
>> >> > Limitations
>> >> > ===========
>> >> >
>> >> > TYPE_SYS_BUS_DEVICE is too generic
>> >> > ----------------------------------
>> >> >
>> >> > Currently all machines have a TYPE_SYS_BUS bus, meaning all
>> >> > TYPE_SYS_BUS_DEVICE subclasses are reported as supported.
>> >> >
>> >>
>> >> Agreed, this is a problem.
>> >>
>> >> > The current solution in this series is to report
>> >> > TYPE_SYS_BUS_DEVICE as supported by all machines.
>>
>> Because all machines have this catch-all pseudo-bus. Reporting it
>> exists is correct, but as is the information is useless.
>
> I will probably keep returning it by default (to make the
> existing information correct), but provide mechanisms for
> machine-types to return more precise information.
>
>>
>> >> > But we could
>> >> > gradually add arch-specific or machine-family-specific interface
>> >> > names that can be used on devices that are meant to work with
>> >> > only a subset of TYPE_SYS_BUS_DEVICE subclasses.
>>
>> Basically, encode pluggability information in the QOM type hierarchy.
>>
>> To gauge whether that would work I'd have to actually understand how
>> exactly pluggable sysbus devices work, in particular what the conditions
>> for accepting a plug are.
>
> I can't evaluate that, either.
>
> But note that covering 100% of the pluggability decisions for
> sysbus is not one of the problems I am trying to solve right now.
> I mean: if the new mechanisms can cover it too, great, but they
> don't (and there's no obvious solution for it), it is out of
> scope.
We don't have to solve all the problems right away. But the less we
know about the problems we're not solving right away, the higher the
risk of accidentally creating obstacles to solving them later.
>> >> > A future version of this series may remove TYPE_SYS_BUS_DEVICE
>> >> > from the supported-device-types output, and return a
>> >> > arch-specific or machine-family-specific interface name to
>> >> > restrict management software to a subset of TYPE_SYS_BUS_DEVICE
>> >> > subclasses.
>> >> >
>> >> > PCI vs PCIe
>> >> > -----------
>> >> >
>> >> > Machines with PCIe buses will report INTERFACE_PCIE_DEVICE on
>> >> > supported-device-types.
>> >> >
>> >> > Machines with legacy PCI buses will report TYPE_PCI_DEVICE on
>> >> > supported-device-types.
>> >> >
>> >> > The problem with the current approach is that PCIe devices are
>> >> > TYPE_PCI_DEVICE subclasses. The allows PCI device classes to
>> >> > indicate they are PCIe-capable, but there's no obvious way to
>> >> > indicate that a device is PCIe-only. This needs to be addressed
>> >> > in a future version of this series.
>> >> >
>> >> > Suggestions are welcome.
>> >>
>> >>
>> >> As we talked offline, I personally like an interface IPCIType
>> >> with a field having 3 possible values {pci/pcie/hybrid}
>> >>
>> >> To understand how hybrid works we need some rules, like
>> >> "pci on pci bus/pcie on pcie bus"
>> >> "pcie on a non-root pcie bus/pcie otherwise
>> >>
>> >> I don't think we'll have a lot of rules, simple boolean fields
>> >> for the interface should be enough.
>> >
>> > What you propose makes sense, the only difference is that the
>> > boolean fields would be just interface names that can be used as
>> > the "implements" argument on qom-list-types.
>> >
>> > e.g.:
>> >
>> > * Hybrid PCI device-types would implement both "legacy-pci-device" and
>> > "pcie-device" interfaces.
>> > * PCIe-only device-types would implement only the "pcie-device"
>> > interface.
>> > * Legacy-PCI-only device-types would implement only the
>> > "legacy-pci-device" interface.
>>
>> In other words, encode "pluggability" in the QOM type hierarchy.
>>
>> > Then, the bus instances would have a 'accepted-device-types'
>> > field:
>> >
>> > * A legacy PCI bus would accept only "legacy-pci-device" devices.
>> > * A PCIe-only bus would accept only "pcie-device" devices.
>> > * A PCIe bus that accepts legacy PCI devices (the root bus?)
>> > would accept both "legacy-pci-device" and "pcie-device"
>> > devices.
>> >
>> > Then, query-machines would return the list of bus instances that
>> > machine init creates, containing the bus ID, bus type, and
>> > accepted-device-types.
>> >
>> > Does that make sense?
>>
>> Yes.
>>
>> Our decision to have hybrid PCI/PCIe devices and buses breeds
>> considerable complexity. I wish we had avoided them, but I believe it's
>> too late to change now.
>
> I'm diving into it right now. v2 will have some attempts to sort
> it out.
>
>>
>> >> This still does not solve the problem that some devices makes
>> >> sense only on a specific arch.
>>
>> Examples?
>>
>> > Right now, we can simply compile out arch-specific devices that
>> > can never be plugged in a QEMU binary. But if we still want them
>> > compiled in for some reason, we can categorize them on a
>> > different type/interface name, and the corresponding machine-type
>> > would tell management that their buses accept only the
>> > arch-specific type/interface name.
>>
>> Could become messy. Can't say without looking at examples.
>
> Can't say, either.
>
>>
>> >> > Incomplete bus lists on some machines
>> >> > -------------------------------------
>> >> >
>> >> > With this series, not all machines classes are changed to add the
>> >> > full list of device types on the 'supported-device-types'. To
>> >> > allow the code to be updated gradually, qmp-machine-info.py has a
>> >> > STRICT_ARCHES variable, that will make the test code require a
>> >> > complete device type list only on some architectures.
>>
>> Ideally, pluggability information would be derived from QOM. I figure
>> that's the only practical way to solve the general case.
>>
>> For the special case "newly created machine", deriving from QOM may be
>> impractical, say because you'd have to create the machine. Then you
>> have to hard-code the result somehow. Tests to validate the hardcoded
>> results match the results you get when you actually create the machine
>> would be required, at least once you *can* get results for a created
>> machine.
>
> Tests were implemented, see
> [RFC 08/15] qmp: Add 'supported-device-types' field to 'query-machines'.
>
>>
>> >> > Out of scope: Configurable buses
>> >> > --------------------------------
>> >> >
>> >> > There's no way to map machine options like "usb=on|off" to
>> >> > device-types or buses. I plan to propose a new interface that
>> >> > allows machine options to be mapped to buses/device-types later.
>> >> >
>> >> > Out of scope: Deciding where to plug devices
>> >> > --------------------------------------------
>> >> >
>> >> > Once management software discovers which devices can be plugged
>> >> > to a machine, it still has to discover or define where devices
>> >> > can/should/will be plugged. This is out of the scope of this
>> >> > series.
>> >> >
>> >>
>> >> That's a pitty :(
>> >> I was hoping this series will solve this issue. But if it prepares
>> >> the grounds for it is also a good step .
>> >
>> > The bus ID will be in the scope of v2.
>>
>> I'm afraid "bus" is insufficiently general.
>
> Does "socket" sound general enough?
Yes, because "socket" isn't defined, yet, so we can make it whatever it
needs to be :)
>> >> Thanks,
>> >> Marcel
>> >>
>> >> > Out of scope: Hotplug
>> >> > ---------------------
>> >> >
>> >> > The proposed interface is supposed to help management software
>> >> > find which device types can be used when creating the VM. Device
>> >> > hotplug is out of the scope of this series. However, the new
>> >> > 'device-types' QOM property on bus objects could be used to find
>> >> > out which device types can be plugged on the existing buses.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines'
2016-11-24 14:22 ` Marcel Apfelbaum
@ 2016-11-24 15:41 ` Markus Armbruster
2016-11-24 16:31 ` Marcel Apfelbaum
0 siblings, 1 reply; 43+ messages in thread
From: Markus Armbruster @ 2016-11-24 15:41 UTC (permalink / raw)
To: Marcel Apfelbaum
Cc: Eduardo Habkost, libvir-list, qemu-devel, Laine Stump,
Michael S. Tsirkin
Marcel Apfelbaum <marcel@redhat.com> writes:
> On 11/24/2016 03:34 PM, Markus Armbruster wrote:
>> Eduardo Habkost <ehabkost@redhat.com> writes:
>>
>>> On Wed, Nov 23, 2016 at 06:43:16PM +0200, Marcel Apfelbaum wrote:
>>>> On 11/22/2016 03:11 AM, Eduardo Habkost wrote:
>>>>> The Problem
>>>
>
> [...]
>
>> Our decision to have hybrid PCI/PCIe devices and buses breeds
>> considerable complexity. I wish we had avoided them, but I believe it's
>> too late to change now.
>>
>>>> This still does not solve the problem that some devices makes
>>>> sense only on a specific arch.
>>
>
> Hi Markus,
>
>> Examples?
>>
>
> One quick example would be that we don't want to see
> Intel's IOH 3420 PCIe Root Port in an ARM machine,
> or a pxb on a Q35 machine (in this case we want pxb-pcie)
Such a device would be weird. But would it be wrong? Wrong enough for
QEMU to reject it? Unless QEMU rejects it, there's no reason not to
list it as pluggable.
> I do believe there are other examples, I'll try to think of more.
>
> Thanks,
> Marcel
>
> [...]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] -nodefaults and available buses (was Re: [RFC 00/15] qmp: Report supported device types on 'query-machines')
2016-11-24 1:51 ` David Gibson
@ 2016-11-24 16:30 ` Cornelia Huck
2016-11-24 17:42 ` Eduardo Habkost
0 siblings, 1 reply; 43+ messages in thread
From: Cornelia Huck @ 2016-11-24 16:30 UTC (permalink / raw)
To: David Gibson
Cc: Eduardo Habkost, Peter Maydell, Alex Williamson, Michael Roth,
Michael S. Tsirkin, Alexey Kardashevskiy, Mark Cave-Ayland,
qemu-devel, Markus Armbruster, Beniamino Galvani, libvir-list,
Greg Kurz, qemu-arm, qemu-ppc, Laine Stump, Edgar E. Iglesias,
Marcel Apfelbaum, Paolo Bonzini, Andrea Bolognani,
Artyom Tarasenko, Jia Liu
On Thu, 24 Nov 2016 12:51:19 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:
> On Wed, Nov 23, 2016 at 03:10:47PM -0200, Eduardo Habkost wrote:
> > (CCing the maintainers of the machines that crash when using
> > -nodefaults)
> >
> > On Tue, Nov 22, 2016 at 08:34:50PM -0200, Eduardo Habkost wrote:
> > [...]
> > > "default defaults" vs "-nodefault defaults"
> > > -------------------------------------------
> > >
> > > Two bad news:
> > >
> > > 1) We need to differentiate buses created by the machine with
> > > "-nodefaults" and buses that are created only without
> > > "-nodefaults".
> > >
> > > libvirt use -nodefaults when starting QEMU, so knowing which
> > > buses are available when using -nodefaults is more interesting
> > > for them.
> > >
> > > Other software, on the other hand, might be interested in the
> > > results without -nodefaults.
> > >
> > > We need to be able model both cases in the new interface.
> > > Suggestions are welcome.
> >
> > The good news is that the list is short. The only[1] machines
> > where the list of buses seem to change when using -nodefaults
> > are:
> >
> > * mpc8544ds
> > * ppce500
> > * mpc8544ds
> > * ppce500
> > * s390-ccw-virtio-*
> >
> > On all cases above, the only difference is that a virtio bus is
> > available if not using -nodefaults.
>
> Hrm.. that's odd. Well, it makes sense for the s390 which has special
> virtio arrangements.
I don't think it makes much sense for s390 either... is this a 'virtio'
bus or a 'virtio-{pci,ccw}' bus? The transport bus should be present
with -nodefaults; the virtio bus is basically a glue bus for virtio
devices...
> However, the others are all embedded ppc
> machines, whose virtio should be bog-standard virtio-pci. I'm
> wondering if the addition of the virtio "bus" is a side-effect of the
> NIC or storage device created without -nodefaults being virtio.
I'd suspect the default NICs (which are virtio at least in the s390
case).
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines'
2016-11-24 15:41 ` Markus Armbruster
@ 2016-11-24 16:31 ` Marcel Apfelbaum
2016-11-25 8:03 ` Markus Armbruster
0 siblings, 1 reply; 43+ messages in thread
From: Marcel Apfelbaum @ 2016-11-24 16:31 UTC (permalink / raw)
To: Markus Armbruster
Cc: Eduardo Habkost, libvir-list, qemu-devel, Laine Stump,
Michael S. Tsirkin
On 11/24/2016 05:41 PM, Markus Armbruster wrote:
> Marcel Apfelbaum <marcel@redhat.com> writes:
>
>> On 11/24/2016 03:34 PM, Markus Armbruster wrote:
>>> Eduardo Habkost <ehabkost@redhat.com> writes:
>>>
>>>> On Wed, Nov 23, 2016 at 06:43:16PM +0200, Marcel Apfelbaum wrote:
>>>>> On 11/22/2016 03:11 AM, Eduardo Habkost wrote:
>>>>>> The Problem
>>>>
>>
>> [...]
>>
>>> Our decision to have hybrid PCI/PCIe devices and buses breeds
>>> considerable complexity. I wish we had avoided them, but I believe it's
>>> too late to change now.
>>>
>>>>> This still does not solve the problem that some devices makes
>>>>> sense only on a specific arch.
>>>
>>
>> Hi Markus,
>>
>>> Examples?
>>>
>>
>> One quick example would be that we don't want to see
>> Intel's IOH 3420 PCIe Root Port in an ARM machine,
>> or a pxb on a Q35 machine (in this case we want pxb-pcie)
>
> Such a device would be weird. But would it be wrong?
Define wrong :)
Wrong enough for
> QEMU to reject it?
QEMU accepts them and they even function correctly as far as I know.
Unless QEMU rejects it, there's no reason not to
> list it as pluggable.
>
This is the gray area I can't argue. I do think that Eduardo's
work may present an opportunity to change QEMU's mantra:
"everything goes as long as it works" to "here is what this configuration supports".
Thanks,
Marcel
>> I do believe there are other examples, I'll try to think of more.
>>
>> Thanks,
>> Marcel
>>
>> [...]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] [RFC 06/15] qdev: Add device_type field to BusClass
2016-11-22 1:12 ` [Qemu-devel] [RFC 06/15] qdev: Add device_type field to BusClass Eduardo Habkost
@ 2016-11-24 16:48 ` Cornelia Huck
2016-11-24 17:37 ` Eduardo Habkost
0 siblings, 1 reply; 43+ messages in thread
From: Cornelia Huck @ 2016-11-24 16:48 UTC (permalink / raw)
To: Eduardo Habkost
Cc: qemu-devel, Markus Armbruster, Marcel Apfelbaum, Michael S. Tsirkin
On Mon, 21 Nov 2016 23:12:04 -0200
Eduardo Habkost <ehabkost@redhat.com> wrote:
<s390 glasses on>
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index 24fae16..74b8fef 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -152,6 +152,7 @@ static void pci_bus_class_init(ObjectClass *klass, void *data)
> k->realize = pci_bus_realize;
> k->unrealize = pci_bus_unrealize;
> k->reset = pcibus_reset;
> + k->device_type = TYPE_PCI_DEVICE;
This covers pci-per-se...
>
> pbc->is_root = pcibus_is_root;
> pbc->bus_num = pcibus_num;
> diff --git a/hw/s390x/css-bridge.c b/hw/s390x/css-bridge.c
> index 9a7f7ee..8a6c1ae 100644
> --- a/hw/s390x/css-bridge.c
> +++ b/hw/s390x/css-bridge.c
> @@ -17,6 +17,7 @@
> #include "hw/s390x/css.h"
> #include "ccw-device.h"
> #include "hw/s390x/css-bridge.h"
> +#include "hw/s390x/virtio-ccw.h"
>
> /*
> * Invoke device-specific unplug handler, disable the subchannel
> @@ -81,6 +82,7 @@ static void virtual_css_bus_class_init(ObjectClass *klass, void *data)
>
> k->reset = virtual_css_bus_reset;
> k->get_dev_path = virtual_css_bus_get_dev_path;
> + k->device_type = TYPE_VIRTIO_CCW_DEVICE;
...this covers virtio-ccw... (notably _not_ generic css)
> }
>
> static const TypeInfo virtual_css_bus_info = {
> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
> index 63f6248..7470fdd 100644
> --- a/hw/s390x/s390-pci-bus.c
> +++ b/hw/s390x/s390-pci-bus.c
> @@ -783,10 +783,17 @@ static const TypeInfo s390_pcihost_info = {
> }
> };
>
> +static void s390_pcibus_class_init(ObjectClass *oc, void *opaque)
> +{
> + BusClass *bc = BUS_CLASS(oc);
> + bc->device_type = TYPE_S390_PCI_DEVICE;
...this covers zpci, which is needed _in addition to_ normal pci to make pci work on s390...
> +}
> +
> static const TypeInfo s390_pcibus_info = {
> .name = TYPE_S390_PCI_BUS,
> .parent = TYPE_BUS,
> .instance_size = sizeof(S390PCIBus),
> + .class_init = s390_pcibus_class_init,
> };
>
> static uint16_t s390_pci_generate_uid(void)
> diff --git a/hw/virtio/virtio-bus.c b/hw/virtio/virtio-bus.c
> index d6c0c72..815f3dd 100644
> --- a/hw/virtio/virtio-bus.c
> +++ b/hw/virtio/virtio-bus.c
> @@ -293,6 +293,7 @@ static void virtio_bus_class_init(ObjectClass *klass, void *data)
> BusClass *bus_class = BUS_CLASS(klass);
> bus_class->get_dev_path = virtio_bus_get_dev_path;
> bus_class->get_fw_dev_path = virtio_bus_get_fw_dev_path;
> + bus_class->device_type = TYPE_VIRTIO_DEVICE;
> }
>
> static const TypeInfo virtio_bus_info = {
...and this covers virtio, which is kind of a glue bus.
So on s390, we have the following:
- to get virtio-ccw, we need virtio-ccw _and_ virtio
- to get virtio-pci, we need pci _and_ zpci _and_ virtio
- to get virtio-per-se, we need one of the combinations above
Please stop me if I'm babbling, but there seem to be some
interdependencies which are different on different architectures and
I'm not sure how these should be modelled.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] [RFC 06/15] qdev: Add device_type field to BusClass
2016-11-24 16:48 ` Cornelia Huck
@ 2016-11-24 17:37 ` Eduardo Habkost
0 siblings, 0 replies; 43+ messages in thread
From: Eduardo Habkost @ 2016-11-24 17:37 UTC (permalink / raw)
To: Cornelia Huck
Cc: qemu-devel, Markus Armbruster, Marcel Apfelbaum, Michael S. Tsirkin
On Thu, Nov 24, 2016 at 05:48:20PM +0100, Cornelia Huck wrote:
> On Mon, 21 Nov 2016 23:12:04 -0200
> Eduardo Habkost <ehabkost@redhat.com> wrote:
>
> <s390 glasses on>
>
> > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > index 24fae16..74b8fef 100644
> > --- a/hw/pci/pci.c
> > +++ b/hw/pci/pci.c
> > @@ -152,6 +152,7 @@ static void pci_bus_class_init(ObjectClass *klass, void *data)
> > k->realize = pci_bus_realize;
> > k->unrealize = pci_bus_unrealize;
> > k->reset = pcibus_reset;
> > + k->device_type = TYPE_PCI_DEVICE;
>
> This covers pci-per-se...
>
> >
> > pbc->is_root = pcibus_is_root;
> > pbc->bus_num = pcibus_num;
>
> > diff --git a/hw/s390x/css-bridge.c b/hw/s390x/css-bridge.c
> > index 9a7f7ee..8a6c1ae 100644
> > --- a/hw/s390x/css-bridge.c
> > +++ b/hw/s390x/css-bridge.c
> > @@ -17,6 +17,7 @@
> > #include "hw/s390x/css.h"
> > #include "ccw-device.h"
> > #include "hw/s390x/css-bridge.h"
> > +#include "hw/s390x/virtio-ccw.h"
> >
> > /*
> > * Invoke device-specific unplug handler, disable the subchannel
> > @@ -81,6 +82,7 @@ static void virtual_css_bus_class_init(ObjectClass *klass, void *data)
> >
> > k->reset = virtual_css_bus_reset;
> > k->get_dev_path = virtual_css_bus_get_dev_path;
> > + k->device_type = TYPE_VIRTIO_CCW_DEVICE;
>
> ...this covers virtio-ccw... (notably _not_ generic css)
>
> > }
> >
> > static const TypeInfo virtual_css_bus_info = {
>
> > diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
> > index 63f6248..7470fdd 100644
> > --- a/hw/s390x/s390-pci-bus.c
> > +++ b/hw/s390x/s390-pci-bus.c
> > @@ -783,10 +783,17 @@ static const TypeInfo s390_pcihost_info = {
> > }
> > };
> >
> > +static void s390_pcibus_class_init(ObjectClass *oc, void *opaque)
> > +{
> > + BusClass *bc = BUS_CLASS(oc);
> > + bc->device_type = TYPE_S390_PCI_DEVICE;
>
> ...this covers zpci, which is needed _in addition to_ normal pci to make pci work on s390...
>
> > +}
> > +
> > static const TypeInfo s390_pcibus_info = {
> > .name = TYPE_S390_PCI_BUS,
> > .parent = TYPE_BUS,
> > .instance_size = sizeof(S390PCIBus),
> > + .class_init = s390_pcibus_class_init,
> > };
> >
> > static uint16_t s390_pci_generate_uid(void)
>
> > diff --git a/hw/virtio/virtio-bus.c b/hw/virtio/virtio-bus.c
> > index d6c0c72..815f3dd 100644
> > --- a/hw/virtio/virtio-bus.c
> > +++ b/hw/virtio/virtio-bus.c
> > @@ -293,6 +293,7 @@ static void virtio_bus_class_init(ObjectClass *klass, void *data)
> > BusClass *bus_class = BUS_CLASS(klass);
> > bus_class->get_dev_path = virtio_bus_get_dev_path;
> > bus_class->get_fw_dev_path = virtio_bus_get_fw_dev_path;
> > + bus_class->device_type = TYPE_VIRTIO_DEVICE;
> > }
> >
> > static const TypeInfo virtio_bus_info = {
>
> ...and this covers virtio, which is kind of a glue bus.
>
> So on s390, we have the following:
>
> - to get virtio-ccw, we need virtio-ccw _and_ virtio
> - to get virtio-pci, we need pci _and_ zpci _and_ virtio
> - to get virtio-per-se, we need one of the combinations above
>
> Please stop me if I'm babbling, but there seem to be some
> interdependencies which are different on different architectures and
> I'm not sure how these should be modelled.
This series doesn't cover any of the interdependencies between
the multiple bus classes inside a machine. It just reports which
device types are available for usage with "-device" or
device_adde when running that machine-type.
If the user is not supposed to plug devices directly to some of
those buses, we can simply hide them on query-machines. (But we
should still set BusClass::device_type to allow internal
validation of the devices that are plugged on those bus objects).
--
Eduardo
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] -nodefaults and available buses (was Re: [RFC 00/15] qmp: Report supported device types on 'query-machines')
2016-11-24 16:30 ` Cornelia Huck
@ 2016-11-24 17:42 ` Eduardo Habkost
0 siblings, 0 replies; 43+ messages in thread
From: Eduardo Habkost @ 2016-11-24 17:42 UTC (permalink / raw)
To: Cornelia Huck
Cc: David Gibson, Peter Maydell, Alex Williamson, Michael Roth,
Michael S. Tsirkin, Alexey Kardashevskiy, Mark Cave-Ayland,
qemu-devel, Markus Armbruster, Beniamino Galvani, libvir-list,
Greg Kurz, qemu-arm, qemu-ppc, Laine Stump, Edgar E. Iglesias,
Marcel Apfelbaum, Paolo Bonzini, Andrea Bolognani,
Artyom Tarasenko, Jia Liu
On Thu, Nov 24, 2016 at 05:30:19PM +0100, Cornelia Huck wrote:
> On Thu, 24 Nov 2016 12:51:19 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
> > On Wed, Nov 23, 2016 at 03:10:47PM -0200, Eduardo Habkost wrote:
> > > (CCing the maintainers of the machines that crash when using
> > > -nodefaults)
> > >
> > > On Tue, Nov 22, 2016 at 08:34:50PM -0200, Eduardo Habkost wrote:
> > > [...]
> > > > "default defaults" vs "-nodefault defaults"
> > > > -------------------------------------------
> > > >
> > > > Two bad news:
> > > >
> > > > 1) We need to differentiate buses created by the machine with
> > > > "-nodefaults" and buses that are created only without
> > > > "-nodefaults".
> > > >
> > > > libvirt use -nodefaults when starting QEMU, so knowing which
> > > > buses are available when using -nodefaults is more interesting
> > > > for them.
> > > >
> > > > Other software, on the other hand, might be interested in the
> > > > results without -nodefaults.
> > > >
> > > > We need to be able model both cases in the new interface.
> > > > Suggestions are welcome.
> > >
> > > The good news is that the list is short. The only[1] machines
> > > where the list of buses seem to change when using -nodefaults
> > > are:
> > >
> > > * mpc8544ds
> > > * ppce500
> > > * mpc8544ds
> > > * ppce500
> > > * s390-ccw-virtio-*
> > >
> > > On all cases above, the only difference is that a virtio bus is
> > > available if not using -nodefaults.
> >
> > Hrm.. that's odd. Well, it makes sense for the s390 which has special
> > virtio arrangements.
>
> I don't think it makes much sense for s390 either... is this a 'virtio'
> bus or a 'virtio-{pci,ccw}' bus? The transport bus should be present
> with -nodefaults; the virtio bus is basically a glue bus for virtio
> devices...
I mean no device of type "virtio-ccw-bus" (which is a subtype of
"virtio-bus") is present on the device tree.
Is the TYPE_VIRTIO_BUS bus supposed to be user-visible, or is it
just internal?
--
Eduardo
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines'
2016-11-24 16:31 ` Marcel Apfelbaum
@ 2016-11-25 8:03 ` Markus Armbruster
0 siblings, 0 replies; 43+ messages in thread
From: Markus Armbruster @ 2016-11-25 8:03 UTC (permalink / raw)
To: Marcel Apfelbaum
Cc: libvir-list, Michael S. Tsirkin, Eduardo Habkost, Laine Stump,
qemu-devel
Marcel Apfelbaum <marcel@redhat.com> writes:
> On 11/24/2016 05:41 PM, Markus Armbruster wrote:
>> Marcel Apfelbaum <marcel@redhat.com> writes:
>>
>>> On 11/24/2016 03:34 PM, Markus Armbruster wrote:
>>>> Eduardo Habkost <ehabkost@redhat.com> writes:
>>>>
>>>>> On Wed, Nov 23, 2016 at 06:43:16PM +0200, Marcel Apfelbaum wrote:
>>>>>> On 11/22/2016 03:11 AM, Eduardo Habkost wrote:
>>>>>>> The Problem
>>>>>
>>>
>>> [...]
>>>
>>>> Our decision to have hybrid PCI/PCIe devices and buses breeds
>>>> considerable complexity. I wish we had avoided them, but I believe it's
>>>> too late to change now.
>>>>
>>>>>> This still does not solve the problem that some devices makes
>>>>>> sense only on a specific arch.
>>>>
>>>
>>> Hi Markus,
>>>
>>>> Examples?
>>>>
>>>
>>> One quick example would be that we don't want to see
>>> Intel's IOH 3420 PCIe Root Port in an ARM machine,
>>> or a pxb on a Q35 machine (in this case we want pxb-pcie)
>>
>> Such a device would be weird. But would it be wrong?
>
> Define wrong :)
I do:
> Wrong enough for
>> QEMU to reject it?
>
> QEMU accepts them and they even function correctly as far as I know.
>
>> Unless QEMU rejects it, there's no reason not to
>> list it as pluggable.
>>
>
> This is the gray area I can't argue. I do think that Eduardo's
> work may present an opportunity to change QEMU's mantra:
> "everything goes as long as it works" to "here is what this configuration supports".
I guess you argument is that in reality, the devices you quoted are
always part of specific chipsets, so "we dont want to see" them
elsewhere.
If I understand you correctly, there are two cases you don't want to see
elsewhere:
(1) The real PCI device only ever exists as function of another device.
(2) The real PCI device only ever exists on certain boards.
We accept these devices elsewhere due to the way we model them.
Because we conflate PCI functions and devices, we can't model (1)
correctly. I think the appropriate solution would be modelling
functions separate from devices, then provide the functions in question
only as part of the devices where you want to see them, by making them
not user-pluggable.
Because we model a board's chipset as a set of independent devices
instead of a composite device, we can't model (2) correctly. I think
the appropriate solution to (2) is modelling composite chipset devices,
then provide the devices in question only as part of the chipset devices
where you want to see them, by making them not user-pluggable.
Adding a bunch of special types to QOM so that introspection claims "you
can't plug that thing" (even though you actually could) would be an
inappropriate solution. As long as you can plug them, QEMU should be
honest about it, even if we think you shouldn't plug them. "Can't" is
mechanism. "Shouldn't" is policy. Baking policy into introspection by
making it lie doesn't strike me as a good idea.
[...]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] [RFC 11/15] s390x: Initialize default bus lists
2016-11-22 1:12 ` [Qemu-devel] [RFC 11/15] s390x: " Eduardo Habkost
@ 2016-12-05 15:24 ` David Hildenbrand
2016-12-05 16:03 ` Cornelia Huck
0 siblings, 1 reply; 43+ messages in thread
From: David Hildenbrand @ 2016-12-05 15:24 UTC (permalink / raw)
To: Eduardo Habkost, qemu-devel, Markus Armbruster, Marcel Apfelbaum,
Michael S. Tsirkin
Am 22.11.2016 um 02:12 schrieb Eduardo Habkost:
> Populate the default_bus_types list for the s390x machines. This
> will allow qmp-machine-info.py to run in strict mode for s390x.
>
> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> ---
> hw/s390x/s390-virtio-ccw.c | 6 ++++++
> tests/qmp-machine-info.py | 2 +-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> index e340eab..2532fcb 100644
> --- a/hw/s390x/s390-virtio-ccw.c
> +++ b/hw/s390x/s390-virtio-ccw.c
> @@ -206,6 +206,12 @@ static void ccw_machine_class_init(ObjectClass *oc, void *data)
> mc->use_sclp = 1;
> mc->max_cpus = 248;
> mc->get_hotplug_handler = s390_get_hotplug_handler;
> + machine_class_add_default_bus(mc, TYPE_VIRTUAL_CSS_BUS);
> + machine_class_add_default_bus(mc, TYPE_PCI_BUS);
> + machine_class_add_default_bus(mc, TYPE_S390_PCI_BUS);
> + machine_class_add_default_bus(mc, "s390-sclp-events-bus");
> + machine_class_add_default_bus(mc, TYPE_VIRTIO_BUS);
> +
Maybe move and use
#define TYPE_SCLP_EVENTS_BUS "s390-sclp-events-bus"
(maybe this should then become TYPE_S390_SCLP_EVENTS_BUS ...)
?
--
David
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] [RFC 11/15] s390x: Initialize default bus lists
2016-12-05 15:24 ` David Hildenbrand
@ 2016-12-05 16:03 ` Cornelia Huck
2016-12-05 16:38 ` Eduardo Habkost
0 siblings, 1 reply; 43+ messages in thread
From: Cornelia Huck @ 2016-12-05 16:03 UTC (permalink / raw)
To: David Hildenbrand
Cc: Eduardo Habkost, qemu-devel, Markus Armbruster, Marcel Apfelbaum,
Michael S. Tsirkin
On Mon, 5 Dec 2016 16:24:00 +0100
David Hildenbrand <david@redhat.com> wrote:
> Am 22.11.2016 um 02:12 schrieb Eduardo Habkost:
> > Populate the default_bus_types list for the s390x machines. This
> > will allow qmp-machine-info.py to run in strict mode for s390x.
> >
> > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> > ---
> > hw/s390x/s390-virtio-ccw.c | 6 ++++++
> > tests/qmp-machine-info.py | 2 +-
> > 2 files changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> > index e340eab..2532fcb 100644
> > --- a/hw/s390x/s390-virtio-ccw.c
> > +++ b/hw/s390x/s390-virtio-ccw.c
> > @@ -206,6 +206,12 @@ static void ccw_machine_class_init(ObjectClass *oc, void *data)
> > mc->use_sclp = 1;
> > mc->max_cpus = 248;
> > mc->get_hotplug_handler = s390_get_hotplug_handler;
> > + machine_class_add_default_bus(mc, TYPE_VIRTUAL_CSS_BUS);
> > + machine_class_add_default_bus(mc, TYPE_PCI_BUS);
> > + machine_class_add_default_bus(mc, TYPE_S390_PCI_BUS);
> > + machine_class_add_default_bus(mc, "s390-sclp-events-bus");
> > + machine_class_add_default_bus(mc, TYPE_VIRTIO_BUS);
> > +
>
> Maybe move and use
> #define TYPE_SCLP_EVENTS_BUS "s390-sclp-events-bus"
>
> (maybe this should then become TYPE_S390_SCLP_EVENTS_BUS ...)
>
> ?
>
I'd ack/take such a patch.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Qemu-devel] [RFC 11/15] s390x: Initialize default bus lists
2016-12-05 16:03 ` Cornelia Huck
@ 2016-12-05 16:38 ` Eduardo Habkost
0 siblings, 0 replies; 43+ messages in thread
From: Eduardo Habkost @ 2016-12-05 16:38 UTC (permalink / raw)
To: Cornelia Huck
Cc: David Hildenbrand, qemu-devel, Markus Armbruster,
Marcel Apfelbaum, Michael S. Tsirkin
On Mon, Dec 05, 2016 at 05:03:27PM +0100, Cornelia Huck wrote:
> On Mon, 5 Dec 2016 16:24:00 +0100
> David Hildenbrand <david@redhat.com> wrote:
>
> > Am 22.11.2016 um 02:12 schrieb Eduardo Habkost:
> > > Populate the default_bus_types list for the s390x machines. This
> > > will allow qmp-machine-info.py to run in strict mode for s390x.
> > >
> > > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> > > ---
> > > hw/s390x/s390-virtio-ccw.c | 6 ++++++
> > > tests/qmp-machine-info.py | 2 +-
> > > 2 files changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> > > index e340eab..2532fcb 100644
> > > --- a/hw/s390x/s390-virtio-ccw.c
> > > +++ b/hw/s390x/s390-virtio-ccw.c
> > > @@ -206,6 +206,12 @@ static void ccw_machine_class_init(ObjectClass *oc, void *data)
> > > mc->use_sclp = 1;
> > > mc->max_cpus = 248;
> > > mc->get_hotplug_handler = s390_get_hotplug_handler;
> > > + machine_class_add_default_bus(mc, TYPE_VIRTUAL_CSS_BUS);
> > > + machine_class_add_default_bus(mc, TYPE_PCI_BUS);
> > > + machine_class_add_default_bus(mc, TYPE_S390_PCI_BUS);
> > > + machine_class_add_default_bus(mc, "s390-sclp-events-bus");
> > > + machine_class_add_default_bus(mc, TYPE_VIRTIO_BUS);
> > > +
> >
> > Maybe move and use
> > #define TYPE_SCLP_EVENTS_BUS "s390-sclp-events-bus"
> >
> > (maybe this should then become TYPE_S390_SCLP_EVENTS_BUS ...)
> >
> > ?
> >
>
> I'd ack/take such a patch.
Agreed. I will address that in final version. This version was
supposed to include a "//FIXME: use macro here" comment.
--
Eduardo
^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2016-12-05 16:38 UTC | newest]
Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-11-22 1:11 [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Eduardo Habkost
2016-11-22 1:11 ` [Qemu-devel] [RFC 01/15] qemu.py: Make logging optional Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 02/15] qtest.py: Support QTEST_LOG environment variable Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 03/15] qtest.py: make logging optional Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 04/15] qtest.py: Make 'binary' parameter optional Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 05/15] tests: Add rules to non-gtester qtest test cases Eduardo Habkost
2016-11-22 13:34 ` Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 06/15] qdev: Add device_type field to BusClass Eduardo Habkost
2016-11-24 16:48 ` Cornelia Huck
2016-11-24 17:37 ` Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 07/15] machine: Add MachineClass::default_buses field Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 08/15] qmp: Add 'supported-device-types' field to 'query-machines' Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 09/15] pci: Introduce INTERFACE_PCIE_DEVICE interface name Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 10/15] pc: Initialize default bus lists Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 11/15] s390x: " Eduardo Habkost
2016-12-05 15:24 ` David Hildenbrand
2016-12-05 16:03 ` Cornelia Huck
2016-12-05 16:38 ` Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 12/15] arm: " Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 13/15] mips: " Eduardo Habkost
2016-11-22 1:12 ` [Qemu-devel] [RFC 14/15] ppc: " Eduardo Habkost
2016-11-23 3:42 ` Alexey Kardashevskiy
2016-11-22 1:12 ` [Qemu-devel] [RFC 15/15] qdev: Add device_class_set_bus_type() function Eduardo Habkost
2016-11-22 1:34 ` [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' no-reply
2016-11-22 1:36 ` no-reply
2016-11-22 8:18 ` David Hildenbrand
2016-11-22 13:09 ` Eduardo Habkost
2016-11-22 22:34 ` Eduardo Habkost
2016-11-23 17:10 ` [Qemu-devel] -nodefaults and available buses (was Re: [RFC 00/15] qmp: Report supported device types on 'query-machines') Eduardo Habkost
2016-11-24 1:51 ` David Gibson
2016-11-24 16:30 ` Cornelia Huck
2016-11-24 17:42 ` Eduardo Habkost
2016-11-24 13:39 ` Markus Armbruster
2016-11-23 16:43 ` [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Marcel Apfelbaum
2016-11-23 17:35 ` Eduardo Habkost
2016-11-24 9:34 ` Marcel Apfelbaum
2016-11-24 13:34 ` Markus Armbruster
2016-11-24 14:12 ` Eduardo Habkost
2016-11-24 14:55 ` Markus Armbruster
2016-11-24 14:22 ` Marcel Apfelbaum
2016-11-24 15:41 ` Markus Armbruster
2016-11-24 16:31 ` Marcel Apfelbaum
2016-11-25 8:03 ` Markus Armbruster
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.