On 9/9/25 8:05 AM, Ján Tomko via Devel wrote:
Ján Tomko (8):
qemu: passt: split out qemuPasstBuildCommand
tests: qemuxmlconftests: store suffix in testQemuInfo
tests: qemuxmlconftest: Introduce testQemuConfMarkUsed
export qemuVirtioFSBuildCommandLine
tests: qemuxmlconftest: test pa
On 9/9/25 8:05 AM, Ján Tomko via Devel wrote:
From: Ján Tomko
Signed-off-by: Ján Tomko
---
...t-user-fs-ccw.s390x-latest.virtiofsd0.args | 3 ++
...fs-fd-memory.x86_64-latest.virtiofsd0.args | 9 ++
...fd-openfiles.x86_64-latest.virtiofsd0.args | 10 ++
...fs-hugepages.x86_64-la
On 9/9/25 8:05 AM, Ján Tomko via Devel wrote:
From: Ján Tomko
The combination of locking + readonly is bogus, because there has never
been a virtiofsd release that supported both.
Locking was a feature of the C-based virtiofsd that was living in the
QEMU tree until v8.0.0 and the readonly feat
On 9/9/25 8:05 AM, Ján Tomko via Devel wrote:
From: Ján Tomko
Introduce testing of the generated command line arguments
of helper binaries too, not just QEMU.
Start with passt.
Signed-off-by: Ján Tomko
The test results need to be regenerated due to commit
cca246e0cbd9f793f91537800f649179d
We currently always pick a read-only firmware unless we are
explicitly asked for a read/write one, which is probably what
most people expect anyway but doesn't really make sense
otherwise: if no specific requirement has been provided by the
user, both read-only and read/write firmwares should be
al
On Tue, Aug 19, 2025 at 18:22:18 +0200, Andrea Bolognani via Devel wrote:
> This centralizes the knowledge about which network interface
> models are PCI devices and thus need to have a PCI address
> allocated by libvirt, and expands said knowledge to include
> the fact that models such as spapr-vl
On Tue, Aug 19, 2025 at 18:22:21 +0200, Andrea Bolognani via Devel wrote:
> The sparc architecture doesn't support PCI, and neither does
> the isapc machine type.
You're mixing architectures with machines :P (spell out the arch for
isapc)
> One of the isapc tests starts failing as a consequence o
On Tue, Aug 19, 2025 at 18:22:19 +0200, Andrea Bolognani via Devel wrote:
> At the moment, we check whether the machine type supports PCI
> before attempting to allocate PCI addresses, and if it does
> not, we simply skip the step entirely.
>
> This means that an attempt to use a PCI device with a
From: xiangwencheng
Signed-off-by: xiangwencheng
---
NEWS.rst | 7 +++
1 file changed, 7 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index 1b8e188f5e..db98d9e7c2 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -32,6 +32,13 @@ v11.8.0 (unreleased)
On the XML side, the existing element has
From: Michal Privoznik
At the end of chDomainDetachDeviceLive() there's a code that
tries to remove the disk that's being detached from the domain
definition. Well, it's a leftover from the original patch which I
forgot to remove when rewriting it to use chDomainRemoveDevice().
The disk is remove
On Tue, Aug 19, 2025 at 18:22:16 +0200, Andrea Bolognani via Devel wrote:
> The isapc machine type doesn't support PCI, so attempting to
> add a PCI controller should fail. It currently doesn't, and
> we're going to address that in an upcoming commit.
>
> Note that the domain gets a PCI memballoon
On Tue, Aug 19, 2025 at 18:22:16 +0200, Andrea Bolognani via Devel wrote:
> The isapc machine type doesn't support PCI, so attempting to
> add a PCI controller should fail. It currently doesn't, and
> we're going to address that in an upcoming commit.
>
> Note that the domain gets a PCI memballoon
On Tue, Aug 19, 2025 at 18:22:26 +0200, Andrea Bolognani via Devel wrote:
> Signed-off-by: Andrea Bolognani
> ---
> src/qemu/qemu_command.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
Reviewed-by: Peter Krempa
On Tue, Aug 19, 2025 at 18:22:29 +0200, Andrea Bolognani via Devel wrote:
> In addition to the code in qemuDomainControllerDefPostParse(),
> which we have just factored into its own function, we also have
> some code in qemuDomainDefAddDefaultDevices() that deals with
> choosing the USB controller
On Tue, Aug 19, 2025 at 18:22:28 +0200, Andrea Bolognani via Devel wrote:
> Extract the logic from qemuDomainControllerDefPostParse() to
> a dedicated helper. The behavior is unchanged.
>
> Signed-off-by: Andrea Bolognani
> ---
> src/qemu/qemu_domain.c| 82 +++
On Tue, Aug 19, 2025 at 18:22:24 +0200, Andrea Bolognani via Devel wrote:
> When support for s390x was introduced in libvirt, it naturally
> followed the conventions established at the time for x86, which
> were to have a USB controller added by default.
>
> Later, in 2013, commit 3a82f628a964 mad
From: xiangwencheng
riscv-aia feature was introduced in qemu-8.2 to specify the
KVM AIA mode. The "riscv-aia" parameter is passed along with
-accel in QEMU command-line.
1) "riscv-aia=emul": IMSIC is emulated by hypervisor
2) "riscv-aia=hwaccel": use hardware guest IMSIC
3) "riscv-aia=auto": use
On Tue, Aug 19, 2025 at 18:22:28 +0200, Andrea Bolognani via Devel wrote:
> Extract the logic from qemuDomainControllerDefPostParse() to
> a dedicated helper. The behavior is unchanged.
I don't see it changed anywhere else ... is it just to separate stuff?
>
> Signed-off-by: Andrea Bolognani
>
On Tue, Aug 19, 2025 at 18:22:27 +0200, Andrea Bolognani via Devel wrote:
> Right now we call qemuValidateDomainDeviceDefControllerUSB()
> quite late, just as we're generating the QEMU command line.
>
> The original intention was likely to prevent configurations
> from being rejected, even though
On Tue, Aug 19, 2025 at 18:22:25 +0200, Andrea Bolognani via Devel wrote:
> We have just changed PostParse so that MODEL_USB_NONE will be
> used instead of MODEL_USB_DEFAULT, so this code is no longer
> doing anything.
>
> Signed-off-by: Andrea Bolognani
> ---
> src/qemu/qemu_command.c | 5 -
On Tue, Aug 19, 2025 at 18:22:23 +0200, Andrea Bolognani via Devel wrote:
> If we have gotten this far into creating the QEMU command line,
> either the user or some earlier code should have assigned a PCI
> address to the USB controller. If one is not present, that must
> mean there's a bug somewh
On Tue, Aug 19, 2025 at 18:22:22 +0200, Andrea Bolognani via Devel wrote:
> These checks enforce some expectations that were, until now,
> documented solely through comments or not spelled out at all.
>
> Signed-off-by: Andrea Bolognani
> ---
> src/qemu/qemu_postparse.c | 38
From: xiangwencheng
Signed-off-by: BillXiang
---
.../caps_9.1.0_riscv64.replies| 4 +++
.../caps_9.1.0_riscv64.xml| 3 ++
...atures-aia-aplic-imsic.riscv64-latest.args | 31 +++
...eatures-aia-aplic-imsic.riscv64-latest.xml | 1 +
.../riscv
On Tue, Aug 19, 2025 at 18:22:15 +0200, Andrea Bolognani via Devel wrote:
> Only the -eb variants of the realview board support PCI
> devices, so those are the only ones that should automatically
> get a USB controller (addDefaultUSB).
You don't mention what the consequence of the originally bad c
On Tue, Aug 19, 2025 at 18:22:17 +0200, Andrea Bolognani via Devel wrote:
> The isapc machine type doesn't support PCI, so adding a
> memballoon (which is a PCI device) to it doesn't make sense.
>
> Signed-off-by: Andrea Bolognani
> ---
> src/qemu/qemu_postparse.c | 3 +-
On 9/18/25 02:12, Andrea Bolognani wrote:
On Wed, Sep 17, 2025 at 12:57:36PM -0600, Jim Fehlig wrote:
On 9/12/25 00:58, Andrea Bolognani wrote:
I wasn't planning on pushing this series until we have
reached an agreement on the edk2 side for the contents of the
descriptors.
After reading this
On Wed, Sep 17, 2025 at 12:57:36PM -0600, Jim Fehlig wrote:
> On 9/12/25 00:58, Andrea Bolognani wrote:
> > I wasn't planning on pushing this series until we have
> > reached an agreement on the edk2 side for the contents of the
> > descriptors.
>
> After reading this again today, I came to the opi
27 matches
Mail list logo
