Hi,
On 2/17/25 5:37 PM, Kashyap Chamarthy wrote:
> This is based on Peter's suggestion here[1].
>
> I simply addrressed the occurrences that I found with `git grep "ARM "`
adressed
> in the docs/ directory. I didn't touch stuff like these "StrongARM",
> ARM926EJ-S, ARM1176JZS, etc. Related com
On 2/17/25 5:37 PM, Kashyap Chamarthy wrote:
> Signed-off-by: Kashyap Chamarthy
Reviewed-by: Eric Auger
Eric
> ---
> docs/system/arm/cpu-features.rst | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/docs/system/arm/cpu-features.rst
> b/docs/sy
On 2/17/25 18:22, Alex Bennée wrote:
...
>> This VK_KHR_display problem is only reproducible with your rootfs that
>> you shared with me. It could be a trouble with your build configs or a
>> buggy package version used by your rootfs build, more likely the
>> former.
> So you have built that latest
On 2/14/25 15:13, Steve Sistare wrote:
Replace the proliferation of exit labels in vfio_connect_container with
conditionals for cleaning each piece of state. No functional change.
Signed-off-by: Steve Sistare
Reviewed-by: Cédric Le Goater
Thanks,
C.
---
hw/vfio/container.c | 61
Am 3. Februar 2025 05:42:55 UTC schrieb Dmitriy Sharikhin
:
>At Sun, 02/02/2025 at 18:09 +0100, Philippe Mathieu-Daudé writes:
>> No clue about compatibility. If you unfortunately need to add it,
>> then please address my comments in the next version.
>TCA6416 is _way_ more complex device than
On 2/17/25 04:50, Peter Maydell wrote:
Currently we hardcode at compile time whether the floatx80 default
Infinity value has the explicit integer bit set or not (x86 sets it;
m68k does not). To be able to compile softfloat once for all targets
we'd like to move this setting to runtime.
Define a
On 2/14/25 15:13, Steve Sistare wrote:
Add vfio_container_group_add to de-dup some code. No functional change.
Signed-off-by: Steve Sistare
Reviewed-by: Cédric Le Goater
Thanks,
C.
---
hw/vfio/container.c | 47 +--
1 file changed, 25 inse
Investigate the git history to uncover when and why the VFIO
properties were introduced and update the models. This is mostly
targeting vfio-pci device, since vfio-platform, vfio-ap and vfio-ccw
devices are simpler.
Sort the properties based on the QEMU version in which they were
introduced.
Cc:
On 2/17/25 04:50, Peter Maydell wrote:
In Intel terminology, a floatx80 Infinity with the explicit integer
bit clear is a "pseudo-infinity"; for x86 these are not valid
infinity values. m68k is looser and does not care whether the
Integer bit is set or clear in an infinity.
Move this setting to
On 2/17/25 04:50, Peter Maydell wrote:
The global const floatx80_infinity is (unlike all the other
float*_infinity values) target-specific, because whether the explicit
Integer bit is set or not varies between m68k and i386. We want to
be able to compile softfloat once for multiple targets, so w
On Sat, Feb 15, 2025 at 6:36 PM Michael Tokarev wrote:
> This looks like a qemu-stable material. Please let me know if it is not.
Yes, that makes sense. Thanks Michael.
Paolo
On 26/1/25 22:16, Richard Henderson wrote:
On 1/23/25 15:44, Philippe Mathieu-Daudé wrote:
CPU_INTERRUPT_EXIT was removed in commit 3098dba01c7
("Use a dedicated function to request exit from execution
loop"), tlb_flush() and tb_flush() are related to TCG
accelerator.
Signed-off-by: Philippe Ma
On 2/17/25 12:03, Zhao Liu wrote:
Hi Paolo,
--- a/hw/timer/Kconfig
+++ b/hw/timer/Kconfig
@@ -11,7 +11,7 @@ config A9_GTIMER
config HPET
bool
-default y if PC
+default y if PC && !HAVE_RUST
+
+config X_HPET_RUST
+bool
+default y if PC && HAVE_RUST
config I8254
Hi Tom,
On Sun, 16 Feb 2025 at 14:57, Tom Rini wrote:
>
> On Sun, Feb 16, 2025 at 01:43:45PM -0700, Simon Glass wrote:
>
> > U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it
> > is not perfect.
> >
> > With both builds, executing the VESA ROM causes an intermittent hang, at
cpu_memory_rw_debug() system implementation is defined in
system/physmem.c. Move the user one to accel/tcg/user-exec.c
to simplify cpu-target.c maintenance.
Signed-off-by: Philippe Mathieu-Daudé
---
accel/tcg/user-exec.c | 80 ++
cpu-target.c | 90 +--
On 17/2/25 00:09, Richard Henderson wrote:
Even though bswap64 can only be used with TCG_TYPE_I64,
rename the opcode to maintain uniformity.
Signed-off-by: Richard Henderson
---
include/tcg/tcg-opc.h| 3 +--
tcg/optimize.c | 6 +++---
tcg/tcg-op.c | 4 ++--
tcg/tc
On 17/2/25 13:50, Peter Maydell wrote:
Currently we have a compile-time shortcut where we return a hardcode
value from snan_bit_is_one() on everything except MIPS, because we
know that's the only target that needs to change
status->no_signaling_nans at runtime.
Remove the ifdef, so we always loo
It is possible to start QEMU with a confidential-guest-support object
even in TCG mode. While there is already a check in qemu_machine_creation_done:
if (machine->cgs && !machine->cgs->ready) {
error_setg(errp, "accelerator does not support confidential guest %s",
o
On Mon, Feb 17, 2025 at 04:17:27PM +0800, Yong-Xuan Wang wrote:
> The riscv-aia property only controls the in-kernel IMSIC mode, the
> emulation of AIA MSI mode is controlled by the kernel-irqchip property.
> Rename the riscv-aia property to riscv-imsic to prevent the confusion.
>
> Signed-off-by:
On Wed, Feb 12, 2025 at 12:29:58PM +0100, Philippe Mathieu-Daudé wrote:
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> meson.build | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/meson.build b/meson.build
> index 18cf9e2913b..10f4c9fd30d 100644
> --- a/meson.build
> +++ b/meson.
Currently we hardcode at compile time whether the floatx80 default
Infinity value has the explicit integer bit set or not (x86 sets it;
m68k does not). To be able to compile softfloat once for all targets
we'd like to move this setting to runtime.
Define a new FloatX80Behaviour enum which is a se
The global const floatx80_infinity is (unlike all the other
float*_infinity values) target-specific, because whether the explicit
Integer bit is set or not varies between m68k and i386. We want to
be able to compile softfloat once for multiple targets, so we can't
continue to use a single global w
Currently we compile-time set an 'm68k_denormal' flag in the FloatFmt
for floatx80 for m68k. This controls our handling of what the Intel
documentation calls a "pseudo-denormal": a value where the exponent
field is zero and the explicit integer bit is set.
For x86, the x87 FPU is supposed to acce
We happen to know that for the PPC target the FP status flags (and in
particular float_flag_inexact) will always be cleared before a
floating point operation, and so can_use_fpu() will always return
false. So we speed things up a little by forcing QEMU_NO_HARDFLOAT
to true on that target.
We woul
Now we have removed all the target-specifics from the softfloat code,
we can switch to building it once for the whole system rather than
once per target.
Signed-off-by: Peter Maydell
---
fpu/softfloat.c | 3 ---
fpu/meson.build | 2 +-
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git
Currently we have a compile-time shortcut where we return a hardcode
value from snan_bit_is_one() on everything except MIPS, because we
know that's the only target that needs to change
status->no_signaling_nans at runtime.
Remove the ifdef, so we always look at the status flag. This means
we must
Currently we have a compile-time shortcut where we
return false from no_signaling_nans() on everything except
Xtensa, because we know that's the only target that
might ever set status->no_signaling_nans.
Remove the ifdef, so we always look at the status flag;
this has no behavioural change, but wi
The work I needed to do to make various softfloat emulation behaviours
runtime-selectable for Arm FEAT_AFP has left the fpu code with very
few remaning target ifdefs. So this series turns the last remaning
ones into runtime behaviour choices and switches the fpu code into
"build once" rather than "
On Mon, Feb 17, 2025 at 1:28 PM Philippe Mathieu-Daudé
wrote:
> qemu-system-x86_64 -m 512 -nographic -object
sev-snp-guest,reduced-phys-bits=48,id=sev0 \
> -M q35,kernel-irqchip=split,confidential-guest-support=sev0
> qemu-system-x86_64: ../system/physmem.c:1871: ram_block
The global const floatx80_infinity is (unlike all the other
float*_infinity values) target-specific, because whether the explicit
Integer bit is set or not varies between m68k and i386. We want to
be able to compile softfloat once for multiple targets, so we can't
continue to use a single global w
Currently the iommu may be reset before the devices
it protects. For example this happens with virtio-scsi-pci.
when system_reset is issued from qmp monitor: spurious
"virtio: zero sized buffers are not allowed" warnings can
be observed. This happens because outstanding DMA requests
are still happe
Currently the IOMMU may be reset before the devices
it protects. For example this happens with virtio devices
but also with VFIO devices. In this latter case this
produces spurious translation faults on host.
Let's use 3-phase reset mechanism and reset the IOMMU on
exit phase after all DMA capable
To ease the debug of reset sequence, let's add a trace point
in vfio_reset_handler()
Signed-off-by: Eric Auger
Reviewed-by: Cédric Le Goater
Acked-by: Michael S. Tsirkin
---
hw/vfio/common.c | 1 +
hw/vfio/trace-events | 1 +
2 files changed, 2 insertions(+)
diff --git a/hw/vfio/common.c
To avoid any translation faults, the IOMMUs are expected to be
reset after the devices they protect. Document that we expect
DMA requests to be stopped during the 'enter' or 'hold' phase
while IOMMUs should be reset during the 'exit' phase.
Signed-off-by: Eric Auger
---
docs/devel/reset.rst | 5
On Tue, 4 Feb 2025 at 09:21, Bernhard Beschow wrote:
>
> Linux checks for the PLLs in the PHY to be locked, so implement a model
> emulating that.
>
> Signed-off-by: Bernhard Beschow
> ---
> +static const VMStateDescription fsl_imx8m_pcie_phy_vmstate = {
> +.name = "fsl-imx8m-pcie-phy",
> +
Queued, thanks.
Paolo
Dmitry Osipenko writes:
> On 1/27/25 19:17, Alex Bennée wrote:
>> Dmitry Osipenko writes:
>>
>>> This patchset adds DRM native context support to VirtIO-GPU on Qemu.
>>>
>>> Contarary to Virgl and Venus contexts that mediates high level GFX APIs,
>>> DRM native context [1] mediates lower level
On 2/14/25 15:13, Steve Sistare wrote:
Define a helper to set ram discard disable, generate error messages,
and cleanup on failure. The second vfio_ram_block_discard_disable
call site now performs VFIO_GROUP_UNSET_CONTAINER immediately on failure,
instead of relying on the close of the container
On Mon, 17 Feb 2025 at 16:38, Kashyap Chamarthy wrote:
>
> Signed-off-by: Kashyap Chamarthy
> ---
> docs/system/arm/cpu-features.rst | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
Reviewed-by: Peter Maydell
thanks
-- PMM
On 17/2/25 15:39, Peter Maydell wrote:
On Mon, 17 Feb 2025 at 14:27, Peter Maydell wrote:
On Sat, 8 Feb 2025 at 16:39, Philippe Mathieu-Daudé wrote:
Signed-off-by: Philippe Mathieu-Daudé
---
hw/char/pl011.c | 4 +++-
hw/char/trace-events | 2 ++
2 files changed, 5 insertions(+), 1
Yes, good point, Philippe!
I will send an update in a few days in case there are additional
changes to be made.
thank you,
---
dan tan
power simulation
phone:+1.7373.099.138
email:dan...@linux.ibm.com
On 2025-02-17 01:31, Philippe Mathieu-Daudé wrote:
Hi,
On 16/2/25 23:11, dan tan wrote:
Im
Dmitry Osipenko writes:
> On 2/14/25 17:33, Alex Bennée wrote:
>> Dmitry Osipenko writes:
>>
>>> This patchset adds DRM native context support to VirtIO-GPU on Qemu.
>>>
>>> Contarary to Virgl and Venus contexts that mediates high level GFX APIs,
>>> DRM native context [1] mediates lower level
On Tue, 11 Feb 2025 at 10:46, Peter Maydell wrote:
>
> (added qemu-devel to the cc list)
>
> On Mon, 10 Feb 2025 at 17:26, Stu Grossman wrote:
> >
> > I've been getting SIGBUS cores with a bunch of user apps running under
> > linux 5.15 and qemu-system-aarch64. These happen to be 32 bit (T32?)
>
On 17/2/25 13:50, Peter Maydell wrote:
Currently we have a compile-time shortcut where we
return false from no_signaling_nans() on everything except
Xtensa, because we know that's the only target that
might ever set status->no_signaling_nans.
Remove the ifdef, so we always look at the status fla
On Fri, Feb 14, 2025 at 09:29:33PM +0100, Victor Toso wrote:
> Hi again,
>
> This patch series intent is to introduce a generator that produces a Go
> module for Go applications to interact over QMP with QEMU.
>
> Previous version (10 Jan 2025)
> https://lists.gnu.org/archive/html/qemu-devel/
Use virtio_get_config_size() rather than sizeof(struct
virtio_snd_config) for the config_size in the vhost-user-snd frontend.
The frontend shall rely on device features for the size of the device
configuration space. The presence of `controls` in the config space
depends on VIRTIO_SND_F_CTLS accord
CPU_RESOLVING_TYPE is declared per target in "cpu.h". Include
it (along with "qom/object.h") to avoid when moving code around:
include/accel/accel-cpu-target.h:26:50: error: expected ')'
26 | DECLARE_CLASS_CHECKERS(AccelCPUClass, ACCEL_CPU, TYPE_ACCEL_CPU)
|
We checked the page flags with page_get_flags(), so
locking the page is superfluous. Remove the lock_user()
calls and directly use g2h() in place.
Suggested-by: Richard Henderson
Signed-off-by: Philippe Mathieu-Daudé
---
cpu-target.c | 17 ++---
1 file changed, 2 insertions(+), 15 d
Commit 35c653c4029 ("tcg: Add 128-bit guest memory
primitives") introduced the use of bswap128() which is
declared in "qemu/int128.h", commit de95016dfbf ("accel/tcg:
Implement helper_{ld,st}*_mmu for user-only") introduced the
other bswap*() uses, which are declared in "qemu/bswap.h".
Include the
On Thu, 13 Feb 2025 at 08:44, Kashyap Chamarthy wrote:
>
> In v2:
>
> - Add live-migration context to the PAuth docs (Marc Zyngier)
>
> - Fix the Arm capitlalization (Peter Maydell)
> - Context here:
> (https://lists.gnu.org/archive/html/qemu-devel/2025-01/msg05137.html)
> Kashyap
In Intel terminology, a floatx80 Infinity with the explicit integer
bit clear is a "pseudo-infinity"; for x86 these are not valid
infinity values. m68k is looser and does not care whether the
Integer bit is set or clear in an infinity.
Move this setting to runtime rather than using an ifdef in
fl
Prasad Pandit writes:
> From: Prasad Pandit
>
> Migration capabilities are set in multiple '.start_hook'
> functions for various tests. Instead, consolidate setting
> capabilities in 'set_migration_capabilities()' function
> which is called from various 'test_*_common()' functions.
> While simpl
On Mon, Feb 17, 2025 at 04:17:24PM +0800, Yong-Xuan Wang wrote:
> Add a helper function to get CSR name from CSR number.
>
> Signed-off-by: Yong-Xuan Wang
> ---
> target/riscv/cpu.h | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/target/riscv/cpu.h b/target/riscv/c
Because floatx80 has an explicit integer bit, this permits some
odd encodings where the integer bit is not set correctly for the
floating point value type. In In Intel terminology the
categories are:
exp == 0, int = 0, mantissa == 0 : zeroes
exp == 0, int = 0, mantissa != 0 : denormals
exp =
On Tue, 4 Feb 2025 at 09:21, Bernhard Beschow wrote:
>
> While at it and since they are user-creatable, build them when
> CONFIG_I2C_DEVICES is set.
The patch subject says this is just a rearrangement
of the Kconfig stanzas with no behaviour change, but then the
commit message body includes one.
On Tue, 4 Feb 2025 at 09:21, Bernhard Beschow wrote:
>
> On the real device, the PCIe root bus is only connected to a PCIe bridge and
> does not allow for direct attachment of devices. Doing so in QEMU results in
> no
> PCI devices being detected by Linux. Instead, PCI devices should plug into th
Currently the iommu may be reset before the devices
it protects. For example this happens with virtio-net.
Let's use 3-phase reset mechanism and reset the IOMMU on
exit phase after all DMA capable devices have been
reset during the 'enter' or 'hold' phase.
Signed-off-by: Eric Auger
Acked-by: Mic
With current reset scheme, DMA capable devices are reset before
the vIOMMU which translate them. This holds for the different
IOMMUs and various DMA capable devices such as virtio devices
and VFIO ones. With virtio devices spurious traces can be
observed at qemu level such as "virtio: zero sized bu
On Mon, Feb 17, 2025 at 06:14:12AM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Sun, 16 Feb 2025 at 14:57, Tom Rini wrote:
> >
> > On Sun, Feb 16, 2025 at 01:43:45PM -0700, Simon Glass wrote:
> >
> > > U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it
> > > is not perfect.
> >
On Sat, 8 Feb 2025 at 16:39, Philippe Mathieu-Daudé wrote:
>
> If the UART back-end chardev doesn't drain data as fast as stdout
> does or blocks, buffer in the TX FIFO to try again later.
>
> This avoids having the IO-thread busy waiting on chardev back-ends,
> reported recently when testing the
On Thu, Feb 13, 2025 at 04:55:13PM -0800, Sean Christopherson wrote:
> On Thu, Feb 13, 2025, Kim Phillips wrote:
> > On 2/11/25 3:46 PM, Sean Christopherson wrote:
> > > On Mon, Feb 10, 2025, Tom Lendacky wrote:
> > > > On 2/7/25 17:34, Kim Phillips wrote:
>
> Third, letting userspace opt-in to so
On Mon, 17 Feb 2025 at 14:27, Peter Maydell wrote:
>
> On Sat, 8 Feb 2025 at 16:39, Philippe Mathieu-Daudé wrote:
> >
> > Signed-off-by: Philippe Mathieu-Daudé
> > ---
> > hw/char/pl011.c | 4 +++-
> > hw/char/trace-events | 2 ++
> > 2 files changed, 5 insertions(+), 1 deletion(-)
> >
> >
On Mon, 17 Feb 2025 at 15:35, Peter Maydell wrote:
> /* If changing this, update the docs for highmem-mmio-size */
> #define DEFAULT_HIGH_PCIE_MMIO_SIZE_GB 512
> #define DEFAULT_HIGH_PCIE_MMIO_SIZE (DEFAULT_HIGH_PCIE_MMIO_SIZE_GB * GiB)
>
> and use it in the definition of extended_memmap[] and in
On Sat, 8 Feb 2025 at 16:39, Philippe Mathieu-Daudé wrote:
>
> Hi,
>
> This series add support for (async) FIFO on the transmit path
> of the PL011 UART.
>
Applied to target-arm.next, thanks (with a couple of minor
tweaks to two of the patches).
-- PMM
On Fri, Feb 14, 2025 at 09:29:33PM +0100, Victor Toso wrote:
> Hi again,
>
> This patch series intent is to introduce a generator that produces a Go
> module for Go applications to interact over QMP with QEMU.
>
> Previous version (10 Jan 2025)
> https://lists.gnu.org/archive/html/qemu-devel/
Creates and supports a GPA->IOVA tree and a partial IOVA->HVA tree by
splitting up guest-backed memory maps and host-only memory maps from the
full IOVA->HVA tree. That is, any guest-backed memory maps are now
stored in the GPA->IOVA tree and host-only memory maps stay in the
IOVA->HVA tree.
Also
Creates and supports an IOVA-only tree to support a SVQ IOVA->HVA and
GPA->IOVA tree for host-only and guest-backed memory, respectively, in
the next patch.
The IOVA allocator still allocates an IOVA range but now adds this range
to the IOVA-only tree as well as to the full IOVA->HVA tree.
In the
An issue arises from aliased memory mappings in the guest, where
different GPAs map to the same HVA. For example:
- GPA1->HVA1
- GPA2->HVA1
When these mappings exist in the IOVA->HVA tree, a lookup by an HVA
backed by guest memory results in ambiguities because the same HVA could
correspond to
Minor update to some of the documentation / comments in
hw/virtio/vhost-iova-tree.c.
Signed-off-by: Jonah Palmer
Reviewed-by: Eugenio Pérez
Tested-by: Lei Yang
---
hw/virtio/vhost-iova-tree.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/hw/virtio
On Mon, 17 Feb 2025 at 14:29, Peter Maydell wrote:
>
> On Sat, 8 Feb 2025 at 16:39, Philippe Mathieu-Daudé wrote:
> >
> > When transmission is disabled, characters are still queued
> > to the FIFO which eventually overruns. Report that error
> > condition in the status register.
> >
> > Signed-of
On 17/2/25 15:52, Peter Maydell wrote:
On Mon, 17 Feb 2025 at 14:29, Peter Maydell wrote:
On Sat, 8 Feb 2025 at 16:39, Philippe Mathieu-Daudé wrote:
When transmission is disabled, characters are still queued
to the FIFO which eventually overruns. Report that error
condition in the status re
On 5/2/25 05:03, Richard Henderson wrote:
Since 64-on-32 is now unsupported, guest addresses always
fit in one host register. Drop the replication of opcodes.
Signed-off-by: Richard Henderson
---
include/tcg/tcg-opc.h| 28 ++--
tcg/optimize.c | 21 ++
The configuration option of Rust HPET is missing, so that PC machine
can't boot with "hpet=on" when QEMU Rust support is enabled.
Add the Rust HPET configuration option.
Fixes: d128c341a744 ("i386: enable rust hpet for pc when rust is enabled")
Signed-off-by: Zhao Liu
---
hw/timer/Kconfig | 4 +
Prasad Pandit writes:
> From: Prasad Pandit
>
> Add new qtests to run postcopy migration with multifd
> channels enabled.
>
> Signed-off-by: Prasad Pandit
> ---
> tests/qtest/migration/compression-tests.c | 13
> tests/qtest/migration/framework.c | 4 +++
> tests/qtest/migrat
On Wed, 12 Feb 2025 at 15:43, Philippe Mathieu-Daudé wrote:
>
> Some boards based on Cortex-A9MP / Cortex-A15MP do not explicit
> the number of external GIC IRQs, using some (implicit) default value,
> not always trivial to figure out. Change that by removing the default
> value, requiring MPCore
Hi Kashyap,
On 2/17/25 5:37 PM, Kashyap Chamarthy wrote:
> PAuth (Pointer Authentication), a security feature in software, is
> relevant for both KVM and QEMU. Relect this fact into the docs:
>
> - For KVM, `pauth` is a binary, "on" vs "off" option. The host CPU
> will choose the cryptogr
On 17.02.2025 14:57, Cédric Le Goater wrote:
On 2/14/25 21:56, Maciej S. Szmigiero wrote:
On 12.02.2025 18:10, Cédric Le Goater wrote:
On 1/30/25 11:08, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
This property allows configuring at runtime whether to transfer the
particular devic
On Sat, 8 Feb 2025 at 16:39, Philippe Mathieu-Daudé wrote:
>
> Extract pl011_xmit() from pl011_write_txdata(). Use the
> FIFO to pass the character to be transmitted.
>
> Implement it using the FEWatchFunc prototype, since we want
> to register it as GSource later. While the return value is
> not
On 16/2/25 01:00, Richard Henderson wrote:
These should have been removed with the rest. There are
a couple of hosts which can emit guest_base into the
constant pool: aarch64, mips64, ppc64, riscv64.
Fixes: a417ef835058 ("tcg: Remove TCG_TARGET_NEED_LDST_LABELS and
TCG_TARGET_NEED_POOL_LABELS"
On Sat, 8 Feb 2025 at 16:39, Philippe Mathieu-Daudé wrote:
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/char/pl011.c | 4 +++-
> hw/char/trace-events | 2 ++
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/hw/char/pl011.c b/hw/char/pl011.c
> index b9c9e5b5983..447
On Mon, Feb 17, 2025 at 02:12:55PM +0100, Matias Ezequiel Vara Larsen wrote:
Use virtio_get_config_size() rather than sizeof(struct
virtio_snd_config) for the config_size in the vhost-user-snd frontend.
The frontend shall rely on device features for the size of the device
configuration space. The
On Sat, 8 Feb 2025 at 16:39, Philippe Mathieu-Daudé wrote:
>
> When no character backend is connected, the PL011 frontend
> just drains the FIFO.
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Peter Maydell
thanks
-- PMM
On Sat, 8 Feb 2025 at 16:39, Philippe Mathieu-Daudé wrote:
>
> When transmission is disabled, characters are still queued
> to the FIFO which eventually overruns. Report that error
> condition in the status register.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/char/pl011.c | 20 +++
On 17/2/25 14:49, Daniel P. Berrangé wrote:
The 'qapi.backend.QAPIBackend' class defines an API contract for
code generators. The current generator is put into a new class
'qapi.backend.QAPICBackend' and made to be the default impl.
A custom generator can be requested using the '-k' arg which ta
Address Richard' suggestions from [*], cleaning
cpu_memory_rw_debug() user implementation.
branch: https://gitlab.com/philmd/qemu/-/commits/user_cpu_memory_rw_debug
Based-on: <20250123234415.59850-14-phi...@linaro.org>
[*] https://lore.kernel.org/qemu-devel/20250123234415.59850-1-phi...@linaro.or
On Thu, 6 Feb 2025 at 22:12, Hao Wu wrote:
>
> Changes since v3:
>
> 1. Removed REGS_END constants according to code review.
> 2. Added a few asserts according to code review.
> 3. A few minor style changes.
>
> Changes since v2:
>
> 1. Update doc to include npcm845-evb description
> 2. Add g_asse
On 2/14/25 21:56, Maciej S. Szmigiero wrote:
On 12.02.2025 18:10, Cédric Le Goater wrote:
On 1/30/25 11:08, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
This property allows configuring at runtime whether to transfer the
particular device state via multifd channels when live migrati
This is based on Peter's suggestion here[1].
I simply addrressed the occurrences that I found with `git grep "ARM "`
in the docs/ directory. I didn't touch stuff like these "StrongARM",
ARM926EJ-S, ARM1176JZS, etc. Related commit[2].
[1] https://lists.gnu.org/archive/html/qemu-devel/2025-01/msg
Signed-off-by: Kashyap Chamarthy
---
docs/system/arm/cpu-features.rst | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/docs/system/arm/cpu-features.rst b/docs/system/arm/cpu-features.rst
index 37d5dfd15b..a596316384 100644
--- a/docs/system/arm/cpu-featur
PAuth (Pointer Authentication), a security feature in software, is
relevant for both KVM and QEMU. Relect this fact into the docs:
- For KVM, `pauth` is a binary, "on" vs "off" option. The host CPU
will choose the cryptographic algorithm.
- For TCG, however, along with `pauth`, a couple
[
Resending v2, Peter pointed out that only patches 1 and 2 made it to
the list; so I'm re-sending with a commit message touch-up:
s/capitalization/capitaliaztion.
Alex Bennée reviewed the first two patches that did show up:
- https://lists.nongnu.org/archive/html/qemu-devel/20
Am 17. Februar 2025 13:40:48 UTC schrieb Peter Maydell
:
>On Tue, 4 Feb 2025 at 09:21, Bernhard Beschow wrote:
>>
>> Linux checks for the PLLs in the PHY to be locked, so implement a model
>> emulating that.
>>
>> Signed-off-by: Bernhard Beschow
>> ---
>
>> +static const VMStateDescription fs
Add GET_SHMEM_CONFIG vhost-user frontend
message to the spec documentation.
Reviewed-by: Alyssa Ross
Signed-off-by: Albert Esteve
---
docs/interop/vhost-user.rst | 39 +
1 file changed, 39 insertions(+)
diff --git a/docs/interop/vhost-user.rst b/docs/interop
Add SHMEM_MAP/UNMAP requests to vhost-user to
handle VIRTIO Shared Memory mappings.
This request allows backends to dynamically map
fds into a VIRTIO Shared Memory Region indentified
by its `shmid`. The map is performed by calling
`memory_region_init_ram_from_fd` and adding the
new region as a sub
Add a shmem BAR block in the vhost-user-device,
which files can be directly mapped into.
The number, shmid, and size of the VIRTIO Shared
Memory subregions is retrieved through a
get_shmem_config message sent by the
vhost-user-base module on the realize step,
after virtio_init().
By default, if V
Add missing members to the VhostUserMsg excerpt in
the vhost-user spec documentation.
Signed-off-by: Albert Esteve
---
docs/interop/vhost-user.rst | 4
1 file changed, 4 insertions(+)
diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst
index 2e50f2ddfa..436a94c0ee 100644
Add SHMEM_MAP/_UNMAP request to the vhost-user
spec documentation.
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Albert Esteve
---
docs/interop/vhost-user.rst | 34 ++
1 file changed, 34 insertions(+)
diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-u
With SHMEM_MAP messages, sharing descriptors between
devices will cause that these devices do not see the
mappings, and fail to access these memory regions.
To solve this, introduce MEM_READ/WRITE requests
that will get triggered as a fallback when
vhost-user memory translation fails.
MEM_READ/WR
On Mon, 17 Feb 2025 at 16:38, Kashyap Chamarthy wrote:
>
> This is based on Peter's suggestion here[1].
>
> I simply addrressed the occurrences that I found with `git grep "ARM "`
> in the docs/ directory. I didn't touch stuff like these "StrongARM",
> ARM926EJ-S, ARM1176JZS, etc. Related commit
The frontend can use this command to retrieve
VirtIO Shared Memory Regions configuration from
the backend. The response contains the number of
shared memory regions, their size, and shmid.
This is useful when the frontend is unaware of
specific backend type and configuration,
for example, in the `
1 - 100 of 311 matches
Mail list logo
