[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] 7e26c9: adb: Correct class size on TYPE_ADB_D
|
From: |
Peter Maydell |
|
Subject: |
[Qemu-commits] [qemu/qemu] 7e26c9: adb: Correct class size on TYPE_ADB_DEVICE |
|
Date: |
Tue, 08 Sep 2020 09:30:34 -0700 |
Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: 7e26c92ba816fccc40ab0a7c1364b65f226e2b21
https://github.com/qemu/qemu/commit/7e26c92ba816fccc40ab0a7c1364b65f226e2b21
Author: David Gibson <david@gibson.dropbear.id.au>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/input/adb.c
Log Message:
-----------
adb: Correct class size on TYPE_ADB_DEVICE
The TypeInfo incorrectly just lets the class size be inherited. It won't
actually break things, since the class is abstract, but we should get it
right.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Commit: 021e878f2efaa4fdcb5e11abfa224f5ba813f809
https://github.com/qemu/qemu/commit/021e878f2efaa4fdcb5e11abfa224f5ba813f809
Author: Cédric Le Goater <clg@kaod.org>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/ppc/pnv_lpc.c
Log Message:
-----------
ppc/pnv: Fix TypeInfo of PnvLpcController abstract class
It was missing the instance_size field.
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20200822083920.2668930-1-clg@kaod.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: 98b49b2bea15ed799e6876336c05de030a040586
https://github.com/qemu/qemu/commit/98b49b2bea15ed799e6876336c05de030a040586
Author: David Gibson <david@gibson.dropbear.id.au>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M include/hw/ppc/spapr_drc.h
Log Message:
-----------
spapr: Remove unnecessary DRC type-checker macros
spapr_drc.h includes typechecker macro boilerplate for the many different
DRC subclasses. However, most of these types don't actually have different
data in their class and/or instance, making these unneeded, unused, and in
fact a bad idea. Remove them.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
Commit: 4f311a70893800f33b57852ca4453823271c022b
https://github.com/qemu/qemu/commit/4f311a70893800f33b57852ca4453823271c022b
Author: Cédric Le Goater <clg@kaod.org>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/intc/spapr_xive.c
M include/hw/ppc/spapr_xive.h
Log Message:
-----------
spapr/xive: Add a 'hv-prio' property to represent the KVM escalation priority
On POWER9, the KVM XIVE device uses priority 7 for the escalation
interrupts. On POWER10, the host can use a reduced set of priorities
and KVM will configure the escalation priority to a lower number. In
any case, the guest is allowed to use priorities in a single range :
[ 0 .. (maxprio - 1) ].
Introduce a 'hv-prio' property to represent the escalation priority
number and use it to compute the "ibm,plat-res-int-priorities"
property defining the priority ranges reserved by the hypervisor.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20200819130843.2230799-2-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: c02f9892af1f166634e1b4fd722044151acb5e88
https://github.com/qemu/qemu/commit/c02f9892af1f166634e1b4fd722044151acb5e88
Author: Cédric Le Goater <clg@kaod.org>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/ppc/pnv_bmc.c
M include/hw/ipmi/ipmi.h
Log Message:
-----------
ppc/pnv: Add a HIOMAP erase command
The OPAL test suite runs a read-erase-write test on the PNOR :
https://github.com/open-power/op-test/blob/master/testcases/OpTestPNOR.py
which revealed that the IPMI HIOMAP handlers didn't support
HIOMAP_C_ERASE. Implement the sector erase command by writing 0xFF in
the PNOR memory region.
Cc: Corey Minyard <cminyard@mvista.com>
Reported-by: Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20200820164638.2515681-1-clg@kaod.org>
Acked-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: 64dbe2c8b823a64ddda5ddef52b7d5a1ddf35d8f
https://github.com/qemu/qemu/commit/64dbe2c8b823a64ddda5ddef52b7d5a1ddf35d8f
Author: Daniel Henrique Barboza <danielhb413@gmail.com>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/scsi/spapr_vscsi.c
Log Message:
-----------
spapr_vscsi: do not allow device hotplug
We do not implement hotplug in the vscsi bus, but we forgot to
tell qdev about it. The result is that users are able to hotplug
devices in the vscsi bus, the devices appear in qdev, but they
aren't usable by the guest OS unless the user reboots it first.
Setting qbus hotplug_handler to NULL will tell qdev-monitor, via
qbus_is_hotpluggable(), that we do not support hotplug operations
in spapr_vscsi.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1862059
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200820190635.379657-1-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: b31911c6167432edc7dc5dd37e8c01f426576224
https://github.com/qemu/qemu/commit/b31911c6167432edc7dc5dd37e8c01f426576224
Author: Cédric Le Goater <clg@kaod.org>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/ppc/spapr_irq.c
Log Message:
-----------
spapr/xive: Use the xics flag to check for XIVE-only IRQ backends
The sPAPR machine has four different IRQ backends, each implementing
the XICS or XIVE interrupt mode or both in the case of the 'dual'
backend.
If a machine is started in P8 compat mode, QEMU should necessarily
support the XICS interrupt mode and in that case, the XIVE-only IRQ
backend is invalid. Currently, spapr_irq_check() tests the pointer
value to the IRQ backend to check for this condition, instead use the
'xics' flag. It's equivalent and it will ease the introduction of new
XIVE-only IRQ backends if needed.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20200820140106.2357228-1-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: 235d3b116213828f4206e2e4b199a32bffc96f35
https://github.com/qemu/qemu/commit/235d3b116213828f4206e2e4b199a32bffc96f35
Author: Cédric Le Goater <clg@kaod.org>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/intc/spapr_xive_kvm.c
Log Message:
-----------
spapr/xive: Modify kvm_cpu_is_enabled() interface
We will use to check if a vCPU IPI has been created.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20200820134547.2355743-2-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: fa94447a2cd6643609d5822d5b5f739dc8ad8a8c
https://github.com/qemu/qemu/commit/fa94447a2cd6643609d5822d5b5f739dc8ad8a8c
Author: Cédric Le Goater <clg@kaod.org>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/intc/spapr_xive_kvm.c
Log Message:
-----------
spapr/xive: Use kvmppc_xive_source_reset() in post_load
This is doing an extra loop but should be equivalent.
It also differentiate the reset of the sources from the restore of the
sources configuration. This will help in allocating the vCPU IPIs
independently.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20200820134547.2355743-3-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: acbdb9956fe93f4669141f103cb543d3025775db
https://github.com/qemu/qemu/commit/acbdb9956fe93f4669141f103cb543d3025775db
Author: Cédric Le Goater <clg@kaod.org>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/intc/spapr_xive_kvm.c
Log Message:
-----------
spapr/xive: Allocate IPIs independently from the other sources
The vCPU IPIs are now allocated in kvmppc_xive_cpu_connect() when the
vCPU connects to the KVM device and not when all the sources are reset
in kvmppc_xive_source_reset()
This requires extra care for hotplug vCPUs and VM restore.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20200820134547.2355743-4-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: eab0a2d06e97ebcf74e8437aa985eee5df3a4c68
https://github.com/qemu/qemu/commit/eab0a2d06e97ebcf74e8437aa985eee5df3a4c68
Author: Cédric Le Goater <clg@kaod.org>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/intc/spapr_xive_kvm.c
Log Message:
-----------
spapr/xive: Allocate vCPU IPIs from the vCPU contexts
When QEMU switches to the XIVE interrupt mode, it creates all the
guest interrupts at the level of the KVM device. These interrupts are
backed by real HW interrupts from the IPI interrupt pool of the XIVE
controller.
Currently, this is done from the QEMU main thread, which results in
allocating all interrupts from the chip on which QEMU is running. IPIs
are not distributed across the system and the load is not well
balanced across the interrupt controllers.
Change the vCPU IPI allocation to run from the vCPU context. The
associated XIVE IPI interrupt will be allocated on the chip on which
the vCPU is running and improve distribution of the IPIs in the system.
When the vCPUs are pinned, this will make the IPI local to the chip of
the vCPU. It will reduce rerouting between interrupt controllers and
gives better performance.
Device interrupts are still treated the same. To improve placement, we
would need some information on the chip owning the virtual source or
the HW source in case of a passthrough device but this reuires
changes in PAPR.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20200820134547.2355743-5-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: 90d282d0858cf5a38f3e8a7e201aeab2a0ccbe88
https://github.com/qemu/qemu/commit/90d282d0858cf5a38f3e8a7e201aeab2a0ccbe88
Author: Daniel Henrique Barboza <danielhb413@gmail.com>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/ppc/spapr_nvdimm.c
Log Message:
-----------
ppc/spapr_nvdimm: use g_autofree in spapr_nvdimm_validate_opts()
Since we're using the string just once, just use g_autofree and
avoid leaking it without calling g_free().
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200825215749.213536-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: beb6073fe7f53526bc49f9cb1a3a830c2cdaf3e7
https://github.com/qemu/qemu/commit/beb6073fe7f53526bc49f9cb1a3a830c2cdaf3e7
Author: Daniel Henrique Barboza <danielhb413@gmail.com>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/ppc/spapr.c
M hw/ppc/spapr_nvdimm.c
M include/hw/ppc/spapr_nvdimm.h
Log Message:
-----------
spapr, spapr_nvdimm: fold NVDIMM validation in the same place
NVDIMM has different contraints and conditions than the regular
DIMM and we'll need to add at least one more.
Instead of relying on 'if (nvdimm)' conditionals in the body of
spapr_memory_pre_plug(), use the existing spapr_nvdimm_validate_opts()
and put all NVDIMM handling code there. Rename it to
spapr_nvdimm_validate() to reflect that the function is now checking
more than the nvdimm device options. This makes spapr_memory_pre_plug()
a bit easier to follow, and we can tune in NVDIMM parameters
and validation in the same place.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200825215749.213536-3-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: 28f5a716212b891eef3eadc2c5053c0e0c512e1d
https://github.com/qemu/qemu/commit/28f5a716212b891eef3eadc2c5053c0e0c512e1d
Author: Daniel Henrique Barboza <danielhb413@gmail.com>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/ppc/spapr_nvdimm.c
Log Message:
-----------
ppc/spapr_nvdimm: do not enable support with 'nvdimm=off'
The NVDIMM support for pSeries was introduced in 5.1, but it
didn't contemplate the 'nvdimm' machine option that other
archs uses. For every other arch, if no '-machine nvdimm(=on)'
is present, it is assumed that the NVDIMM support is disabled.
The user must explictly inform that the machine supports
NVDIMM. For pseries-5.1 the 'nvdimm' option is completely
ignored, and support is always assumed to exist. This
leads to situations where the user is able to set 'nvdimm=off'
but the guest boots up with the NVDIMMs anyway.
Fixing this now, after 5.1 launch, can put the overall NVDIMM
support for pseries in a strange place regarding this 'nvdimm'
machine option. If we force everything to be like other archs,
existing pseries-5.1 guests that didn't use 'nvdimm' to use NVDIMM
devices will break. If we attempt to make the newer pseries
machines (5.2+) behave like everyone else, but keep pseries-5.1
untouched, we'll have consistency problems on machine upgrade
(5.1 will have different default values for NVDIMM support than
5.2).
The common ground here is, if the user sets 'nvdimm=off', we
must comply regardless of being 5.1 or 5.2+. This patch
changes spapr_nvdimm_validate() to verify if the user set
NVDIMM support off in the machine options and, in that
case, error out if we have a NVDIMM device. The default
value for 5.2+ pseries machines will still be 'nvdimm=on'
when there is no 'nvdimm' option declared, just like it is today
with pseries-5.1. In the end we'll have different default
semantics from everyone else in the absence of the 'nvdimm'
machine option, but this boat has sailed.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1848887
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200825215749.213536-4-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: c1b701587e59d9569c38d1d6033cd7cc2a992105
https://github.com/qemu/qemu/commit/c1b701587e59d9569c38d1d6033cd7cc2a992105
Author: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M exec.c
M include/hw/core/cpu.h
M target/arm/cpu.c
M target/arm/cpu.h
M target/arm/kvm32.c
M target/arm/kvm64.c
Log Message:
-----------
target/arm: Move start-powered-off property to generic CPUState
There are other platforms which also have CPUs that start powered off, so
generalize the start-powered-off property so that it can be used by them.
Note that ARMv7MState also has a property of the same name but this patch
doesn't change it because that class isn't a subclass of CPUState so it
wouldn't be a trivial change.
This change should not cause any change in behavior.
Suggested-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Message-Id: <20200826055535.951207-2-bauerman@linux.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: 6ad1da667c8e21f019d4adc21702e06dd9225790
https://github.com/qemu/qemu/commit/6ad1da667c8e21f019d4adc21702e06dd9225790
Author: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/core/cpu.c
M target/arm/cpu.c
Log Message:
-----------
target/arm: Move setting of CPU halted state to generic code
This change is in a separate patch because it's not so obvious that it
won't cause a regression.
Suggested-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Message-Id: <20200826055535.951207-3-bauerman@linux.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: 554c2169e9251ca2829ab968bd9ba5641a5abe1d
https://github.com/qemu/qemu/commit/554c2169e9251ca2829ab968bd9ba5641a5abe1d
Author: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/ppc/spapr_cpu_core.c
Log Message:
-----------
ppc/spapr: Use start-powered-off CPUState property
PowerPC sPAPR CPUs start in the halted state, and spapr_reset_vcpu()
attempts to implement this by setting CPUState::halted to 1. But that's too
late for the case of hotplugged CPUs in a machine configure with 2 or more
threads per core.
By then, other parts of QEMU have already caused the vCPU to run in an
unitialized state a couple of times. For example, ppc_cpu_reset() calls
ppc_tlb_invalidate_all(), which ends up calling async_run_on_cpu(). This
kicks the new vCPU while it has CPUState::halted = 0, causing QEMU to issue
a KVM_RUN ioctl on the new vCPU before the guest is able to make the
start-cpu RTAS call to initialize its register state.
This problem doesn't seem to cause visible issues for regular guests, but
on a secure guest running under the Ultravisor it does. The Ultravisor
relies on being able to snoop on the start-cpu RTAS call to map vCPUs to
guests, and this issue causes it to see a stray vCPU that doesn't belong to
any guest.
Fix by setting the start-powered-off CPUState property in
spapr_create_vcpu(), which makes cpu_common_reset() initialize
CPUState::halted to 1 at an earlier moment.
Suggested-by: Eduardo Habkost <ehabkost@redhat.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Message-Id: <20200826055535.951207-4-bauerman@linux.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: a2c93f06cf63c29448f60285b7e103bc07cf014b
https://github.com/qemu/qemu/commit/a2c93f06cf63c29448f60285b7e103bc07cf014b
Author: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/ppc/e500.c
Log Message:
-----------
ppc/e500: Use start-powered-off CPUState property
Instead of setting CPUState::halted to 1 in ppce500_cpu_reset_sec(), use
the start-powered-off property which makes cpu_common_reset() initialize it
to 1 in common code.
Also change creation of CPU object from cpu_create() to object_new() and
qdev_realize_and_unref() because cpu_create() realizes the CPU and it's not
possible to set a property after the object is realized.
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Message-Id: <20200826055535.951207-5-bauerman@linux.ibm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: 102ca9667d1e813c305ff84e6d07408258717ba9
https://github.com/qemu/qemu/commit/102ca9667d1e813c305ff84e6d07408258717ba9
Author: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/mips/cps.c
Log Message:
-----------
mips/cps: Use start-powered-off CPUState property
Instead of setting CPUState::halted to 1 in main_cpu_reset(), use the
start-powered-off property which makes cpu_common_reset() initialize it
to 1 in common code.
Also change creation of CPU object from cpu_create() to object_new() and
qdev_realize_and_unref() because cpu_create() realizes the CPU and it's not
possible to set a property after the object is realized.
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Message-Id: <20200826055535.951207-6-bauerman@linux.ibm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: 3d0c102092bc6096c278784484605096aa4f2384
https://github.com/qemu/qemu/commit/3d0c102092bc6096c278784484605096aa4f2384
Author: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/sparc/sun4m.c
Log Message:
-----------
sparc/sun4m: Don't set cs->halted = 0 in main_cpu_reset()
We rely on cpu_common_reset() to set cs->halted to 0, it's redundant to do
it in main_cpu_reset().
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Message-Id: <20200826055535.951207-7-bauerman@linux.ibm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: 24f675cd3b1406f3af9f9b811bb6946d0e2e6ecf
https://github.com/qemu/qemu/commit/24f675cd3b1406f3af9f9b811bb6946d0e2e6ecf
Author: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/sparc/sun4m.c
Log Message:
-----------
sparc/sun4m: Use start-powered-off CPUState property
Instead of setting CPUState::halted to 1 in secondary_cpu_reset(), use the
start-powered-off property which makes cpu_common_reset() initialize it
to 1 in common code.
Now secondary_cpu_reset() becomes equivalent to main_cpu_reset() so rename
the function to sun4m_cpu_reset().
Also remove setting of cs->halted from cpu_devinit(), which seems out of
place when compared to similar code in other architectures (e.g.,
ppce500_init() in hw/ppc/e500.c).
Finally, change creation of CPU object from cpu_create() to object_new()
and qdev_realize_and_unref() because cpu_create() realizes the CPU and it's
not possible to set a property after the object is realized.
Suggested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Message-Id: <20200826055535.951207-8-bauerman@linux.ibm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: 86c5e6aba6c08a81986fc8c82bfce477288ede48
https://github.com/qemu/qemu/commit/86c5e6aba6c08a81986fc8c82bfce477288ede48
Author: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M target/s390x/cpu.c
Log Message:
-----------
target/s390x: Use start-powered-off CPUState property
Instead of setting CPUState::halted to 1 in s390_cpu_initfn(), use the
start-powered-off property which makes cpu_common_reset() initialize it
to 1 in common code.
Note that this changes behavior by setting cs->halted to 1 on reset, which
didn't happen before.
Acked-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Message-Id: <20200826055535.951207-9-bauerman@linux.ibm.com>
[dwg: Fix from Laurent Vivier for user only case]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: 4192920cbc962770d54cd932748f913a7b1fe3c7
https://github.com/qemu/qemu/commit/4192920cbc962770d54cd932748f913a7b1fe3c7
Author: Philippe Mathieu-Daudé <f4bug@amsat.org>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/ppc/ppc4xx_pci.c
Log Message:
-----------
hw/ppc/ppc4xx_pci: Use ARRAY_SIZE() instead of magic value
Replace the magic '4' by ARRAY_SIZE(s->irq) which is more explicit.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20200901104043.91383-4-f4bug@amsat.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: f5f239315cbf047aef51022ecb083fc7662c660a
https://github.com/qemu/qemu/commit/f5f239315cbf047aef51022ecb083fc7662c660a
Author: Philippe Mathieu-Daudé <f4bug@amsat.org>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/ppc/ppc4xx_pci.c
Log Message:
-----------
hw/ppc/ppc4xx_pci: Replace pointless warning by assert()
We call pci_register_root_bus() to register 4 IRQs with the
ppc4xx_pci_set_irq() handler. As it can only be called with
values in the [0-4[ range, replace the pointless warning by
an assert().
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20200901104043.91383-5-f4bug@amsat.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: 1eee9950264867232a8771e60f3955b84acf538f
https://github.com/qemu/qemu/commit/1eee9950264867232a8771e60f3955b84acf538f
Author: Daniel Henrique Barboza <danielhb413@gmail.com>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/ppc/meson.build
M hw/ppc/spapr.c
A hw/ppc/spapr_numa.c
A include/hw/ppc/spapr_numa.h
Log Message:
-----------
ppc: introducing spapr_numa.c NUMA code helper
We're going to make changes in how spapr handles all
ibm,associativity* related properties to enhance our current NUMA
support.
At this moment we have associativity code scattered all around
spapr_* files, with hardcoded values and array sizes. This
makes it harder to change any NUMA specific parameters in
the future. Having everything in the same place allows not
only for easier tuning, but also easier understanding since all
NUMA related code is on the same file.
This patch introduces a new file to gather all NUMA/associativity
handling code in spapr, spapr_numa.c. To get things started, let's
remove associativity-reference-points and max-associativity-domains
code from spapr_dt_rtas() to a new helper called spapr_numa_write_rtas_dt().
This will decouple spapr_dt_rtas() from the NUMA changes that
are going to happen in those two properties.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200901125645.118026-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: 6ee1d62e6af84c5ccda06763f2e58fb3f41ba106
https://github.com/qemu/qemu/commit/6ee1d62e6af84c5ccda06763f2e58fb3f41ba106
Author: Daniel Henrique Barboza <danielhb413@gmail.com>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/ppc/spapr_nvdimm.c
M include/hw/ppc/spapr_nvdimm.h
Log Message:
-----------
ppc/spapr_nvdimm: turn spapr_dt_nvdimm() static
This function is only used inside spapr_nvdimm.c.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200901125645.118026-3-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: f1aa45fffeeb084a9ad8bd08e83c5ec6af223884
https://github.com/qemu/qemu/commit/f1aa45fffeeb084a9ad8bd08e83c5ec6af223884
Author: Daniel Henrique Barboza <danielhb413@gmail.com>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/ppc/spapr.c
M hw/ppc/spapr_numa.c
M hw/ppc/spapr_nvdimm.c
M hw/ppc/spapr_pci.c
M include/hw/ppc/spapr.h
M include/hw/ppc/spapr_numa.h
M include/hw/ppc/spapr_nvdimm.h
Log Message:
-----------
spapr: introduce SpaprMachineState::numa_assoc_array
The next step to centralize all NUMA/associativity handling in
the spapr machine is to create a 'one stop place' for all
things ibm,associativity.
This patch introduces numa_assoc_array, a 2 dimensional array
that will store all ibm,associativity arrays of all NUMA nodes.
This array is initialized in a new spapr_numa_associativity_init()
function, called in spapr_machine_init(). It is being initialized
with the same values used in other ibm,associativity properties
around spapr files (i.e. all zeros, last value is node_id).
The idea is to remove all hardcoded definitions and FDT writes
of ibm,associativity arrays, doing instead a call to the new
helper spapr_numa_write_associativity_dt() helper, that will
be able to write the DT with the correct values.
We'll start small, handling the trivial cases first. The
remaining instances of ibm,associativity will be handled
next.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200903220639.563090-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: 8f86a408241264db605da9a1215a409475a60bd0
https://github.com/qemu/qemu/commit/8f86a408241264db605da9a1215a409475a60bd0
Author: Daniel Henrique Barboza <danielhb413@gmail.com>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/ppc/spapr.c
M hw/ppc/spapr_numa.c
M include/hw/ppc/spapr_numa.h
Log Message:
-----------
spapr, spapr_numa: handle vcpu ibm,associativity
Vcpus have an additional paramenter to be appended, vcpu_id. This
also changes the size of the of property itself, which is being
represented in index 0 of numa_assoc_array[cpu->node_id],
and defaults to MAX_DISTANCE_REF_POINTS for all cases but
vcpus.
All this logic makes more sense in spapr_numa.c, where we handle
everything NUMA and associativity. A new helper spapr_numa_fixup_cpu_dt()
was added, and spapr.c uses it the same way as it was using the former
spapr_fixup_cpu_numa_dt().
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200903220639.563090-3-danielhb413@gmail.com>
[dwg: Correct uint to int type, which can break windows builds]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: 0ee520126a2a1a2539e54b6d0879380cb0bf4ea4
https://github.com/qemu/qemu/commit/0ee520126a2a1a2539e54b6d0879380cb0bf4ea4
Author: Daniel Henrique Barboza <danielhb413@gmail.com>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/ppc/spapr.c
M hw/ppc/spapr_numa.c
M include/hw/ppc/spapr_numa.h
Log Message:
-----------
spapr, spapr_numa: move lookup-arrays handling to spapr_numa.c
In a similar fashion as the previous patch, let's move the
handling of ibm,associativity-lookup-arrays from spapr.c to
spapr_numa.c. A spapr_numa_write_assoc_lookup_arrays() helper was
created, and spapr_dt_dynamic_reconfiguration_memory() can now
use it to advertise the lookup-arrays.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200903220639.563090-4-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: dd7e1d7ae431ee61b0e59bf505fc39dc17bba24b
https://github.com/qemu/qemu/commit/dd7e1d7ae431ee61b0e59bf505fc39dc17bba24b
Author: Daniel Henrique Barboza <danielhb413@gmail.com>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/ppc/spapr_numa.c
M hw/ppc/spapr_pci_nvlink2.c
Log Message:
-----------
spapr_numa: move NVLink2 associativity handling to spapr_numa.c
The NVLink2 GPUs works like a regular NUMA node with its
own associativity values, regardless of user input.
This can be handled inside spapr_numa_associativity_init(),
initializing NVGPU_MAX_NUM associativity arrays that can
be used by the GPUs.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200903220639.563090-5-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: f8a13fc3812562ad46db1d37d9a176613731698f
https://github.com/qemu/qemu/commit/f8a13fc3812562ad46db1d37d9a176613731698f
Author: Daniel Henrique Barboza <danielhb413@gmail.com>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/ppc/spapr_hcall.c
M hw/ppc/spapr_numa.c
Log Message:
-----------
spapr: move h_home_node_associativity to spapr_numa.c
The implementation of this hypercall will be modified to use
spapr->numa_assoc_arrays input. Moving it to spapr_numa.c makes
make more sense.
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200904172422.617460-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: d370f9cf0aac54b091047392427d3d5ec93182c3
https://github.com/qemu/qemu/commit/d370f9cf0aac54b091047392427d3d5ec93182c3
Author: Daniel Henrique Barboza <danielhb413@gmail.com>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/ppc/spapr_numa.c
M include/hw/ppc/spapr.h
Log Message:
-----------
spapr_numa: create a vcpu associativity helper
The work to be done in h_home_node_associativity() intersects
with what is already done in spapr_numa_fixup_cpu_dt(). This
patch creates a new helper, spapr_numa_get_vcpu_assoc(), to
be used for both spapr_numa_fixup_cpu_dt() and
h_home_node_associativity().
While we're at it, use memcpy() instead of loop assignment
to created the returned array.
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200904172422.617460-3-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: 876ab8d89d0d288945334c8caa908b07ef847de2
https://github.com/qemu/qemu/commit/876ab8d89d0d288945334c8caa908b07ef847de2
Author: Daniel Henrique Barboza <danielhb413@gmail.com>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M hw/ppc/spapr_numa.c
Log Message:
-----------
spapr_numa: use spapr_numa_get_vcpu_assoc() in home_node hcall
The current implementation of h_home_node_associativity hard codes
the values of associativity domains of the vcpus. Let's make
it consider the values already initialized in spapr->numa_assoc_array,
via the spapr_numa_get_vcpu_assoc() helper.
We want to set it and forget it, and for that we also need to
assert that we don't overflow the registers of the hypercall.
>From R4 to R9 we can squeeze in 12 associativity domains for
vcpus, so let's assert that VCPU_ASSOC_SIZE -1 isn't greater
than that.
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200904172422.617460-4-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit: b95ba83fc56ebfc4b6869f21db0c757c0c191104
https://github.com/qemu/qemu/commit/b95ba83fc56ebfc4b6869f21db0c757c0c191104
Author: Peter Maydell <peter.maydell@linaro.org>
Date: 2020-09-08 (Tue, 08 Sep 2020)
Changed paths:
M exec.c
M hw/core/cpu.c
M hw/input/adb.c
M hw/intc/spapr_xive.c
M hw/intc/spapr_xive_kvm.c
M hw/mips/cps.c
M hw/ppc/e500.c
M hw/ppc/meson.build
M hw/ppc/pnv_bmc.c
M hw/ppc/pnv_lpc.c
M hw/ppc/ppc4xx_pci.c
M hw/ppc/spapr.c
M hw/ppc/spapr_cpu_core.c
M hw/ppc/spapr_hcall.c
M hw/ppc/spapr_irq.c
A hw/ppc/spapr_numa.c
M hw/ppc/spapr_nvdimm.c
M hw/ppc/spapr_pci.c
M hw/ppc/spapr_pci_nvlink2.c
M hw/scsi/spapr_vscsi.c
M hw/sparc/sun4m.c
M include/hw/core/cpu.h
M include/hw/ipmi/ipmi.h
M include/hw/ppc/spapr.h
M include/hw/ppc/spapr_drc.h
A include/hw/ppc/spapr_numa.h
M include/hw/ppc/spapr_nvdimm.h
M include/hw/ppc/spapr_xive.h
M target/arm/cpu.c
M target/arm/cpu.h
M target/arm/kvm32.c
M target/arm/kvm64.c
M target/s390x/cpu.c
Log Message:
-----------
Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-5.2-20200908' into
staging
ppc patch queue 2020-09-08
This supersedes ppc-for-5.2-20200904, it fixes a couple of bugs in
that PR and adds a few extra patches.
Next pull request for qemu-5.2. The biggest thing here is the
generalization of ARM's start-powered-off machine property to all
targets. This can fix a number of odd little edge cases where KVM
could run vcpus before they were properly initialized. This does
include changes to a number of files that aren't normally in my
purview. There are suitable Acked-by lines and Peter requested this
come in via my tree, since the most pressing requirement for it is in
pseries machines with the POWER secure virtual machine facility.
In addition we have:
* Daniel Barboza's rework and clean up of pseries machine NUMA handling
* Correction to behaviour of the nvdimm= generic machine property on
pseries
* An optimization to the allocation of XIVE interrupts on KVM
* Some fixes for confused behaviour with kernel_irqchip when both
XICS and XIVE are in play
* Add HIOMAP comamnd to pnv flash
* Properly advertise the fact that spapr_vscsi doesn't handle
hotplugged disks
* Some assorted minor enhancements
# gpg: Signature made Tue 08 Sep 2020 06:19:34 BST
# gpg: using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392
# gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" [full]
# gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" [full]
# gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>"
[full]
# gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>"
[unknown]
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392
* remotes/dgibson/tags/ppc-for-5.2-20200908: (33 commits)
spapr_numa: use spapr_numa_get_vcpu_assoc() in home_node hcall
spapr_numa: create a vcpu associativity helper
spapr: move h_home_node_associativity to spapr_numa.c
spapr_numa: move NVLink2 associativity handling to spapr_numa.c
spapr, spapr_numa: move lookup-arrays handling to spapr_numa.c
spapr, spapr_numa: handle vcpu ibm,associativity
spapr: introduce SpaprMachineState::numa_assoc_array
ppc/spapr_nvdimm: turn spapr_dt_nvdimm() static
ppc: introducing spapr_numa.c NUMA code helper
hw/ppc/ppc4xx_pci: Replace pointless warning by assert()
hw/ppc/ppc4xx_pci: Use ARRAY_SIZE() instead of magic value
target/s390x: Use start-powered-off CPUState property
sparc/sun4m: Use start-powered-off CPUState property
sparc/sun4m: Don't set cs->halted = 0 in main_cpu_reset()
mips/cps: Use start-powered-off CPUState property
ppc/e500: Use start-powered-off CPUState property
ppc/spapr: Use start-powered-off CPUState property
target/arm: Move setting of CPU halted state to generic code
target/arm: Move start-powered-off property to generic CPUState
ppc/spapr_nvdimm: do not enable support with 'nvdimm=off'
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Compare: https://github.com/qemu/qemu/compare/00942071a0ea...b95ba83fc56e
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] 7e26c9: adb: Correct class size on TYPE_ADB_DEVICE,
Peter Maydell <=