On Fri, Jul 12, 2024 at 7:17 AM Fabiano Rosas wrote:
>
> Yichen Wang writes:
>
> > From: Bryan Zhang
> >
> > Adds support for 'qatzip' as an option for the multifd compression
> > method parameter, and implements using QAT for 'qatzip' compression and
> > decompression.
> >
> > Signed-off-by:
On 2024/07/09 11:52, Jason Wang wrote:
On Mon, Jul 8, 2024 at 3:38 PM Akihiko Odaki wrote:
Based-on: <20240428-rss-v10-0-73cbaa91a...@daynix.com>
("[PATCH v10 00/18] virtio-net RSS/hash report fixes and improvements")
Some features are not always available, and virtio-net used to disable
Warning about RSS fallback at device realization allows the user to
notice the configuration problem early.
Signed-off-by: Akihiko Odaki
---
hw/net/virtio-net.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index
Some features are not always available, and virtio-net used to disable
them when not available even if the corresponding properties were
explicitly set to "on".
Convert feature properties to OnOffAuto so that the user can explicitly
tell QEMU to automatically select the value by setting them
If ebpf-rss-fds is specified but we fail to use, we should not fall
back to loading eBPF programs by ourselves as such makes the situation
complicated.
Suggested-by: Daniel P. Berrangé
Signed-off-by: Akihiko Odaki
---
hw/net/virtio-net.c | 24 +---
1 file changed, 9
Accept bool literals for OnOffAuto properties for consistency with bool
properties.
Signed-off-by: Akihiko Odaki
---
hw/core/qdev-properties.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
index
Some features are not always available, and virtio-net used to disable
them when not available even if the corresponding properties were
explicitly set to "on".
Convert feature properties to OnOffAuto so that the user can explicitly
tell QEMU to automatically select the value by setting them
DEFINE_PROP_ON_OFF_AUTO_BIT64() corresponds to DEFINE_PROP_ON_OFF_AUTO()
as DEFINE_PROP_BIT64() corresponds to DEFINE_PROP_BOOL(). The difference
is that DEFINE_PROP_ON_OFF_AUTO_BIT64() exposes OnOffAuto instead of
bool.
Signed-off-by: Akihiko Odaki
---
include/hw/qdev-properties.h | 18
The transfer size check was originally added to prevent consecutive DMA TI
commands from causing an assert() due to an existing SCSI request being in
progress, but since the last set of updates this is no longer required.
Remove the transfer size check from DMA DATA IN and DATA OUT transfers so
Non-active block commits do not discard blocks only containing zeros,
causing images to lose sparseness after the commit. This commit fixes
that by writing zero blocks using blk_co_pwrite_zeroes rather than
writing them out as any other arbitrary data.
Signed-off-by: Vincent Vanlaer
---
Signed-off-by: Vincent Vanlaer
---
block/commit.c | 39 ---
1 file changed, 28 insertions(+), 11 deletions(-)
diff --git a/block/commit.c b/block/commit.c
index 8dee25b313..fb54fc9560 100644
--- a/block/commit.c
+++ b/block/commit.c
@@ -128,6 +128,11 @@
bdrv_co_common_block_status_above not only returns whether the block is
allocated, but also if it contains zeroes.
Signed-off-by: Vincent Vanlaer
---
block/commit.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/block/commit.c b/block/commit.c
index
Signed-off-by: Vincent Vanlaer
---
tests/qemu-iotests/315 | 95 ++
tests/qemu-iotests/315.out | 54 ++
2 files changed, 149 insertions(+)
create mode 100755 tests/qemu-iotests/315
create mode 100644 tests/qemu-iotests/315.out
diff
This patch series adds support for zero blocks in non-active commits.
The first three patches in the series contains the actual changes to the
commit code, the last patch adds a test for the new functionality.
---
Changes since v1:
- split up the implementation in three separate commits
-
On 13/7/24 17:56, SamJakob wrote:
It is common practice when implementing double-buffering
on VideoCore to do so by multiplying the height of the
virtual buffer by the number of virtual screens desired
(i.e., two - in the case of double-bufferring).
At
On 12/7/24 13:39, Peter Maydell wrote:
The TCGCPUOps::cpu_exec_interrupt hook is currently not mandatory; if
it is left NULL then we treat it as if it had returned false. However
since pretty much every architecture needs to handle interrupts,
almost every target we have provides the hook. The
On Sat, Jul 13, 2024 at 02:43:25PM -0300, Daniel Henrique Barboza wrote:
> Commit b1f1e9dcfa renamed 'riscv,delegate' to 'riscv,delegation' since
> it is the correct name as per dt-bindings, and the absence of the
> correct name will result in validation fails when dumping the dtb and
> using
Add common function to help unregister the GDB register space. This shall be
done in context to the CPU unrealization.
Note: These are common functions exported to arch specific code. For example,
for ARM this code is being referred in associated arch specific patch-set:
Link:
Virtual CPU Hot-unplug leads to unrealization of a CPU object. This also
involves destruction of the CPU AddressSpace. Add common function to help
destroy the CPU AddressSpace.
Signed-off-by: Salil Mehta
Tested-by: Vishnu Pajjuri
Reviewed-by: Gavin Shan
Tested-by: Xianglai Li
Tested-by:
CPUs Control device(\\_SB.PCI0) register interface for the x86 arch is IO port
based and existing CPUs AML code assumes _CRS objects would evaluate to a system
resource which describes IO Port address. But on ARM arch CPUs control
device(\\_SB.PRES) register interface is memory-mapped hence _CRS
OSPM evaluates _EVT method to map the event. The CPU hotplug event eventually
results in start of the CPU scan. Scan figures out the CPU and the kind of
event(plug/unplug) and notifies it back to the guest. Update the GED AML _EVT
method with the call to method \\_SB.CPUS.CSCN (via \\_SB.GED.CSCN)
ACPI GED (as described in the ACPI 6.4 spec) uses an interrupt listed in the
_CRS object of GED to intimate OSPM about an event. Later then demultiplexes the
notified event by evaluating ACPI _EVT method to know the type of event. Use
ACPI GED to also notify the guest kernel about any CPU
[Note: References are present at the last after the revision history]
Virtual CPU hotplug support is being added across various architectures [1][3].
This series adds various code bits common across all architectures:
1. vCPU creation and Parking code refactor [Patch 1]
2. Update ACPI GED
CPU ctrl-dev MMIO region length could be used in ACPI GED and various other
architecture specific places. Move ACPI_CPU_HOTPLUG_REG_LEN macro to more
appropriate common header file.
Signed-off-by: Salil Mehta
Reviewed-by: Alex Bennée
Reviewed-by: Jonathan Cameron
Reviewed-by: Gavin Shan
KVM vCPU creation is done once during the vCPU realization when Qemu vCPU thread
is spawned. This is common to all the architectures as of now.
Hot-unplug of vCPU results in destruction of the vCPU object in QOM but the
corresponding KVM vCPU object in the Host KVM is not destroyed as KVM doesn't
Commit b1f1e9dcfa renamed 'riscv,delegate' to 'riscv,delegation' since
it is the correct name as per dt-bindings, and the absence of the
correct name will result in validation fails when dumping the dtb and
using dt-validate.
But this change has a side-effect: every other firmware available that
It is common practice when implementing double-buffering
on VideoCore to do so by multiplying the height of the
virtual buffer by the number of virtual screens desired
(i.e., two - in the case of double-bufferring).
At present, this won't work in QEMU
It is common practice when implementing double-buffering
on VideoCore to do so by multiplying the height of the
virtual buffer by the number of virtual screens desired
(i.e., two - in the case of double-bufferring).
At present, this won't work in QEMU
On 2024/07/12 2:05, Daniel P. Berrangé wrote:
On Mon, Jul 08, 2024 at 07:25:20PM +0800, junjiehua wrote:
when building elf2dump with x86_64-w64-mingw32-gcc, fwrite is imported from
msvcrt.dll. However, the implementation of msvcrt.dll!fwrite is buggy:
it enters an infinite loop when the size of
On 2024/07/10 19:52, Michael S. Tsirkin wrote:
On Wed, Jul 10, 2024 at 08:37:27AM +0200, Cédric Le Goater wrote:
Hello,
This change introduced a regression on s390x. I could have spotted it
earlier. Sorry about that. Here is the scenario,
QEMU now creates automatically the PCI device objects
This is a ping to the patch below.
https://lore.kernel.org/qemu-devel/ty0pr0101mb42850337f8917d1f514107fba4...@ty0pr0101mb4285.apcprd01.prod.exchangelabs.com/
差出人: 伊藤 太清
送信日時: 2024年7月5日 12:33
宛先: qemu-devel@nongnu.org
CC: pbonz...@redhat.com ; m...@redhat.com
Before this commit, there are 3 problems about HPET timer interrupts. First,
HPET periodic timers cause a too early interrupt before HPET main counter
value reaches a value written its comparator value register. Second,
disabled HPET timers whose comparator value register is not
0x
Thank you for reviewing.
The patch fixed by you can't solve my problem.
However, it is able to do this with minor modification.
I will send a new version patch.
差出人: Paolo Bonzini
送信日時: 2024年7月10日 19:01
宛先: TaiseiIto ; qemu-devel@nongnu.org
CC: m...@redhat.com
On 7/12/24 14:02, Nicholas Piggin wrote:
Power9/10 CPUs have PVR[51] set in small-core mode and clear in big-core
mode. This is used by skiboot firmware.
PVR is not hypervisor-privileged but it is not so important that spapr
to implement this because it's generally masked out of PVR matching
On 7/12/24 14:02, Nicholas Piggin wrote:
Power CPUs have an execution control facility that can pause, resume,
and cause NMIs, among other things. Add a function that will nmi a CPU
and resume it if it was paused, in preparation for implementing the
control facility.
Signed-off-by: Nicholas
On 7/12/24 14:02, Nicholas Piggin wrote:
Recent POWER CPUs can operate in "LPAR per core" or "LPAR per thread"
modes. In per-core mode, some SPRs and IPI doorbells are shared between
threads in a core. In per-thread mode, supervisor and user state is
not shared between threads.
OpenPOWER
On 7/12/24 14:02, Nicholas Piggin wrote:
Big-core implementation is complete, so expose it as a machine
property that may be set with big-core=on option on powernv9 and
powernv10 machines.
Signed-off-by: Nicholas Piggin
---
hw/ppc/pnv.c | 62
On 7/12/24 14:02, Nicholas Piggin wrote:
POWER10 has a quirk in its ChipTOD addressing that requires the even
small-core to be selected even when programming the odd small-core.
This allows skiboot chiptod init to run in big-core mode.
Signed-off-by: Nicholas Piggin
Looks good, some more
On 7/12/24 14:02, Nicholas Piggin wrote:
POWER9 and POWER10 machines come in two variants, big-core and
small-core. Big-core machines are SMT8 from software's point of view,
but the low level platform topology ("xscom registers and pervasive
addressing"), these look more like a pair of small
On 7/12/24 18:27, Philippe Mathieu-Daudé wrote:
Tag to test Aspeed tree:
https://gitlab.com/philmd/qemu/-/tags/aspeed_emmc-v9
Updated aspeed9.1 branch. LGTM.
Thanks,
C.
Since v48:
- Dropped "Implement 'boot-mode' reset timing" patch
- Re-introduce Joel "Support boot area in emmc image"
40 matches
Mail list logo
