Using qom-list and qom-get to get all the nodes and property values in a
QOM tree can take multiple seconds because it requires 1000's of individual
QOM requests. Some managers fetch the entire tree or a large subset
of it when starting a new VM, and this cost is a substantial fraction of
start up
Currently, when a migration of a VM with an encrypted vTPM
fails on the destination host (e.g., due to a mismatch in secret values),
the error message displayed on the source host is generic and unhelpful.
For example, a typical error looks like this:
"operation failed: job 'migration out' failed:
Hello Kane,
On 6/30/25 07:17, Kane Chen wrote:
From: Kane-Chen-AS
This patch series introduces a QEMU model for the ASPEED OTP (One-Time
Programmable) memory, along with its integration into the Secure Boot
Controller (SBC) and supported SoC (AST2600).
The OTP model emulates a simple fuse arr
From: Kane-Chen-AS
This patch series introduces a QEMU model for the ASPEED OTP (One-Time
Programmable) memory, along with its integration into the Secure Boot
Controller (SBC) and supported SoC (AST2600).
The OTP model emulates a simple fuse array used for secure boot or
device configuration, i
This series enhances Xilinx ZynqMP support to allow booting on RPUs.
It was validated with home-made binaries. FreeRTOS was tested but without
success: outputs/IRQ seems broken. AFAICT, FreeRTOS is expecting Xilinx's
QEMU thus I didn't investigate further. I'd still like advice on the 3rd
patch ("
Hi,
New version where typos in patch 1 were fixed. No other changes made.
All patches acked.
Changes from v2:
- patch 1
- fixed typos dince -> since and specd -> spec
- v2 link:
https://lore.kernel.org/qemu-riscv/20250604174329.1147549-1-dbarb...@ventanamicro.com/
Daniel Henrique Barboza (3)
Am 03.06.2025 um 16:25 hat Markus Armbruster geschrieben:
> More than a year ago, Daniel posted patches to put an AI policy in
> writing. Reception was mostly positive. A v2 to address feedback
> followed with some delay. But no pull request.
>
> I asked Daniel why, and he told me he was concer
More than a year ago, Daniel posted patches to put an AI policy in
writing. Reception was mostly positive. A v2 to address feedback
followed with some delay. But no pull request.
I asked Daniel why, and he told me he was concerned it might go too
far in its interpretation of the DCO requirement
On 5/2/25 16:22, Steve Sistare wrote:
Cleanup a few vfio functions prior to the introduction of CPR.
These were extracted from
https://lore.kernel.org/qemu-devel/1739542467-226739-1-git-send-email-steven.sist...@oracle.com/
Changes in V3:
* update to master
Steve Sistare (3):
vfio/co
Cleanup a few vfio functions prior to the introduction of CPR.
These were extracted from
https://lore.kernel.org/qemu-devel/1739542467-226739-1-git-send-email-steven.sist...@oracle.com/
Changes in V3:
* update to master
Steve Sistare (3):
vfio/container: ram discard disable helper
vfio
From: Kane-Chen-AS
Dear reviewers,
This patch series introduces a new model for the ASPEED OTP (One-Time
Programmable) memory and integrates it with the ASPEED Secure Boot
Controller (SBC) and SoC models such as AST1030 and AST2600.
The OTP memory is implemented as a QEMU device (`aspeed.otpmem
DIAG 308 (subcode 10 - performing secure execution unpack) response
code when the configuration is unable to enter secure mode has limited
usability as it is a fixed value (0xa02) for variety of different
reasons. The aim is to extend this DIAG to return UVC command ID, RC
and RRC values in additio
On Fri, 2025-04-11 at 16:28 -0600, Alex Williamson wrote:
> > >
--- snip ---
> > > Cc: folks related to that commit.
> > >
> > > The original issue that brought us ram_device was a very obscure
> > > alignment of a memory region versus a device quirk only seen with
> > > assignment of specific RT
On 4/11/2025 3:28 PM, Alex Williamson wrote:
On Thu, 10 Apr 2025 09:07:51 -0700
Farhan Ali wrote:
On 4/3/2025 2:24 PM, Alex Williamson wrote:
On Thu, 3 Apr 2025 13:33:17 -0700
Farhan Ali wrote:
On 4/3/2025 11:05 AM, Alex Williamson wrote:
On Thu, 3 Apr 2025 10:33:52 -0700
Farhan Ali
On Thu, 10 Apr 2025 09:07:51 -0700
Farhan Ali wrote:
> On 4/3/2025 2:24 PM, Alex Williamson wrote:
> > On Thu, 3 Apr 2025 13:33:17 -0700
> > Farhan Ali wrote:
> >
> >> On 4/3/2025 11:05 AM, Alex Williamson wrote:
> >>> On Thu, 3 Apr 2025 10:33:52 -0700
> >>> Farhan Ali wrote:
> >>>
> >
On 4/3/2025 2:24 PM, Alex Williamson wrote:
On Thu, 3 Apr 2025 13:33:17 -0700
Farhan Ali wrote:
On 4/3/2025 11:05 AM, Alex Williamson wrote:
On Thu, 3 Apr 2025 10:33:52 -0700
Farhan Ali wrote:
On 4/3/2025 9:27 AM, Alex Williamson wrote:
On Thu, 3 Apr 2025 11:44:42 -0400
Stefan Hajnocz
QE tested this series v3 with virtio-net regression tests, everything works
fine.
Tested-by: Lei Yang
On Thu, Mar 27, 2025 at 2:46 PM Haoqian He wrote:
> At the end of the VM live migration, the vhost device will be stopped.
> Currently, if the vhost-user backend crashes, vhost device's set_st
On Thu, 3 Apr 2025 10:33:52 -0700
Farhan Ali wrote:
> On 4/3/2025 9:27 AM, Alex Williamson wrote:
> > On Thu, 3 Apr 2025 11:44:42 -0400
> > Stefan Hajnoczi wrote:
> >
> >> On Thu, Apr 03, 2025 at 09:47:26AM +0200, Niklas Schnelle wrote:
> >>> On Wed, 2025-04-02 at 11:51 -0400, Stefan Hajnocz
On Tue, Apr 01, 2025 at 10:22:43AM -0700, Farhan Ali wrote:
> Hi,
>
> Recently on s390x we have enabled mmap support for vfio-pci devices [1].
Hi Alex,
I wanted to bring this to your attention. Feel free to merge it through
the VFIO tree, otherwise I will merge it once you have taken a look.
Tha
On Thu, Apr 03, 2025 at 09:47:26AM +0200, Niklas Schnelle wrote:
> On Wed, 2025-04-02 at 11:51 -0400, Stefan Hajnoczi wrote:
> > On Tue, Apr 01, 2025 at 10:22:43AM -0700, Farhan Ali wrote:
> > > Hi,
> > >
> > > Recently on s390x we have enabled mmap support for vfio-pci devices [1].
> >
> > Hi Al
On 4/3/25 22:33, Farhan Ali wrote:
On 4/3/2025 11:05 AM, Alex Williamson wrote:
On Thu, 3 Apr 2025 10:33:52 -0700
Farhan Ali wrote:
On 4/3/2025 9:27 AM, Alex Williamson wrote:
On Thu, 3 Apr 2025 11:44:42 -0400
Stefan Hajnoczi wrote:
On Thu, Apr 03, 2025 at 09:47:26AM +0200, Niklas Schnell
On Thu, 3 Apr 2025 13:33:17 -0700
Farhan Ali wrote:
> On 4/3/2025 11:05 AM, Alex Williamson wrote:
> > On Thu, 3 Apr 2025 10:33:52 -0700
> > Farhan Ali wrote:
> >
> >> On 4/3/2025 9:27 AM, Alex Williamson wrote:
> >>> On Thu, 3 Apr 2025 11:44:42 -0400
> >>> Stefan Hajnoczi wrote:
> >>>
On 4/3/2025 11:05 AM, Alex Williamson wrote:
On Thu, 3 Apr 2025 10:33:52 -0700
Farhan Ali wrote:
On 4/3/2025 9:27 AM, Alex Williamson wrote:
On Thu, 3 Apr 2025 11:44:42 -0400
Stefan Hajnoczi wrote:
On Thu, Apr 03, 2025 at 09:47:26AM +0200, Niklas Schnelle wrote:
On Wed, 2025-04-02 at
On 4/3/2025 9:27 AM, Alex Williamson wrote:
On Thu, 3 Apr 2025 11:44:42 -0400
Stefan Hajnoczi wrote:
On Thu, Apr 03, 2025 at 09:47:26AM +0200, Niklas Schnelle wrote:
On Wed, 2025-04-02 at 11:51 -0400, Stefan Hajnoczi wrote:
On Tue, Apr 01, 2025 at 10:22:43AM -0700, Farhan Ali wrote:
Hi,
On Thu, 3 Apr 2025 11:44:42 -0400
Stefan Hajnoczi wrote:
> On Thu, Apr 03, 2025 at 09:47:26AM +0200, Niklas Schnelle wrote:
> > On Wed, 2025-04-02 at 11:51 -0400, Stefan Hajnoczi wrote:
> > > On Tue, Apr 01, 2025 at 10:22:43AM -0700, Farhan Ali wrote:
> > > > Hi,
> > > >
> > > > Recently on
On Wed, 2025-04-02 at 11:51 -0400, Stefan Hajnoczi wrote:
> On Tue, Apr 01, 2025 at 10:22:43AM -0700, Farhan Ali wrote:
> > Hi,
> >
> > Recently on s390x we have enabled mmap support for vfio-pci devices [1].
>
> Hi Alex,
> I wanted to bring this to your attention. Feel free to merge it through
>
Hi,
Recently on s390x we have enabled mmap support for vfio-pci devices [1].
This allows us to take advantage and use userspace drivers on s390x. However,
on s390x we have special instructions for MMIO access. Starting with z15
(and newer platforms) we have new PCI Memory I/O (MIO) instructions w
Am 27. März 2025 16:19:32 UTC schrieb "Philippe Mathieu-Daudé"
:
>
>> Bernhard Beschow (3):
>>hw/arm/imx8mp-evk: Fix reference count of SoC object
>>hw/arm/fsl-imx8mp: Derive struct FslImx8mpState from
>> TYPE_SYS_BUS_DEVICE
>>hw/arm/fsl-imx8mp: Remove unused define
>
>Series q
Bernhard Beschow (3):
hw/arm/imx8mp-evk: Fix reference count of SoC object
hw/arm/fsl-imx8mp: Derive struct FslImx8mpState from
TYPE_SYS_BUS_DEVICE
hw/arm/fsl-imx8mp: Remove unused define
Series queued to hw-misc, thanks!
At the end of the VM live migration, the vhost device will be stopped.
Currently, if the vhost-user backend crashes, vhost device's set_status()
would not return failure, live migration won't perceive the disconnection
with the backend. After the live migration is successful, the stale inflight
IO
As discussed in [1], this series modifies the SoC class be derived from
TYPE_SYS_BUS_DEVICE to fix the reset mechanism and to prevent it from being
user-creatable. It also removes an unused define.
v3:
* Fix reference counting in separate commit (Peter)
v2:
* Do not set user_creatable = false; (Z
This patch set solves errors reported by coccinelle tool with commands:
spatch --sp-file scripts/coccinelle/*.cocci --dir target/loongarch/
spatch --sp-file scripts/coccinelle/*.cocci --dir hw/loongarch/
The main problem is that qemu should fail to run when feature is forced
to enabled however
v2 discussion:
https://lore.kernel.org/qemu-devel/20250312122559.944533-1-npig...@gmail.com/T/#m9e610343e190d6e65148eb6c9d2e8f4eb8b857b8
Changes since v2:
- Fixed junk in patch 3.
- Add R-B.
Test results for functional-system-debian and -fedora can be seen here:
https://gitlab.com/npiggin/qemu/-
Since v1:
- Propagate alignment argument to BSD's mmap_find_vma()
Philippe Mathieu-Daudé (3):
bsd-user: Always use mmap_find_vma_aligned() in target_mmap()
bsd-user: Propagate alignment argument to mmap_find_vma()
user: Extract common MMAP API to 'user/mmap.h'
bsd-user/bsd-mem.h | 2 +
On Mon, Feb 24, 2025 at 10:32 PM Daniel Henrique Barboza
wrote:
>
> Hi,
>
> In this version I rolled back on the riscv_cpu_reset_hold() changes made
> in patch 1. Peter made an argument about keeping the design the same
> across architectures and I agreed. Patches 2 and 3 are already taking
> care
Hi,
In this version I rolled back on the riscv_cpu_reset_hold() changes made
in patch 1. Peter made an argument about keeping the design the same
across architectures and I agreed. Patches 2 and 3 are already taking
care of everything that KVM needs during reset, thus this doesn't incur
in any fun
Hi,
In this series we made changes in the commit msg in patch 2 to make it
less ambiguious what the KVM driver will do with ziccrse.
No other changes made. Patches based on alistair/riscv_to_apply.next.
Changes from v2:
- patch 2:
- reworded commit message
- v2 link:
https://lore.kernel.org/
CXL CCI media operations commands implmented as per CXL Specification
3.2 8.2.10.9.5.3
1) General(00h) - Discovery (00h)
2) Sanitize(01h - Sanitize (00h)
Write zeros (01h)
The patches are generated against the Johnathan's tree
https://gitlab.com/jic23/qemu.git and branch cxl-2024
On 31/1/25 22:07, Luke Craig wrote:
This PR extends the plugin API with two functions which allow convenient access
around tbs.
Luke Craig (3):
plugin: extend API with qemu_plugin_tb_get_insn_by_vaddr
plugin: extend API with qemu_plugin_tb_size
plugins: extend insn test for new conve
This PR extends the plugin API with two functions which allow convenient access
around tbs.
The first, qemu_plugin_tb_size, provides a mechanism for determining the total
size of a translation block.
The second, qemu_plugin_tb_get_insn_by_vaddr, allows users to get a reference
to an instruction b
On 21/1/25 16:55, Philippe Mathieu-Daudé wrote:
Philippe Mathieu-Daudé (3):
hw/irq: Introduce qemu_init_irqs() helper
hw/ipack: Clarify KConfig symbols
hw/ipack: Remove legacy qemu_allocate_irqs() use
Series queued.
Clarify what is what in Kconfig,
replace qemu_allocate_irqs() by qemu_init_irq().
Since v2:
- Introduce qemu_init_irqs (Bernhard)
Since v1:
- s/qemu_irq/IRQState/ in IPackDevice state
Philippe Mathieu-Daudé (3):
hw/irq: Introduce qemu_init_irqs() helper
hw/ipack: Clarify KConfig symbols
hw
One of the items raised at the QEMU maintainers meeting at KVM Forum
2024 was adoption of SPDX-License-Identifier for licensing of newly
contributed source files, for which there were no dissenting voices.
Thus, this series proposes a way to put this into action by extending
checkpatch.pl to manda
"Michael S. Tsirkin" writes:
> On Sat, Jan 04, 2025 at 04:36:04PM +0900, Akihiko Odaki wrote:
>> This series was spun off from:
>> "[PATCH 0/3] virtio-net: Convert feature properties to OnOffAuto"
>> (https://patchew.org/QEMU/20240714-auto-v3-0-e27401aab...@daynix.com/)
>>
>> Some features are n
On Sat, Jan 04, 2025 at 04:36:04PM +0900, Akihiko Odaki wrote:
> This series was spun off from:
> "[PATCH 0/3] virtio-net: Convert feature properties to OnOffAuto"
> (https://patchew.org/QEMU/20240714-auto-v3-0-e27401aab...@daynix.com/)
>
> Some features are not always available with vhost. Legacy
On 1/7/25 23:36, Peter Maydell wrote:
On Tue, 7 Jan 2025 at 17:55, Cédric Le Goater wrote:
Hello,
I would not recommend using qemu_irq_invert() in new code.
I guess in an ideal world we'd implement a QOM object
that encapsulated the the "not gate" logic, similar to
TYPE_OR_IRQ. (Though for
On Tue, 7 Jan 2025 at 17:55, Cédric Le Goater wrote:
>
> Hello,
>
> > I would not recommend using qemu_irq_invert() in new code.
> >
> > I guess in an ideal world we'd implement a QOM object
> > that encapsulated the the "not gate" logic, similar to
> > TYPE_OR_IRQ. (Though for TYPE_OR_IRQ we made
On 11/27/24 12:23, Philippe Mathieu-Daudé wrote:
On 27/11/24 10:44, Cédric Le Goater wrote:
On 11/14/24 10:48, Jamin Lin wrote:
change from v1:
1. Support RTC for AST2700.
2. Support SDHCI write protected pin inverted for AST2500 and AST2600.
3. Introduce Capabilities Register 2 for SD slot 0 a
Hello,
I would not recommend using qemu_irq_invert() in new code.
I guess in an ideal world we'd implement a QOM object
that encapsulated the the "not gate" logic, similar to
TYPE_OR_IRQ. (Though for TYPE_OR_IRQ we made the mistake
of making it inherit from TYPE_DEVICE, not TYPE_SYSBUS_DEVICE,
This series was spun off from:
"[PATCH 0/3] virtio-net: Convert feature properties to OnOffAuto"
(https://patchew.org/QEMU/20240714-auto-v3-0-e27401aab...@daynix.com/)
Some features are not always available with vhost. Legacy features are
not available with vp_vdpa in particular. virtio devices us
Hi all,
This series refactored booting protocol generation code
to better accommodate different host ABI / Alignment and
endianess.
It also enhanced LoongArch32 support.
Thanks
---
v2: Fix building on 32 bit host
Signed-off-by: Jiaxun Yang
---
Changes in v3:
- v3: Split PATCH 2 to ease revie
Hi all,
On 11/28/24 12:15, Pierrick Bouvier wrote:
For now, it was only possible to build plugins using GCC on Windows. However,
windows-aarch64 only supports Clang.
This biggest roadblock was to get rid of gcc_struct attribute, which is not
supported by Clang. After investigation, we proved it
For now, it was only possible to build plugins using GCC on Windows. However,
windows-aarch64 only supports Clang.
This biggest roadblock was to get rid of gcc_struct attribute, which is not
supported by Clang. After investigation, we proved it was safe to drop it.
Built and tested on Windows (all
On Wed, 27 Nov 2024 at 11:26, Cédric Le Goater wrote:
>
>
> > Having to modify sdhci.c internals is dubious, since inversion
> > occurs out of this block. If this is the soc/board layer, isn't
> > better to model at this level? Smth like:
> >
> > -- >8 --
> > diff --git a/hw/arm/aspeed_ast2600.c b
Hi Philippe,
> Subject: Re: [PATCH v3 0/3] Introduce a new Write Protected pin inverted
> property
>
> On 27/11/24 10:44, Cédric Le Goater wrote:
> > On 11/14/24 10:48, Jamin Lin wrote:
> >> change from v1:
> >> 1. Support RTC for AST2700.
> >> 2. S
Having to modify sdhci.c internals is dubious, since inversion
occurs out of this block. If this is the soc/board layer, isn't
better to model at this level? Smth like:
-- >8 --
diff --git a/hw/arm/aspeed_ast2600.c b/hw/arm/aspeed_ast2600.c
index be3eb70cdd7..aad9be66b75 100644
--- a/hw/arm/as
On 27/11/24 10:44, Cédric Le Goater wrote:
On 11/14/24 10:48, Jamin Lin wrote:
change from v1:
1. Support RTC for AST2700.
2. Support SDHCI write protected pin inverted for AST2500 and AST2600.
3. Introduce Capabilities Register 2 for SD slot 0 and 1.
4. Support create flash devices via command
On 11/14/24 10:48, Jamin Lin wrote:
change from v1:
1. Support RTC for AST2700.
2. Support SDHCI write protected pin inverted for AST2500 and AST2600.
3. Introduce Capabilities Register 2 for SD slot 0 and 1.
4. Support create flash devices via command line for AST1030.
change from v2:
replace w
Hello,
This series completes the conversion of the Aspeed tests to the new
functional framework and removes the workarounds for capturing the
console output.
Thanks,
C.
Changes in v3:
- Rebased on :
https://lore.kernel.org/all/20241121165806.476008-1-alex.ben...@linaro.org/
- Added docu
change from v1:
1. Support RTC for AST2700.
2. Support SDHCI write protected pin inverted for AST2500 and AST2600.
3. Introduce Capabilities Register 2 for SD slot 0 and 1.
4. Support create flash devices via command line for AST1030.
change from v2:
replace wp-invert with wp-inverted and fix revi
On 11/12/24 13:08, Alex Bennée wrote:
Pierrick Bouvier writes:
Now that meson build for plugins was merged, we can cleanup another part with
the symbols file.
It has to be kept in sync between the header (qemu-plugin.h) and the symbols
file. This has proved to be error prone and tedious.
We s
Pierrick Bouvier writes:
> Now that meson build for plugins was merged, we can cleanup another part with
> the symbols file.
> It has to be kept in sync between the header (qemu-plugin.h) and the symbols
> file. This has proved to be error prone and tedious.
>
> We solve this by generating this l
Support to load DTB after 3GB on RV64 system, so that larger initrd
doesn't be overlapped to DTB. DTB loading now will check if overlapping
to kernel/initrd and report this error.
Verify the patch via running 4GB initramfs on the virt machine.
Changes for v3:
- Change struct RISCVBootInfo from
Now that meson build for plugins was merged, we can cleanup another part with
the symbols file.
It has to be kept in sync between the header (qemu-plugin.h) and the symbols
file. This has proved to be error prone and tedious.
We solve this by generating this list from header directly using a pytho
Hi Alex,
On 10/24/24 03:15, Alex Bennée wrote:
Pierrick Bouvier writes:
Contrib plugins have been built out of tree so far, thanks to a Makefile.
However, it is quite inconvenient for maintenance, as we may break them,
especially for specific architectures.
First patches are fixing warnings
在 2024/10/28 上午10:38, Bibo Mao 写道:
Add unistd_64.h on arm64,loongarch and riscv platform, and update
linux headers to Linux v6.12-rc5.
Pass to compile on aarch64, arm, loongarch64, x86_64, i386, riscv64,
riscv32 softmmu and linux-user.
---
v2 ... v3:
1. Add unistd_64.h on arm64 and riscv pla
Add unistd_64.h on arm64,loongarch and riscv platform, and update
linux headers to Linux v6.12-rc5.
Pass to compile on aarch64, arm, loongarch64, x86_64, i386, riscv64,
riscv32 softmmu and linux-user.
---
v2 ... v3:
1. Add unistd_64.h on arm64 and riscv platform also
2. Update header files to
Pierrick Bouvier writes:
> Contrib plugins have been built out of tree so far, thanks to a Makefile.
> However, it is quite inconvenient for maintenance, as we may break them,
> especially for specific architectures.
>
> First patches are fixing warnings for existing plugins, then we add meson
>
Contrib plugins have been built out of tree so far, thanks to a Makefile.
However, it is quite inconvenient for maintenance, as we may break them,
especially for specific architectures.
First patches are fixing warnings for existing plugins, then we add meson
support, and finally, we remove Makefi
On 9/25/24 03:43, Alex Bennée wrote:
Alex Bennée writes:
Queued to testing/next, thanks.
Gentle ping. I can't see this series on testing/next. Was it lost on the
way?
Thanks,
Pierrick
Pierrick Bouvier writes:
> While working on a concurrency bug, I gave a try to tsan builds for QEMU. I
> noticed it didn't build out of the box with recent gcc, so I fixed
> compilation.
> In more, updated documentation to explain how to build a sanitized glib to
> avoid
> false positives relat
On 10/09/2024 19.40, Pierrick Bouvier wrote:
While working on a concurrency bug, I gave a try to tsan builds for QEMU. I
noticed it didn't build out of the box with recent gcc, so I fixed compilation.
In more, updated documentation to explain how to build a sanitized glib to avoid
false positives
While working on a concurrency bug, I gave a try to tsan builds for QEMU. I
noticed it didn't build out of the box with recent gcc, so I fixed compilation.
In more, updated documentation to explain how to build a sanitized glib to avoid
false positives related to glib synchronisation primitives.
v
Update the SPCR table to accommodate the SPCR Table version 4 [1].
The SPCR table has been modified to adhere to the version 4 format [2].
Meanwhile, the virt SPCR golden reference files have been updated to
accommodate the SPCR Table version 4.
[1]:
https://learn.microsoft.com/en-us/windows-har
On Fri, Aug 2, 2024 at 5:25 PM LIU Zhiwei wrote:
>
> In this patch set, we remove the redundant insn length check for zama16b as
> the
> specification clarified that zama16b applies to compressed encodings[1].
>
> Richard points out we should obey the MXLEN requirement for F/D/Q loads or
> store
In this patch set, we remove the redundant insn length check for zama16b as the
specification clarified that zama16b applies to compressed encodings[1].
Richard points out we should obey the MXLEN requirement for F/D/Q loads or
stores,
so we add this constraint for trans_fld/fsd.
I notice that w
v2 -> v3:
* Patch 2: modify test case. Increase number of requests from 1024 to
2048; make odd requests write actual data, while even requests cause
write_zeroes operation;
* Add patch 3: add scripts/filev2p.py for mapping of virtual file
offsets to physical block device offsets.
Updating a bunch of VMX and VSX storage access instructions to use
tcg_gen_qemu_ld/st_i128 instead of using tcg_gen_qemu_ld/st_i64 in
succession; as suggested by Richard, in my decodetree patches.
Plus some minor clean-ups to facilitate the above in case of VMX insns.
Change log:
v3 : Rectified E
On Sun, 7 Jul 2024 at 09:59, Inès Varhol wrote:
>
> STM32L4x5 EXTI was handling only configurable interrupts
> (such as those coming from STM32L4x5 SYSCFG which was the
> only device connected to the EXTI).
> This patch adds support for direct line interrupts and
> connects the existing STM32L4x5
STM32L4x5 EXTI was handling only configurable interrupts
(such as those coming from STM32L4x5 SYSCFG which was the
only device connected to the EXTI).
This patch adds support for direct line interrupts and
connects the existing STM32L4x5 USART devices to the EXTI.
The patch also corrects the handli
From: Clément Mathieu--Drif
Various fixes for VT-d
This series contains fixes that will be necessary
when adding in-guest (fully emulated) SVM support.
v3
FRCD construction macro :
- Longer sha1 for the 'Fixes' tag
- Add '.' at the end of the sentence
Make types mat
On Mon, 24 Jun 2024 at 19:09, Gustavo Romero wrote:
>
> Enable FEAT_Debugv8p8 on Arm max CPU.
>
> v2:
> - Revert to the original comment above call to aa32_max_features()
>
> v3:
> - Added feature entry to docs/system/arm/emulation.rst
> - Explicitly set t=0 before using it to set DBGDEVID reg.
Enable FEAT_Debugv8p8 on Arm max CPU.
v2:
- Revert to the original comment above call to aa32_max_features()
v3:
- Added feature entry to docs/system/arm/emulation.rst
- Explicitly set t=0 before using it to set DBGDEVID reg.
- Put indent fix in a separate patch
Cheers,
Gustavo
Gustavo Rom
No worries, and thanks!
On Mon, Jun 24, 2024 at 3:52 PM Peter Maydell wrote:
>
> On Mon, 24 Jun 2024 at 10:12, Rayhan Faizel wrote:
> >
> > Hi,
> >
> > The patch series is still not merged.
>
> Oops, sorry about that -- not sure how it got lost. I have
> applied it to target-arm.next for real th
On Mon, 24 Jun 2024 at 10:12, Rayhan Faizel wrote:
>
> Hi,
>
> The patch series is still not merged.
Oops, sorry about that -- not sure how it got lost. I have
applied it to target-arm.next for real this time...
-- PMM
Hi,
The patch series is still not merged.
On Thu, May 30, 2024 at 6:57 PM Peter Maydell wrote:
>
> On Sun, 19 May 2024 at 10:42, Rayhan Faizel wrote:
> >
> > All BCM2835 boards have on-board OTP memory with 66 32-bit rows. Usually,
> > its contents are accessible via mailbox commands.
> >
> > [
Add a way to update the boot-mode via machine properties.
Changes for V2:
Make boot-mode property work with string
Fixed few code style issues
Added zynq board doc.
Changes for V3:
Mentioned about zynq doc in MAINTAINERS file
Stick to small case for mentioning boot modes in doc
On 5/6/24 15:14, Gerd Hoffmann wrote:
Gerd Hoffmann (3):
stdvga: fix screen blanking
ui+display: rename is_placeholder() -> surface_is_placeholder()
ui+display: rename is_buffer_shared() -> surface_is_allocated()
Since Marc-André reviewed, I'm queuing this series, thanks!
The original code assumes that memory transmission is always successful,
but in some cases, it gets bus-error.
Add error handling for DMA reading description failures. Do some
reasonable settings, and return the corrected transmission size.
Finally, return the error status.
* Fix the trace format
Today for x86 the _PRT() table is computed in runtime.
Under some configurations, computing the _PRT table can take more than
30 seconds and the ACPI timeout is violated.
This patchset modifies _PRT() to return a pre-computed table.
Changelog v2 Thanks Michael:
- Code style
- Add cover letter
Ri
Add a new library api to check for the support of a specific cpu type.
Used the new api to check support for some older x86 cpu models before
running the tests.
CC: th...@redhat.com
CC: imamm...@redhat.com
CC: qemu-devel@nongnu.org
CC: pbonz...@redhat.com
CC: lviv...@redhat.com
CC: m...@redhat.com
On Wed, Jun 5, 2024 at 1:00 PM Chao Du wrote:
>
> This series implements QEMU KVM Guest Debug on RISC-V, with which we
> could debug RISC-V KVM guest from the host side, using software
> breakpoints.
>
> This series is based on riscv-to-apply.next branch and is also
> available at:
> https://githu
On Wed, Jun 5, 2024 at 5:14 PM Gerd Hoffmann wrote:
>
>
>
> Gerd Hoffmann (3):
> stdvga: fix screen blanking
> ui+display: rename is_placeholder() -> surface_is_placeholder()
> ui+display: rename is_buffer_shared() -> surface_is_allocated()
>
> include/ui/surface.h| 6 +++---
> hw/disp
Gerd Hoffmann (3):
stdvga: fix screen blanking
ui+display: rename is_placeholder() -> surface_is_placeholder()
ui+display: rename is_buffer_shared() -> surface_is_allocated()
include/ui/surface.h| 6 +++---
hw/display/qxl-render.c | 2 +-
hw/display/vga.c| 24 ++
This series implements QEMU KVM Guest Debug on RISC-V, with which we
could debug RISC-V KVM guest from the host side, using software
breakpoints.
This series is based on riscv-to-apply.next branch and is also
available at:
https://github.com/Du-Chao/alistair23-qemu/tree/riscv-to-apply.next.0605
T
On Sun, 19 May 2024 at 10:42, Rayhan Faizel wrote:
>
> All BCM2835 boards have on-board OTP memory with 66 32-bit rows. Usually,
> its contents are accessible via mailbox commands.
>
> [Changes in v3]
>
> - Forgot to replace constant with macro in one particular spot.
>
> [Changes in v2]
>
> - Rep
Song will online next week.
Please correct me if there is something wrong, song.
On 2024/5/24 上午7:50, Jiaxun Yang wrote:
在2024年5月21日五月 下午1:32，Song Gao写道：
On LoongArch, IRQs can be routed to four vcpus with hardware extioi.
This patch adds the extioi virt extension support so that the IRQ ca
在2024年5月21日五月 下午1:32，Song Gao写道：
> On LoongArch, IRQs can be routed to four vcpus with hardware extioi.
> This patch adds the extioi virt extension support so that the IRQ can
> route to 256 vcpus.
Hi Song,
Sorry for chime in here, I'm a little bit confused by this series, can
you give me a li
On ppc64, the PowerVM hypervisor runs with limited memory and a VCPU
creation during hotplug may fail during kvm_ioctl for KVM_CREATE_VCPU,
leading to termination of guest since errp is set to &error_fatal while
calling kvm_init_vcpu. This unexpected behaviour can be avoided by
pre-creating and par
I upgraded my Fedora Asahi Remix from 39 to 40 and found new sanitizer
errors with clang it ships so here are fixes.
The patch "meson: Drop the .fa library prefix" may have a broad impact
to the build system so please tell me if you have a concern with it.
To: Michael Tokarev
To: Laurent Vivier
1 - 100 of 1073 matches
Mail list logo
