On Wed, May 07, 2025 at 14:46:16 +0200, Michal Privoznik via Devel wrote:
> From: Michal Privoznik
>
> While with upstream QEMU it's impossible to have virtio-mem-ccw and not
> have virtio-mem-pci, in RHEL the QEMU's build system is patched to make
> that possible. But this breaks our assumption
On Wed, May 07, 2025 at 15:56:52 +0200, Martin Kletzander wrote:
> On Sun, Apr 27, 2025 at 07:48:02PM +0800, honglei.w...@smartx.com wrote:
> > From: hongleiwang
> >
> > QEMU has supported nvme disk emulation for a long time,
> > see: https://qemu-project.gitlab.io/qemu/system/devices/nvme.html.
On Wed, May 07, 2025 at 09:55:13AM +0200, Markus Armbruster wrote:
> Pierrick Bouvier writes:
>
> [...]
>
> > I don't think we should think too much ahead for languages other than C,
> > for one, two, and even three reasons :)
>
> I agree that thinking ahead too much is a bad habit. So is thi
On Wed, May 07, 2025 at 16:38:38 -0700, Matthew R. Ochs via Devel wrote:
> The borzoi machine type was dropped in QEMU 9.2.0, so let's
> use a different machine type with no ACPI support and no
> implicit USB controller instead.
>
> Signed-off-by: Matthew R. Ochs
> ---
> tests/qemuxmlconfdata/aa
On Wed, May 07, 2025 at 16:38:46 -0700, Matthew R. Ochs via Devel wrote:
> Add xml and reply files for QEMU 10.0.0 on aarch64.
I'd prefer if the commit message commented on some of the .args changes.
See below. (I can ammend the commit message for you so that you don't
have to resend the caps dump
On Sun, Apr 27, 2025 at 07:48:02PM +0800, honglei.w...@smartx.com wrote:
From: hongleiwang
QEMU has supported nvme disk emulation for a long time,
see: https://qemu-project.gitlab.io/qemu/system/devices/nvme.html.
The following patches introduce nvme-ns disk bus type:
Thanks for the v2. I h
From: Michal Privoznik
While with upstream QEMU it's impossible to have virtio-mem-ccw and not
have virtio-mem-pci, in RHEL the QEMU's build system is patched to make
that possible. But this breaks our assumption when fetching
capabilities.
Well, just do what we are already doing in this situati
On 2025-05-05 09:20, Peter Krempa wrote:
On Wed, Apr 30, 2025 at 15:47:31 +0200, Shalini Chellathurai Saroja
wrote:
Update the replies and xml files for QEMU 10.0.0 on s390x based on
the released QEMU tag v10.0.0 with the commit Id
7c949c53e936aa3a658d84ab53bae5cadaa5d59c.
Signed-off-by: Shalin
On Fri, Apr 11, 2025 at 08:40:54AM -0700, Matthew R. Ochs via Devel wrote:
> Resending: Series has been re-based over latest upstream.
>
> This patch series adds support for configuring the PCI high memory MMIO
> window size for aarch64 virt machine types. This feature has been merged
> into the Q
Daniel P. Berrangé writes:
> On Tue, Apr 29, 2025 at 09:43:24AM +0200, Markus Armbruster wrote:
>> Pierrick Bouvier writes:
>>
>> > After looking at the introspection code, I don't see any major blocker.
>> > We need to keep some of existing "if", as they are based on config-host,
>> > and sho
This is a refresh of a series that Andrea Bolognani posted in February
2025 [1] and provides aarch64 capability support for QEMU v10.0.0.
[1]
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/Z4NQ3CVQYLNGZRBC35CUHOQ2EXJROPYG
Signed-off-by: Matthew R. Ochs
Matthew R. Ochs (
The borzoi machine type was dropped in QEMU 9.2.0, so let's
use a different machine type with no ACPI support and no
implicit USB controller instead.
Signed-off-by: Matthew R. Ochs
---
tests/qemuxmlconfdata/aarch64-noacpi-acpi.aarch64-latest.err| 2 +-
tests/qemuxmlconfdata/aarch64-noacpi-ac
Hi Daniel,
Thanks for your feedback!
> On May 7, 2025, at 11:51 AM, Daniel P. Berrangé wrote:
> On Fri, Apr 11, 2025 at 08:40:54AM -0700, Matthew R. Ochs via Devel wrote:
>> Resending: Series has been re-based over latest upstream.
>>
>> This patch series adds support for configuring the PCI hi
On Tue, May 06, 2025 at 17:00:11 +0100, Tim Small via Devel wrote:
> Add check for networks which were previously
> neglected (as opposed to explicit PCI hostdev devices), so that they can
> be granted the necessary permissions for PCI device access. The network
> type lookup in-turn requires the
On Tue, May 06, 2025 at 17:00:10 +0100, Tim Small via Devel wrote:
> Signed-off-by: Tim Small
> ---
> src/security/virt-aa-helper.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
Note my comment about git config for authorship on 2/2;
Reviewed-by: Peter Krempa
Pierrick Bouvier writes:
[...]
> I don't think we should think too much ahead for languages other than C,
> for one, two, and even three reasons :)
I agree that thinking ahead too much is a bad habit. So is thinking
ahead too little :)
> - First, it's already broken because we rely on ifdef
On Wed, May 07, 2025 at 10:07:41 +0300, Dmitry Frolov wrote:
> Enum variable of type qemuMigrationCapability is checked for zero in
> src/qemu/qemu_migration_params.c:729.
>
> "if (item->optional) { ..."
>
> Actualy, QEMU_MIGRATION_CAP_XBZRLE enum constant has value 0.
> So, at least, the conditi
On Wed, May 07, 2025 at 10:07:41 +0300, Dmitry Frolov via Devel wrote:
> Enum variable of type qemuMigrationCapability is checked for zero in
> src/qemu/qemu_migration_params.c:729.
>
> "if (item->optional) { ..."
>
> Actualy, QEMU_MIGRATION_CAP_XBZRLE enum constant has value 0.
> So, at least, t
Thanks for your review and comments!
On 2025-05-06 10:24, Peter Krempa wrote:
> As witnessed by the fact that you needed to include assert.h we don't
> use asserts in the code base.
>
> While this code path should not be possible to reach without doing
> a programming error we still should repo
Enum variable of type qemuMigrationCapability is checked for zero in
src/qemu/qemu_migration_params.c:729.
"if (item->optional) { ..."
Actualy, QEMU_MIGRATION_CAP_XBZRLE enum constant has value 0.
So, at least, the condition is incorrect.
v1: introducing a separate enum for optional capabilities
20 matches
Mail list logo
