[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] ea4d7a: hw/core/or-irq: Fix incorrect assert
|
From: |
Peter Maydell |
|
Subject: |
[Qemu-commits] [qemu/qemu] ea4d7a: hw/core/or-irq: Fix incorrect assert forbidding nu... |
|
Date: |
Thu, 30 Jan 2020 11:15:13 -0800 |
Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: ea4d7ab5d927baa96b940bcbbdf3b2971cf6b9ab
https://github.com/qemu/qemu/commit/ea4d7ab5d927baa96b940bcbbdf3b2971cf6b9ab
Author: Peter Maydell <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M hw/core/or-irq.c
Log Message:
-----------
hw/core/or-irq: Fix incorrect assert forbidding num-lines == MAX_OR_LINES
The num-lines property of the TYPE_OR_GATE device sets the number
of input lines it has. An assert() in or_irq_realize() restricts
this to the maximum supported by the implementation. However we
got the condition in the assert wrong: it should be using <=,
because num-lines == MAX_OR_LINES is permitted, and means that
all entries from 0 to MAX_OR_LINES-1 in the s->levels[] array
are used.
We didn't notice this previously because no user has so far
needed that many input lines.
Reported-by: Guenter Roeck <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Guenter Roeck <address@hidden>
Message-id: address@hidden
Commit: 16ab12a936ef96b25be7f5981c96548fa772f3df
https://github.com/qemu/qemu/commit/16ab12a936ef96b25be7f5981c96548fa772f3df
Author: Peter Maydell <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M target/arm/arm-semi.c
Log Message:
-----------
target/arm/arm-semi: Don't let the guest close stdin/stdout/stderr
The guest can use the semihosting API to open a handle
corresponding to QEMU's own stdin, stdout, or stderr.
When the guest closes this handle, we should not
close the underlying host stdin/stdout/stderr
the way we would do if the handle corresponded to
a host fd we'd opened on behalf of the guest in SYS_OPEN.
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Alex Bennée <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Commit: 0e2c24c6267c1874daee71ecd98d1f2108ea7c66
https://github.com/qemu/qemu/commit/0e2c24c6267c1874daee71ecd98d1f2108ea7c66
Author: Andrew Jeffery <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M hw/arm/aspeed.c
M hw/arm/aspeed_ast2600.c
M hw/arm/aspeed_soc.c
M hw/sd/aspeed_sdhci.c
M include/hw/sd/aspeed_sdhci.h
Log Message:
-----------
hw/sd: Configure number of slots exposed by the ASPEED SDHCI model
The AST2600 includes a second cut-down version of the SD/MMC controller
found in the AST2500, named the eMMC controller. It's cut down in the
sense that it only supports one slot rather than two, but it brings the
total number of slots supported by the AST2600 to three.
The existing code assumed that the SD controller always provided two
slots. Rework the SDHCI object to expose the number of slots as a
property to be set by the SoC configuration.
Signed-off-by: Andrew Jeffery <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Cédric Le Goater <address@hidden>
Signed-off-by: Cédric Le Goater <address@hidden>
Message-id: address@hidden
[PMM: fixed up to use device_class_set_props()]
Signed-off-by: Peter Maydell <address@hidden>
Commit: a29e3e127077709c6b733475a3a031bc49adf293
https://github.com/qemu/qemu/commit/a29e3e127077709c6b733475a3a031bc49adf293
Author: Andrew Jeffery <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M hw/arm/aspeed.c
M hw/arm/aspeed_ast2600.c
M include/hw/arm/aspeed_soc.h
Log Message:
-----------
hw/arm: ast2600: Wire up the eMMC controller
Initialise another SDHCI model instance for the AST2600's eMMC
controller and use the SDHCI's num_slots value introduced previously to
determine whether we should create an SD card instance for the new slot.
Signed-off-by: Andrew Jeffery <address@hidden>
Reviewed-by: Cédric Le Goater <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Signed-off-by: Cédric Le Goater <address@hidden>
Message-id: address@hidden
[ clg : - removed ternary operator from sdhci_attach_drive()
- renamed SDHCI objects with a '-controller' prefix ]
Signed-off-by: Cédric Le Goater <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
Commit: 55efb365191635d9839600f1f44502769e66aabf
https://github.com/qemu/qemu/commit/55efb365191635d9839600f1f44502769e66aabf
Author: Cédric Le Goater <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M hw/net/ftgmac100.c
Log Message:
-----------
ftgmac100: check RX and TX buffer alignment
These buffers should be aligned on 16 bytes.
Ignore invalid RX and TX buffer addresses and log an error. All
incoming and outgoing traffic will be dropped because no valid RX or
TX descriptors will be available.
Signed-off-by: Cédric Le Goater <address@hidden>
Message-id: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
Commit: 1a15311a12fa6a5c865e7f779e6e1b2557440626
https://github.com/qemu/qemu/commit/1a15311a12fa6a5c865e7f779e6e1b2557440626
Author: Cédric Le Goater <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M hw/arm/aspeed.c
M include/hw/arm/aspeed.h
Log Message:
-----------
hw/arm/aspeed: add a 'execute-in-place' property to boot directly from CE0
The overhead for the OpenBMC firmware images using the a custom U-Boot
is around 2 seconds, which is fine, but with a U-Boot from mainline,
it takes an extra 50 seconds or so to reach Linux. A quick survey on
the number of reads performed on the flash memory region gives the
following figures :
OpenBMC U-Boot 922478 (~ 3.5 MBytes)
Mainline U-Boot 20569977 (~ 80 MBytes)
QEMU must be trashing the TCG TBs and reloading text very often. Some
addresses are read more than 250.000 times. Until we find a solution
to improve boot time, execution from MMIO is not activated by default.
Setting this option also breaks migration compatibility.
Signed-off-by: Cédric Le Goater <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: a90d8f84674da3afaaa15fca7a47901fac5f47b5
https://github.com/qemu/qemu/commit/a90d8f84674da3afaaa15fca7a47901fac5f47b5
Author: Joel Stanley <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M hw/misc/pca9552.c
Log Message:
-----------
misc/pca9552: Add qom set and get
Following the pattern of the work recently done with the ASPEED GPIO
model, this adds support for inspecting and modifying the PCA9552 LEDs
from the monitor.
(qemu) qom-set /machine/unattached/device[17] led0 on
(qemu) qom-set /machine/unattached/device[17] led0 off
(qemu) qom-set /machine/unattached/device[17] led0 pwm0
(qemu) qom-set /machine/unattached/device[17] led0 pwm1
Signed-off-by: Joel Stanley <address@hidden>
Signed-off-by: Cédric Le Goater <address@hidden>
Message-id: address@hidden
[clg: - removed the "qom-get" examples from the commit log
- merged memory leak fixes from Joel ]
Signed-off-by: Cédric Le Goater <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
Commit: 100bc4ab41a9819846a798d4eb8ad495046e8f11
https://github.com/qemu/qemu/commit/100bc4ab41a9819846a798d4eb8ad495046e8f11
Author: Philippe Mathieu-Daudé <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M hw/arm/raspi.c
Log Message:
-----------
hw/arm/raspi: Remove obsolete use of -smp to set the soc 'enabled-cpus'
Since we enabled parallel TCG code generation for softmmu (see
commit 3468b59 "tcg: enable multiple TCG contexts in softmmu")
and its subsequent fix (commit 72649619 "add .min_cpus and
.default_cpus fields to machine_class"), the raspi machines are
restricted to always use their 4 cores:
See in hw/arm/raspi2 (with BCM283X_NCPUS set to 4):
222 static void raspi2_machine_init(MachineClass *mc)
223 {
224 mc->desc = "Raspberry Pi 2";
230 mc->max_cpus = BCM283X_NCPUS;
231 mc->min_cpus = BCM283X_NCPUS;
232 mc->default_cpus = BCM283X_NCPUS;
235 };
236 DEFINE_MACHINE("raspi2", raspi2_machine_init)
We can no longer use the -smp option, as we get:
$ qemu-system-arm -M raspi2 -smp 1
qemu-system-arm: Invalid SMP CPUs 1. The min CPUs supported by machine
'raspi2' is 4
Since we can not set the TYPE_BCM283x SOC "enabled-cpus" with -smp,
remove the unuseful code.
We can achieve the same by using the '-global bcm2836.enabled-cpus=1'
option.
Reported-by: Laurent Bonnans <address@hidden>
Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Alistair Francis <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: f703a04ce558ac3c7c0587a2d919c39efb8ca3ba
https://github.com/qemu/qemu/commit/f703a04ce558ac3c7c0587a2d919c39efb8ca3ba
Author: Damien Hedde <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M hw/audio/intel-hda.c
M hw/core/qdev.c
M hw/hyperv/hyperv.c
M hw/i386/microvm.c
M hw/i386/pc.c
M hw/ide/microdrive.c
M hw/intc/spapr_xive.c
M hw/ppc/pnv_psi.c
M hw/ppc/spapr_pci.c
M hw/ppc/spapr_vio.c
M hw/s390x/s390-pci-inst.c
M hw/scsi/vmw_pvscsi.c
M hw/sd/omap_mmc.c
M hw/sd/pl181.c
M include/hw/qdev-core.h
Log Message:
-----------
add device_legacy_reset function to prepare for reset api change
Provide a temporary device_legacy_reset function doing what
device_reset does to prepare for the transition with Resettable
API.
All occurrence of device_reset in the code tree are also replaced
by device_legacy_reset.
The new resettable API has different prototype and semantics
(resetting child buses as well as the specified device). Subsequent
commits will make the changeover for each call site individually; once
that is complete device_legacy_reset() will be removed.
Signed-off-by: Damien Hedde <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Acked-by: David Gibson <address@hidden>
Acked-by: Cornelia Huck <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: 70804c83f2914acaca74c1789a6b869bd5d1ea67
https://github.com/qemu/qemu/commit/70804c83f2914acaca74c1789a6b869bd5d1ea67
Author: Damien Hedde <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M hw/core/qdev.c
M hw/core/trace-events
Log Message:
-----------
hw/core/qdev: add trace events to help with resettable transition
Adds trace events to reset procedure and when updating the parent
bus of a device.
Signed-off-by: Damien Hedde <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Cornelia Huck <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: bc5a39bf2688130bae86351a6c6b005cf9566a3c
https://github.com/qemu/qemu/commit/bc5a39bf2688130bae86351a6c6b005cf9566a3c
Author: Damien Hedde <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M hw/core/Makefile.objs
A hw/core/resettable.c
M hw/core/trace-events
A include/hw/resettable.h
Log Message:
-----------
hw/core: create Resettable QOM interface
This commit defines an interface allowing multi-phase reset. This aims
to solve a problem of the actual single-phase reset (built in
DeviceClass and BusClass): reset behavior is dependent on the order
in which reset handlers are called. In particular doing external
side-effect (like setting an qemu_irq) is problematic because receiving
object may not be reset yet.
The Resettable interface divides the reset in 3 well defined phases.
To reset an object tree, all 1st phases are executed then all 2nd then
all 3rd. See the comments in include/hw/resettable.h for a more complete
description. The interface defines 3 phases to let the future
possibility of holding an object into reset for some time.
The qdev/qbus reset in DeviceClass and BusClass will be modified in
following commits to use this interface. A mechanism is provided
to allow executing a transitional reset handler in place of the 2nd
phase which is executed in children-then-parent order inside a tree.
This will allow to transition devices and buses smoothly while
keeping the exact current qdev/qbus reset behavior for now.
Documentation will be added in a following commit.
Signed-off-by: Damien Hedde <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: c11256aa6fdd3971ef1dff23dfd8422049558d77
https://github.com/qemu/qemu/commit/c11256aa6fdd3971ef1dff23dfd8422049558d77
Author: Damien Hedde <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M hw/core/bus.c
M hw/core/qdev.c
M include/hw/qdev-core.h
M tests/Makefile.include
Log Message:
-----------
hw/core: add Resettable support to BusClass and DeviceClass
This commit adds support of Resettable interface to buses and devices:
+ ResettableState structure is added in the Bus/Device state
+ Resettable methods are implemented.
+ device/bus_is_in_reset function defined
This commit allows to transition the objects to the new
multi-phase interface without changing the reset behavior at all.
Object single reset method can be split into the 3 different phases
but the 3 phases are still executed in a row for a given object.
>From the qdev/qbus reset api point of view, nothing is changed.
qdev_reset_all() and qbus_reset_all() are not modified as well as
device_legacy_reset().
Transition of an object must be done from parent class to child class.
Care has been taken to allow the transition of a parent class
without requiring the child classes to be transitioned at the same
time. Note that SysBus and SysBusDevice class do not need any transition
because they do not override the legacy reset method.
Signed-off-by: Damien Hedde <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: 614f731adb9cc86bd45ce749f597e68dbde253b1
https://github.com/qemu/qemu/commit/614f731adb9cc86bd45ce749f597e68dbde253b1
Author: Damien Hedde <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M hw/core/resettable.c
M hw/core/trace-events
M include/hw/resettable.h
Log Message:
-----------
hw/core/resettable: add support for changing parent
Add a function resettable_change_parent() to do the required
plumbing when changing the parent a of Resettable object.
We need to make sure that the reset state of the object remains
coherent with the reset state of the new parent.
We make the 2 following hypothesis:
+ when an object is put in a parent under reset, the object goes in
reset.
+ when an object is removed from a parent under reset, the object
leaves reset.
The added function avoids any glitch if both old and new parent are
already in reset.
Signed-off-by: Damien Hedde <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: a7c3a4f986dd2becca5fa11dd7e6eba81b596d06
https://github.com/qemu/qemu/commit/a7c3a4f986dd2becca5fa11dd7e6eba81b596d06
Author: Damien Hedde <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M hw/core/qdev.c
Log Message:
-----------
hw/core/qdev: handle parent bus change regarding resettable
In qdev_set_parent_bus(), when changing the parent bus of a
realized device, if the source and destination buses are not in the
same reset state, some adaptations are required. This patch adds
needed call to resettable_change_parent() to make sure a device reset
state stays coherent with its parent bus.
The addition is a no-op if:
1. the device being parented is not realized.
2. the device is realized, but both buses are not under reset.
Case 2 means that as long as qdev_set_parent_bus() is called
during the machine realization procedure (which is before the
machine reset so nothing is in reset), it is a no op.
There are 52 call sites of qdev_set_parent_bus(). All but one fall
into the no-op case:
+ 29 trivial calls related to virtio (in hw/{s390x,display,virtio}/
{vhost,virtio}-xxx.c) to set a vdev(or vgpu) composing device
parent bus just before realizing the same vdev(vgpu).
+ hw/core/qdev.c: when creating a device in qdev_try_create()
+ hw/core/sysbus.c: when initializing a device in the sysbus
+ hw/i386/amd_iommu.c: before realizing AMDVIState/pci
+ hw/isa/piix4.c: before realizing PIIX4State/rtc
+ hw/misc/auxbus.c: when creating an AUXBus
+ hw/misc/auxbus.c: when creating an AUXBus child
+ hw/misc/macio/macio.c: when initializing a MACIOState child
+ hw/misc/macio/macio.c: before realizing NewWorldMacIOState/pmu
+ hw/misc/macio/macio.c: before realizing NewWorldMacIOState/cuda
+ hw/net/virtio-net.c: Used for migration when using the failover
mechanism to migration a vfio-pci/net. It is
a no-op because at this point the device is
already on the bus.
+ hw/pci-host/designware.c: before realizing DesignwarePCIEHost/root
+ hw/pci-host/gpex.c: before realizing GPEXHost/root
+ hw/pci-host/prep.c: when initialiazing PREPPCIState/pci_dev
+ hw/pci-host/q35.c: before realizing Q35PCIHost/mch
+ hw/pci-host/versatile.c: when initializing PCIVPBState/pci_dev
+ hw/pci-host/xilinx-pcie.c: before realizing XilinxPCIEHost/root
+ hw/s390x/event-facility.c: when creating SCLPEventFacility/
TYPE_SCLP_QUIESCE
+ hw/s390x/event-facility.c: ditto with SCLPEventFacility/
TYPE_SCLP_CPU_HOTPLUG
+ hw/s390x/sclp.c: Not trivial because it is called on a SLCPDevice
just after realizing it. Ok because at this point the destination
bus (sysbus) is not in reset; the realize step is before the
machine reset.
+ hw/sd/core.c: Not OK. Used in sdbus_reparent_card(). See below.
+ hw/ssi/ssi.c: Used to put spi slave on spi bus and connect the cs
line in ssi_auto_connect_slave(). Ok because this function is only
used in realize step in hw/ssi/aspeed_smc.ci, hw/ssi/imx_spi.c,
hw/ssi/mss-spi.c, hw/ssi/xilinx_spi.c and hw/ssi/xilinx_spips.c.
+ hw/xen/xen-legacy-backend.c: when creating a XenLegacyDevice device
+ qdev-monitor.c: in device hotplug creation procedure before realize
Note that this commit alone will have no effect, right now there is no
use of resettable API to reset anything. So a bus will never be tagged
as in-reset by this same API.
The one place where side-effect will occurs is in hw/sd/core.c in
sdbus_reparent_card(). This function is only used in the raspi machines,
including during the sysbus reset procedure. This case will be
carrefully handled when doing the multiple phase reset transition.
Signed-off-by: Damien Hedde <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: e755e12759e91a013e417a438305b133ea3c2d19
https://github.com/qemu/qemu/commit/e755e12759e91a013e417a438305b133ea3c2d19
Author: Damien Hedde <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M hw/core/qdev.c
M include/hw/resettable.h
Log Message:
-----------
hw/core/qdev: update hotplug reset regarding resettable
This commit make use of the resettable API to reset the device being
hotplugged when it is realized. Also it ensures it is put in a reset
state coherent with the parent it is plugged into.
Note that there is a difference in the reset. Instead of resetting
only the hotplugged device, we reset also its subtree (switch to
resettable API). This is not expected to be a problem because
sub-buses are just realized too. If a hotplugged device has any
sub-buses it is logical to reset them too at this point.
The recently added should_be_hidden and PCI's partially_hotplugged
mechanisms do not interfere with realize operation:
+ In the should_be_hidden use case, device creation is
delayed.
+ The partially_hotplugged mechanism prevents a device to be
unplugged and unrealized from qdev POV and unrealized.
Signed-off-by: Damien Hedde <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: abb89dbf2bb3c4f8c74da638a610a73db6a7d4af
https://github.com/qemu/qemu/commit/abb89dbf2bb3c4f8c74da638a610a73db6a7d4af
Author: Damien Hedde <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M hw/core/bus.c
M hw/core/qdev.c
M hw/core/resettable.c
M include/hw/qdev-core.h
M include/hw/resettable.h
Log Message:
-----------
hw/core: deprecate old reset functions and introduce new ones
Deprecate device_legacy_reset(), qdev_reset_all() and
qbus_reset_all() to be replaced by new functions
device_cold_reset() and bus_cold_reset() which uses resettable API.
Also introduce resettable_cold_reset_fn() which may be used as a
replacement for qdev_reset_all_fn and qbus_reset_all_fn().
Following patches will be needed to look at legacy reset call sites
and switch to resettable api. The legacy functions will be removed
when unused.
Signed-off-by: Damien Hedde <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: d66cc84cd19f1d4d29ca64056a0e35efa495f32a
https://github.com/qemu/qemu/commit/d66cc84cd19f1d4d29ca64056a0e35efa495f32a
Author: Damien Hedde <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M docs/devel/index.rst
A docs/devel/reset.rst
Log Message:
-----------
docs/devel/reset.rst: add doc about Resettable interface
Signed-off-by: Damien Hedde <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: 751b4b7b4b7b5bd1e399e3756ef62cc1ef03b177
https://github.com/qemu/qemu/commit/751b4b7b4b7b5bd1e399e3756ef62cc1ef03b177
Author: Damien Hedde <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M vl.c
Log Message:
-----------
vl: replace deprecated qbus_reset_all registration
Replace deprecated qbus_reset_all by resettable_cold_reset_fn for
the sysbus reset registration.
Apart for the raspi machines, this does not impact the behavior
because:
+ at this point resettable just calls the old reset methods of devices
and buses in the same order as qdev/qbus.
+ resettable handlers registered with qemu_register_reset are
serialized; there is no interleaving.
+ eventual explicit calls to legacy reset API (device_reset or
qdev/qbus_reset) inside this reset handler will not be masked out
by resettable mechanism; they do not go through resettable api.
For the raspi machines, during the sysbus reset the sd-card is not
reset twice anymore but only once. This is a consequence of switching
both sysbus reset and changing parent to resettable; it detects the
second reset is not needed. This has no impact on the state after
reset; the sd-card reset method only reset local state and query
information from the block backend.
The raspi reset change can be observed by using the following command
(reset will occurs, then do Ctrl-C to end qemu; no firmware is
given here).
qemu-system-aarch64 -M raspi3 \
-trace resettable_phase_hold_exec \
-trace qdev_update_parent_bus \
-trace resettable_change_parent \
-trace qdev_reset -trace qbus_reset
Before the patch, the qdev/qbus_reset traces show when reset method are
called. After the patch, the resettable_phase_hold_exec show when reset
method are called.
The traced reset order of the raspi3 is listed below. I've added empty
lines and the tree structure.
+->bcm2835-peripherals reset
|
| +->sd-card reset
| +->sd-bus reset
+->bcm2835_gpio reset
| -> dev_update_parent_bus (move the sd-card on the sdhci-bus)
| -> resettable_change_parent
|
+->bcm2835-dma reset
|
| +->bcm2835-sdhost-bus reset
+->bcm2835-sdhost reset
|
| +->sd-card (reset ONLY BEFORE BEFORE THE PATCH)
| +->sdhci-bus reset
+->generic-sdhci reset
|
+->bcm2835-rng reset
+->bcm2835-property reset
+->bcm2835-fb reset
+->bcm2835-mbox reset
+->bcm2835-aux reset
+->pl011 reset
+->bcm2835-ic reset
+->bcm2836-control reset
System reset
In both case, the sd-card is reset (being on bcm2835_gpio/sd-bus) then moved
to generic-sdhci/sdhci-bus by the bcm2835_gpio reset method.
Before the patch, it is then reset again being part of generic-sdhci/sdhci-bus.
After the patch, it considered again for reset but its reset method is not
called because it is already flagged as reset.
Signed-off-by: Damien Hedde <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: cd45c506c8ec37c05fdfe06441ad350ab8e19138
https://github.com/qemu/qemu/commit/cd45c506c8ec37c05fdfe06441ad350ab8e19138
Author: Damien Hedde <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M hw/s390x/ipl.c
Log Message:
-----------
hw/s390x/ipl: replace deprecated qdev_reset_all registration
Replace deprecated qdev_reset_all by resettable_cold_reset_fn for
the ipl registration in the main reset handlers.
This does not impact the behavior for the following reasons:
+ at this point resettable just call the old reset methods of devices
and buses in the same order than qdev/qbus.
+ resettable handlers registered with qemu_register_reset are
serialized; there is no interleaving.
+ eventual explicit calls to legacy reset API (device_reset or
qdev/qbus_reset) inside this reset handler will not be masked out
by resettable mechanism; they do not go through resettable api.
Signed-off-by: Damien Hedde <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Reviewed-by: Cornelia Huck <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: 618bacabd3c8c3360be795cd8763bacdf5bec101
https://github.com/qemu/qemu/commit/618bacabd3c8c3360be795cd8763bacdf5bec101
Author: Zenghui Yu <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M hw/intc/arm_gicv3_kvm.c
Log Message:
-----------
hw/intc/arm_gicv3_kvm: Stop wrongly programming GICR_PENDBASER.PTZ bit
If LPIs are disabled, KVM will just ignore the GICR_PENDBASER.PTZ bit when
restoring GICR_CTLR. Setting PTZ here makes littlt sense in "reduce GIC
initialization time".
And what's worse, PTZ is generally programmed by guest to indicate to the
Redistributor whether the LPI Pending table is zero when enabling LPIs.
If migration is triggered when the PTZ has just been cleared by guest (and
before enabling LPIs), we will see PTZ==1 on the destination side, which
is not as expected. Let's just drop this hackish userspace behavior.
Also take this chance to refine the comment a bit.
Fixes: 367b9f527bec ("hw/intc/arm_gicv3_kvm: Implement get/put functions")
Signed-off-by: Zenghui Yu <address@hidden>
Message-id: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
Commit: d1ebbc9d16297b54b153ee33abe05eb4f1df0c66
https://github.com/qemu/qemu/commit/d1ebbc9d16297b54b153ee33abe05eb4f1df0c66
Author: Andrew Jones <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M target/arm/kvm_arm.h
Log Message:
-----------
target/arm/kvm: trivial: Clean up header documentation
Signed-off-by: Andrew Jones <address@hidden>
Message-id: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
Commit: fa7c8e92cb9bb004359926497675a9b7d0099dfc
https://github.com/qemu/qemu/commit/fa7c8e92cb9bb004359926497675a9b7d0099dfc
Author: Andrew Jones <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M hw/arm/virt.c
Log Message:
-----------
hw/arm/virt: Add missing 5.0 options call to 4.2 options
Signed-off-by: Andrew Jones <address@hidden>
Message-id: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
Commit: 65caa415487f4a6e265105446c6ef8f56bb0aa70
https://github.com/qemu/qemu/commit/65caa415487f4a6e265105446c6ef8f56bb0aa70
Author: Andrew Jones <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M target/arm/kvm64.c
Log Message:
-----------
target/arm/kvm64: kvm64 cpus have timer registers
Add the missing GENERIC_TIMER feature to kvm64 cpus.
We don't currently use these registers when KVM is enabled, but it's
probably best we add the feature flag for consistency and potential
future use. There's also precedent, as we add the PMU feature flag to
KVM enabled guests, even though we don't use those registers either.
This change was originally posted as a hunk of a different, never
merged patch from Bijan Mottahedeh.
Signed-off-by: Andrew Jones <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: 789a35efb583464f9fcd5d871a7fd6164318bb91
https://github.com/qemu/qemu/commit/789a35efb583464f9fcd5d871a7fd6164318bb91
Author: Andrew Jones <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M tests/qtest/arm-cpu-features.c
Log Message:
-----------
tests/arm-cpu-features: Check feature default values
If we know what the default value should be then we can test for
that as well as the feature existence.
Signed-off-by: Andrew Jones <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: e5ac4200b4cddf44df9adbef677af0d1f1c579c6
https://github.com/qemu/qemu/commit/e5ac4200b4cddf44df9adbef677af0d1f1c579c6
Author: Andrew Jones <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M target/arm/cpu.h
M target/arm/kvm.c
M target/arm/kvm32.c
M target/arm/kvm64.c
M target/arm/kvm_arm.h
M target/arm/machine.c
Log Message:
-----------
target/arm/kvm: Implement virtual time adjustment
When a VM is stopped (such as when it's paused) guest virtual time
should stop counting. Otherwise, when the VM is resumed it will
experience time jumps and its kernel may report soft lockups. Not
counting virtual time while the VM is stopped has the side effect
of making the guest's time appear to lag when compared with real
time, and even with time derived from the physical counter. For
this reason, this change, which is enabled by default, comes with
a KVM CPU feature allowing it to be disabled, restoring legacy
behavior.
This patch only provides the implementation of the virtual time
adjustment. A subsequent patch will provide the CPU property
allowing the change to be enabled and disabled.
Reported-by: Bijan Mottahedeh <address@hidden>
Signed-off-by: Andrew Jones <address@hidden>
Message-id: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
Commit: dea101a1ae9968c9fec6ab0291489dad7c49f36f
https://github.com/qemu/qemu/commit/dea101a1ae9968c9fec6ab0291489dad7c49f36f
Author: Andrew Jones <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M docs/arm-cpu-features.rst
M hw/arm/virt.c
M include/hw/arm/virt.h
M target/arm/cpu.c
M target/arm/cpu64.c
M target/arm/kvm.c
M target/arm/kvm_arm.h
M target/arm/monitor.c
M tests/qtest/arm-cpu-features.c
Log Message:
-----------
target/arm/cpu: Add the kvm-no-adjvtime CPU property
kvm-no-adjvtime is a KVM specific CPU property and a first of its
kind. To accommodate it we also add kvm_arm_add_vcpu_properties()
and a KVM specific CPU properties description to the CPU features
document.
Signed-off-by: Andrew Jones <address@hidden>
Message-id: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
Commit: 928173659d6e5dc368284f73f90ea1d129e1f57d
https://github.com/qemu/qemu/commit/928173659d6e5dc368284f73f90ea1d129e1f57d
Author: Peter Maydell <address@hidden>
Date: 2020-01-30 (Thu, 30 Jan 2020)
Changed paths:
M docs/arm-cpu-features.rst
M docs/devel/index.rst
A docs/devel/reset.rst
M hw/arm/aspeed.c
M hw/arm/aspeed_ast2600.c
M hw/arm/aspeed_soc.c
M hw/arm/raspi.c
M hw/arm/virt.c
M hw/audio/intel-hda.c
M hw/core/Makefile.objs
M hw/core/bus.c
M hw/core/or-irq.c
M hw/core/qdev.c
A hw/core/resettable.c
M hw/core/trace-events
M hw/hyperv/hyperv.c
M hw/i386/microvm.c
M hw/i386/pc.c
M hw/ide/microdrive.c
M hw/intc/arm_gicv3_kvm.c
M hw/intc/spapr_xive.c
M hw/misc/pca9552.c
M hw/net/ftgmac100.c
M hw/ppc/pnv_psi.c
M hw/ppc/spapr_pci.c
M hw/ppc/spapr_vio.c
M hw/s390x/ipl.c
M hw/s390x/s390-pci-inst.c
M hw/scsi/vmw_pvscsi.c
M hw/sd/aspeed_sdhci.c
M hw/sd/omap_mmc.c
M hw/sd/pl181.c
M include/hw/arm/aspeed.h
M include/hw/arm/aspeed_soc.h
M include/hw/arm/virt.h
M include/hw/qdev-core.h
A include/hw/resettable.h
M include/hw/sd/aspeed_sdhci.h
M target/arm/arm-semi.c
M target/arm/cpu.c
M target/arm/cpu.h
M target/arm/cpu64.c
M target/arm/kvm.c
M target/arm/kvm32.c
M target/arm/kvm64.c
M target/arm/kvm_arm.h
M target/arm/machine.c
M target/arm/monitor.c
M tests/Makefile.include
M tests/qtest/arm-cpu-features.c
M vl.c
Log Message:
-----------
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20200130'
into staging
target-arm queue:
* hw/core/or-irq: Fix incorrect assert forbidding num-lines == MAX_OR_LINES
* target/arm/arm-semi: Don't let the guest close stdin/stdout/stderr
* aspeed: some minor bugfixes
* aspeed: add eMMC controller model for AST2600 SoC
* hw/arm/raspi: Remove obsolete use of -smp to set the soc 'enabled-cpus'
* New 3-phase reset API for device models
* hw/intc/arm_gicv3_kvm: Stop wrongly programming GICR_PENDBASER.PTZ bit
* Arm KVM: stop/restart the guest counter when the VM is stopped and started
# gpg: Signature made Thu 30 Jan 2020 16:14:45 GMT
# gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg: issuer "address@hidden"
# gpg: Good signature from "Peter Maydell <address@hidden>" [ultimate]
# gpg: aka "Peter Maydell <address@hidden>" [ultimate]
# gpg: aka "Peter Maydell <address@hidden>" [ultimate]
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE
* remotes/pmaydell/tags/pull-target-arm-20200130: (26 commits)
target/arm/cpu: Add the kvm-no-adjvtime CPU property
target/arm/kvm: Implement virtual time adjustment
tests/arm-cpu-features: Check feature default values
target/arm/kvm64: kvm64 cpus have timer registers
hw/arm/virt: Add missing 5.0 options call to 4.2 options
target/arm/kvm: trivial: Clean up header documentation
hw/intc/arm_gicv3_kvm: Stop wrongly programming GICR_PENDBASER.PTZ bit
hw/s390x/ipl: replace deprecated qdev_reset_all registration
vl: replace deprecated qbus_reset_all registration
docs/devel/reset.rst: add doc about Resettable interface
hw/core: deprecate old reset functions and introduce new ones
hw/core/qdev: update hotplug reset regarding resettable
hw/core/qdev: handle parent bus change regarding resettable
hw/core/resettable: add support for changing parent
hw/core: add Resettable support to BusClass and DeviceClass
hw/core: create Resettable QOM interface
hw/core/qdev: add trace events to help with resettable transition
add device_legacy_reset function to prepare for reset api change
hw/arm/raspi: Remove obsolete use of -smp to set the soc 'enabled-cpus'
misc/pca9552: Add qom set and get
...
Signed-off-by: Peter Maydell <address@hidden>
Compare: https://github.com/qemu/qemu/compare/204aa60b37c2...928173659d6e
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] ea4d7a: hw/core/or-irq: Fix incorrect assert forbidding nu...,
Peter Maydell <=