From: Markus Armbruster arm...@redhat.com
Messed up in commit 8281abd.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
vl.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/vl.c b/vl.c
index 983cdc6..7e1f408 100644
--- a/vl.c
+++ b/vl.c
@@ -2825,7 +2825,7 @@ int
From: Markus Armbruster arm...@redhat.com
Marcel's recent improvements (commit dbd94f8..125ee0e) go in the right
direction, but there are issues (see PATCH 1/2), and I find the
resulting help output still hard to read.
This series redoes the help printing part of Marcel's series. Result
looks
From: Markus Armbruster arm...@redhat.com
This reverts most of commit 3d1237fb2ab4edb926c717767bb5e31d6053a7c5.
The commit claims to sort the output of -device help by
functionality rather than alphabetical. Issues:
* The output was unsorted before, not alphabetically sorted.
Misleading, but
From: Markus Armbruster arm...@redhat.com
Output is a long, unsorted list. Not very helpful. Print one list
per device category instead, with a header line identifying the
category, plus a list of uncategorized devices. Print each list in
case-insenitive alphabetical order.
Devices with
From: Markus Armbruster arm...@redhat.com
device_add plugs devices into suitable bus. For real buses, that
actually connects the device. For sysbus, the connections need to be
made separately, and device_add can't do that. The device would be
left unconncected, and could not possibly work.
From: Markus Armbruster arm...@redhat.com
Many PCI host bridges consist of a sysbus device and a PCI device.
You need both for the thing to work. Arguably, these bridges should
be modelled as a single, composite devices instead of pairs of
seemingly independent devices you can only use together,
From: Markus Armbruster arm...@redhat.com
Note: this series is on top of my Improve -device command line help
some more series. You can also get it from branch no-user at
git://repo.or.cz/qemu/armbru.git
In an ideal world, machines can be built by wiring devices together
with configuration, not
From: Markus Armbruster arm...@redhat.com
Such devices have always been unavailable and omitted from the list of
available devices shown by device_add help. Until commit 18b6dad
silently broke the former, setting up nasty traps for unwary users,
like this one:
$ qemu-system-x86_64
From: Markus Armbruster arm...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
---
hw/intc/apic_common.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c
index ea420c7..aaef054 100644
--- a/hw/intc/apic_common.c
From: Markus Armbruster arm...@redhat.com
A PIIX3/PIIX4 southbridge has multiple functions. We model each
function as a separate qdev. Two of them need some special wiring set
up in pc_init1() or mips_malta_init() to work: the ISA bridge at 01.0,
and the SMBus controller at 01.3.
Additionally,
From: Markus Armbruster arm...@redhat.com
Drop it when there's no obvious reason why device_add could not work.
Else keep and document why.
* isa-fdc, port92, i8042, m48t59_isa, mc146818rtc, isa-pit, kvm-pit:
drop (the last two by dropping it from their abstract base
pit-common)
* pcspk:
From: Markus Armbruster arm...@redhat.com
DeviceClass member no_user used to make device models unavailable with
-device / device_add, but that regressed in commit 18b6dad. All
that's left is the device model is still omitted from help.
Attempts to fix the regression have been rejected with the
From: Markus Armbruster arm...@redhat.com
An ICH9 southbridge contains several PCI devices, some of them with
multiple functions. We model each function as a separate qdev. Two
of them need some special wiring set up in pc_q35_init() to work: the
LPC controller at 00:1f.0, and the SMBus
From: Markus Armbruster arm...@redhat.com
A VT82C686B southbridge has multiple functions. We model each
function as a separate qdev. One of them need some special wiring set
up in mips_fulong2e_init() to work: the ISA bridge at 05.0.
Additionally, the IDE controller at 05.1 has always had
From: Markus Armbruster arm...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
---
hw/intc/apic_common.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c
index ea420c7..aaef054 100644
--- a/hw/intc/apic_common.c
From: Markus Armbruster arm...@redhat.com
In an ideal world, machines can be built by wiring devices together
with configuration, not code. Unfortunately, that's not the world we
live in right now. We still have quite a few devices that need to be
wired up by code. If you try to device_add
From: Markus Armbruster arm...@redhat.com
A VT82C686B southbridge has multiple functions. We model each
function as a separate qdev. One of them need some special wiring set
up in mips_fulong2e_init() to work: the ISA bridge at 05.0.
The IDE controller at 05.1 (via-ide) has always had
From: Markus Armbruster arm...@redhat.com
device_add plugs devices into suitable bus. For real buses, that
actually connects the device. For sysbus, the connections need to be
made separately, and device_add can't do that. The device would be
left unconncected, and could not possibly work.
From: Markus Armbruster arm...@redhat.com
Drop it when there's no obvious reason why device_add could not work.
Else keep and document why.
* isa-fdc, port92, i8042, m48t59_isa, mc146818rtc, isa-pit, kvm-pit:
drop (from the last two by dropping it from their abstract base
pit-common)
*
From: Markus Armbruster arm...@redhat.com
In an ideal world, machines can be built by wiring devices together
with configuration, not code. Unfortunately, that's not the world we
live in right now. We still have quite a few devices that need to be
wired up by code. If you try to device_add
From: Markus Armbruster arm...@redhat.com
Such devices have always been unavailable and omitted from the list of
available devices shown by device_add help. Until commit 18b6dad
silently broke the former, setting up nasty traps for unwary users,
like this one:
$ qemu-system-x86_64
From: Markus Armbruster arm...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
---
qom/cpu.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/qom/cpu.c b/qom/cpu.c
index 09c15e6..6e0d54e 100644
--- a/qom/cpu.c
+++ b/qom/cpu.c
@@ -254,7 +254,11 @@ static
From: Markus Armbruster arm...@redhat.com
An ICH9 southbridge contains several PCI devices, some of them with
multiple functions. We model each function as a separate qdev. Two
of them need some special wiring set up in pc_q35_init() to work: the
LPC controller at 00:1f.0, and the SMBus
From: Markus Armbruster arm...@redhat.com
A PIIX3/PIIX4 southbridge has multiple functions. We model each
function as a separate qdev. Two of them need some special wiring set
up in pc_init1() or mips_malta_init() to work: the ISA bridge at 01.0,
and the SMBus controller at 01.3.
The IDE
From: Markus Armbruster arm...@redhat.com
Many PCI host bridges consist of a sysbus device and a PCI device.
You need both for the thing to work. Arguably, these bridges should
be modelled as a single, composite devices instead of pairs of
seemingly independent devices you can only use together,
From: Markus Armbruster arm...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
Reviewed-by: Peter Maydell peter.mayd...@linaro.org
---
hw/intc/apic_common.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c
index
From: Markus Armbruster arm...@redhat.com
In an ideal world, machines can be built by wiring devices together
with configuration, not code. Unfortunately, that's not the world we
live in right now. We still have quite a few devices that need to be
wired up by code. If you try to device_add
From: Markus Armbruster arm...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
Reviewed-by: Peter Maydell peter.mayd...@linaro.org
---
qom/cpu.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/qom/cpu.c b/qom/cpu.c
index 09c15e6..6e0d54e 100644
---
From: Markus Armbruster arm...@redhat.com
A VT82C686B southbridge has multiple functions. We model each
function as a separate qdev. One of them need some special wiring set
up in mips_fulong2e_init() to work: the ISA bridge at 05.0.
The IDE controller at 05.1 (via-ide) has always had
From: Markus Armbruster arm...@redhat.com
Such devices have always been unavailable and omitted from the list of
available devices shown by device_add help. Until commit 18b6dad
silently broke the former, setting up nasty traps for unwary users,
like this one:
$ qemu-system-x86_64
From: Markus Armbruster arm...@redhat.com
An ICH9 southbridge contains several PCI devices, some of them with
multiple functions. We model each function as a separate qdev. Two
of them need some special wiring set up in pc_q35_init() to work: the
LPC controller at 00:1f.0, and the SMBus
From: Markus Armbruster arm...@redhat.com
Many PCI host bridges consist of a sysbus device and a PCI device.
You need both for the thing to work. Arguably, these bridges should
be modelled as a single, composite devices instead of pairs of
seemingly independent devices you can only use together,
From: Markus Armbruster arm...@redhat.com
A PIIX3/PIIX4 southbridge has multiple functions. We model each
function as a separate qdev. Two of them need some special wiring set
up in pc_init1() or mips_malta_init() to work: the ISA bridge at 01.0,
and the SMBus controller at 01.3.
The IDE
From: Markus Armbruster arm...@redhat.com
Drop it when there's no obvious reason why device_add could not work.
Else keep and document why.
* isa-fdc: drop
* i8042: drop, even though its I/O base is hardcoded (because you
could conceivably still add one to a board that has none), and even
From: Markus Armbruster arm...@redhat.com
In an ideal world, machines can be built by wiring devices together
with configuration, not code. Unfortunately, that's not the world we
live in right now. We still have quite a few devices that need to be
wired up by code. If you try to device_add
From: Markus Armbruster arm...@redhat.com
device_add plugs devices into suitable bus. For real buses, that
actually connects the device. For sysbus, the connections need to be
made separately, and device_add can't do that. The device would be
left unconnected, and could not possibly work.
From: Markus Armbruster arm...@redhat.com
Put it in QEMUMachineInitArgs, so I don't have to touch every board.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
include/hw/boards.h | 7 +--
vl.c| 3 ++-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git
From: Markus Armbruster arm...@redhat.com
Currently, we get SeaBIOS defaults: manufacturer Bochs, product Bochs,
no version. Best SeaBIOS can do, but we can provide better defaults:
manufacturer QEMU, product version taken from QEMUMachine desc and
name.
Take care to do this only for new
From: Markus Armbruster arm...@redhat.com
Currently, we get SeaBIOS defaults: manufacturer Bochs, product Bochs,
no version. Best SeaBIOS can do, but we can provide better defaults:
manufacturer QEMU, product version taken from QEMUMachine desc and
name.
This series used to be called [PATCH v2
From: Markus Armbruster arm...@redhat.com
In an ideal world, machines can be built by wiring devices together
with configuration, not code. Unfortunately, that's not the world we
live in right now. We still have quite a few devices that need to be
wired up by code. If you try to device_add
From: Markus Armbruster arm...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
Reviewed-by: Peter Maydell peter.mayd...@linaro.org
---
qom/cpu.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/qom/cpu.c b/qom/cpu.c
index 09c15e6..6e0d54e 100644
---
From: Markus Armbruster arm...@redhat.com
device_add plugs devices into suitable bus. For real buses, that
actually connects the device. For sysbus, the connections need to be
made separately, and device_add can't do that. The device would be
left unconnected, and could not possibly work.
From: Markus Armbruster arm...@redhat.com
In an ideal world, machines can be built by wiring devices together
with configuration, not code. Unfortunately, that's not the world we
live in right now. We still have quite a few devices that need to be
wired up by code. If you try to device_add
From: Markus Armbruster arm...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
Reviewed-by: Peter Maydell peter.mayd...@linaro.org
---
hw/intc/apic_common.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c
index
From: Markus Armbruster arm...@redhat.com
Many PCI host bridges consist of a sysbus device and a PCI device.
You need both for the thing to work. Arguably, these bridges should
be modelled as a single, composite devices instead of pairs of
seemingly independent devices you can only use together,
From: Markus Armbruster arm...@redhat.com
An ICH9 southbridge contains several PCI devices, some of them with
multiple functions. We model each function as a separate qdev. Two
of them need some special wiring set up in pc_q35_init() to work: the
LPC controller at 00:1f.0, and the SMBus
From: Markus Armbruster arm...@redhat.com
Such devices have always been unavailable and omitted from the list of
available devices shown by device_add help. Until commit 18b6dad
silently broke the former, setting up nasty traps for unwary users,
like this one:
$ qemu-system-x86_64
From: Markus Armbruster arm...@redhat.com
A VT82C686B southbridge has multiple functions. We model each
function as a separate qdev. One of them need some special wiring set
up in mips_fulong2e_init() to work: the ISA bridge at 05.0.
The IDE controller at 05.1 (via-ide) has always had
From: Markus Armbruster arm...@redhat.com
A PIIX3/PIIX4 southbridge has multiple functions. We model each
function as a separate qdev. Two of them need some special wiring set
up in pc_init1() or mips_malta_init() to work: the ISA bridge at 01.0,
and the SMBus controller at 01.3.
The IDE
From: Markus Armbruster arm...@redhat.com
Drop it when there's no obvious reason why device_add could not work.
Else keep and document why.
* isa-fdc: drop
* i8042: drop, even though its I/O base is hardcoded (because you
could conceivably still add one to a board that has none), and even
From: Markus Armbruster arm...@redhat.com
Event qxl_render_blit_guest_primary_initialized is unused since commit
c58c7b9, drop it.
Commit 42e5b4c moved hw/ppc/xics.c to hw/intc/xics.c without updating
the comment in trace-events.
scripts/cleanup-trace-events.pl trace-events | diff trace-events
From: Markus Armbruster arm...@redhat.com
Hasn't gotten maintainer attention for two months. Retrying via
qemu-trivial.
v3: Trivially rebased
v2: Nominate for qemu-stable (Andreas)
Markus Armbruster (2):
tests: Fix schema parser test for in-tree build
tests: Update .gitignore for
From: Markus Armbruster arm...@redhat.com
Forgotten in commit 6046c62 and 3464700.
Cc: qemu-sta...@nongnu.org
Reviewed-by: Andreas Färber afaer...@suse.de
Reviewed-by: Laszlo Ersek ler...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
---
tests/.gitignore | 2 ++
1 file changed,
From: Markus Armbruster arm...@redhat.com
Commit 4f193e3 added the test, but screwed up in-tree builds
(SRCDIR=.): the tests's output overwrites the expected output, and is
thus compared to itself.
Cc: qemu-sta...@nongnu.org
Reported-by: Laszlo Ersek ler...@redhat.com
Reviewed-by: Andreas Färber
From: Markus Armbruster arm...@redhat.com
Obvious cleanups possible since we no longer have the special case of
a non-qdevified controller.
v2:
* Dropped PATCH 1/10 ide: Break all non-qdevified controllers
Andreas qdevified them since; thanks!
* Series renamed from Drop code for non-qdevified
From: Markus Armbruster arm...@redhat.com
All uses are simple array subscripts.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
hw/ide/core.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index 0022cc5..2ed7cb8 100644
---
From: Markus Armbruster arm...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
---
hw/ide/core.c | 2 +-
hw/ide/internal.h | 3 +--
hw/ide/qdev.c | 12 +++-
3 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index
From: Markus Armbruster arm...@redhat.com
It's a copy of dev-serial. The copy was needed for non-qdevified
controllers, which lacked dev.
Note that pci_piix3_xen_ide_unplug() did not clear the copy (it only
cleared the copy of bs). Begs the question whether stale data could
have been used
From: Markus Armbruster arm...@redhat.com
It's a copy of dev-conf.bs. The copy was needed for non-qdevified
controllers, which lacked dev.
Note how pci_piix3_xen_ide_unplug() cleared the copy. We'll get back
to that in the next few commits.
Signed-off-by: Markus Armbruster arm...@redhat.com
From: Markus Armbruster arm...@redhat.com
Members cylinders, heads, sectors, chs_trans are copies of
dev-conf.cyls, dev-conf.heads, dev-conf.secs, dev-chs_trans.
Copies were needed for non-qdevified controllers, which lacked dev.
Note that pci_piix3_xen_ide_unplug() did not clear the copies (it
From: Markus Armbruster arm...@redhat.com
It's a copy of dev-version. The copy was needed for non-qdevified
controllers, which lacked dev.
Note that pci_piix3_xen_ide_unplug() did not clear the copy (it only
cleared the copy of bs). Begs the question whether stale data could
have been used
From: Markus Armbruster arm...@redhat.com
Testing dev is more obvious than testing bs, in my opinion.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
hw/ide/ahci.c | 8
hw/ide/core.c | 56 -
hw/ide/microdrive.c |
From: Markus Armbruster arm...@redhat.com
It's a copy of dev-wwn. The copy was needed for non-qdevified
controllers, which lacked dev.
Note that pci_piix3_xen_ide_unplug() did not clear the copy (it only
cleared the copy of bs). Begs the question whether stale data could
have been used after
From: Markus Armbruster arm...@redhat.com
It's a copy of dev-serial. The copy was needed for non-qdevified
controllers, which lacked dev.
Note that pci_piix3_xen_ide_unplug() did not clear the copy (it only
cleared the copy of bs). Begs the question whether stale data could
have been used
From: Markus Armbruster arm...@redhat.com
Commit b5613fd neglected to drop the trace events along with the code.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
trace-events | 13 -
1 file changed, 13 deletions(-)
diff --git a/trace-events b/trace-events
index
From: Markus Armbruster arm...@redhat.com
Watch this:
$ upstream-qemu -nodefaults -S -display none -monitor stdio
QEMU 1.7.50 monitor - type 'help' for more information
(qemu) device_add rng-egd
/work/armbru/qemu/qdev-monitor.c:491:qdev_device_add: Object 0x2089b00
From: Markus Armbruster arm...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
Reviewed-by: Peter Maydell peter.mayd...@linaro.org
---
hw/intc/apic_common.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c
index
From: Markus Armbruster arm...@redhat.com
In an ideal world, machines can be built by wiring devices together
with configuration, not code. Unfortunately, that's not the world we
live in right now. We still have quite a few devices that need to be
wired up by code. If you try to device_add
From: Markus Armbruster arm...@redhat.com
An ICH9 southbridge contains several PCI devices, some of them with
multiple functions. We model each function as a separate qdev. Two
of them need some special wiring set up in pc_q35_init() to work: the
LPC controller at 00:1f.0, and the SMBus
From: Markus Armbruster arm...@redhat.com
A VT82C686B southbridge has multiple functions. We model each
function as a separate qdev. One of them need some special wiring set
up in mips_fulong2e_init() to work: the ISA bridge at 05.0.
The IDE controller at 05.1 (via-ide) has always had
From: Markus Armbruster arm...@redhat.com
Drop it when there's no obvious reason why device_add could not work.
Else keep and document why.
* isa-fdc: drop
* i8042: drop, even though its I/O base is hardcoded (because you
could conceivably still add one to a board that has none), and even
From: Markus Armbruster arm...@redhat.com
device_add plugs devices into suitable bus. For real buses, that
actually connects the device. For sysbus, the connections need to be
made separately, and device_add can't do that. The device would be
left unconnected, and could not possibly work.
From: Markus Armbruster arm...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
Reviewed-by: Peter Maydell peter.mayd...@linaro.org
---
qom/cpu.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/qom/cpu.c b/qom/cpu.c
index 09c15e6..6e0d54e 100644
---
From: Markus Armbruster arm...@redhat.com
Such devices have always been unavailable and omitted from the list of
available devices shown by device_add help. Until commit 18b6dad
silently broke the former, setting up nasty traps for unwary users,
like this one:
$ qemu-system-x86_64
From: Markus Armbruster arm...@redhat.com
Many PCI host bridges consist of a sysbus device and a PCI device.
You need both for the thing to work. Arguably, these bridges should
be modelled as a single, composite devices instead of pairs of
seemingly independent devices you can only use together,
From: Markus Armbruster arm...@redhat.com
In an ideal world, machines can be built by wiring devices together
with configuration, not code. Unfortunately, that's not the world we
live in right now. We still have quite a few devices that need to be
wired up by code. If you try to device_add
From: Markus Armbruster arm...@redhat.com
A PIIX3/PIIX4 southbridge has multiple functions. We model each
function as a separate qdev. Two of them need some special wiring set
up in pc_init1() or mips_malta_init() to work: the ISA bridge at 01.0,
and the SMBus controller at 01.3.
The IDE
From: Markus Armbruster arm...@redhat.com
Pointer properties can be set only by code, not by device_add. A
device with a pointer property can't work with device_add only unless
the property may remain null. cannot_instantiate_with_device_add_yet
needs to be set then. PATCH 1/2 sets it when
From: Markus Armbruster arm...@redhat.com
Ask users of DEFINE_PROP_PTR() to set
cannot_instantiate_with_device_add_yet, or explain why it's not
needed.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
include/hw/qdev-properties.h | 17 +
1 file changed, 17 insertions(+)
From: Markus Armbruster arm...@redhat.com
Pointer properties can be set only by code, not by device_add. A
device with a pointer property can work with device_add only when the
property may remain null.
This is the case for property interrupt_vector of device
etraxfs,pic. Add a comment there.
From: Markus Armbruster arm...@redhat.com
The first five patches are admittedly related to the stated purpose of
this series pretty much only by I can't stand perpetuating this
stupid crap. Max Filippov and Peter Maydell already cleaned up
Xtensa and ARM the same way.
v4:
* Rebase
v3:
* Rebase
From: Markus Armbruster arm...@redhat.com
Don't explode when the variable is used just once, and never changed.
Signed-off-by: Markus Armbruster arm...@redhat.com
Acked-by: Alexander Graf ag...@suse.de
---
hw/ppc/e500plat.c | 18 ++
hw/ppc/mpc8544ds.c | 18 ++
2
From: Markus Armbruster arm...@redhat.com
Don't explode when the variable is used just a few times, and never
changed.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
hw/i386/pc_q35.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git
From: Markus Armbruster arm...@redhat.com
Don't explode QEMUMachineInitArgs before passing it to pc_init1().
Signed-off-by: Markus Armbruster arm...@redhat.com
---
hw/i386/pc_piix.c | 65 ++-
1 file changed, 16 insertions(+), 49 deletions(-)
From: Markus Armbruster arm...@redhat.com
Don't explode QEMUMachineInitArgs before passing it to
sun4m_hw_init(), sun4uv_init().
Signed-off-by: Markus Armbruster arm...@redhat.com
---
hw/sparc/sun4m.c | 113 -
hw/sparc64/sun4u.c | 52
From: Markus Armbruster arm...@redhat.com
Pass on the generic arguments unadulterated, and the machine-specific
ones as separate argument.
Signed-off-by: Markus Armbruster arm...@redhat.com
Acked-by: Alexander Graf ag...@suse.de
---
hw/ppc/e500.c | 35 ++-
From: Markus Armbruster arm...@redhat.com
We set default boot order cad in every single machine definition
except pseries and moxiesim, even though very few boards actually
care for boot order, and cad makes sense for even fewer.
Machines that care:
* pc and its variants
Accept up to three
From: Markus Armbruster arm...@redhat.com
We allow either tables or fields for the same type. Makes sense,
because SeaBIOS uses fields only when no tables are present.
We do this by searching the SMBIOS blob for a previously added table
or field. Error messages look like this:
From: Markus Armbruster arm...@redhat.com
So that it can be set in config file for -readconfig.
This tightens parsing of -smbios, and makes it more consistent with
other options: unknown parameters are rejected, numbers with trailing
junk are rejected, when a parameter is given multiple times,
From: Markus Armbruster arm...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
---
hw/i386/smbios.c | 61 +++-
1 file changed, 25 insertions(+), 36 deletions(-)
diff --git
From: Markus Armbruster arm...@redhat.com
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add
From: Markus Armbruster arm...@redhat.com
I'd like to access QEMUMachine from a QEMUMachine init() method, which
is currently not possible. Instead of passing it as an argument, I
simply set current_machine earlier.
Signed-off-by: Markus Armbruster arm...@redhat.com
Reviewed-by: Eric Blake
From: Markus Armbruster arm...@redhat.com
It exits on all error conditions but one, where it returns -1.
Normalize, and return void.
Signed-off-by: Markus Armbruster arm...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
---
arch_init.c | 4 +---
hw/i386/smbios.c | 10
From: Markus Armbruster arm...@redhat.com
This gets rid of one of the last get_param_value() users, makes
multiple -smbios work sanely, cleans up the gross side effect in
qemu_uuid_parse(), and more. Topped off with a little feature in the
last patch.
v2: Rebase, only last patch had conflicts
From: Markus Armbruster arm...@redhat.com
Currently, we get SeaBIOS defaults: manufacturer Bochs, product Bochs,
no version. Best SeaBIOS can do, but we can provide better defaults:
manufacturer QEMU, product version taken from QEMUMachine desc and
name.
Take care to do this only for new
From: Markus Armbruster arm...@redhat.com
It's the abstract base of virtio-scsi-device and vhost-scsi.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
hw/scsi/virtio-scsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
index
From: Markus Armbruster arm...@redhat.com
Commit 4f193e3 added the test, but screwed up in-tree builds
(SRCDIR=.): the tests's output overwrites the expected output, and is
thus compared to itself.
Reported-by: Laszlo Ersek ler...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
---
From: Markus Armbruster arm...@redhat.com
Markus Armbruster (2):
tests: Fix schema parser test for in-tree build
tests: Update .gitignore for test-int128 and test-bitops
tests/.gitignore | 3 +++
tests/Makefile | 8
2 files changed, 7 insertions(+), 4 deletions(-)
--
1.8.1.4
From: Markus Armbruster arm...@redhat.com
Forgotten in commit 6046c62 and 3464700.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
tests/.gitignore | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/.gitignore b/tests/.gitignore
index d9c2ef4..9ac044d 100644
---
From: Markus Armbruster arm...@redhat.com
Commit 4f193e3 added the test, but screwed up in-tree builds
(SRCDIR=.): the tests's output overwrites the expected output, and is
thus compared to itself.
Cc: qemu-sta...@nongnu.org
Reported-by: Laszlo Ersek ler...@redhat.com
Reviewed-by: Andreas Färber
1 - 100 of 107 matches
Mail list logo
