Historically libvirt hasn't differentiated between the name of a
loadable kernel module, and the name of the device driver that module
implements, but these two names can be (and usually are) at least
subtly different.
For example, the loadable module called "vfio_pci" implements a PCI
driver call
This is done so that we can re-use the same parser/formatter for
and
Signed-off-by: Laine Stump
Reviewed-by: Peter Krempa
---
src/conf/device_conf.c | 40
src/conf/device_conf.h | 7 +++
src/conf/domain_conf.c | 27 +--
3 f
Currently this enum is defined in domain_conf.h and named
virDomainHostdevSubsysPCIDriverType. I want to use it in parts of the
network and networkport config, so am moving its definition to
device_conf.h which is / can be included by all interested parties,
and renaming it to match the name of the
Now if a new attribute is added to , we only need to update
the formatting/parsing in one place.
Signed-off-by: Laine Stump
Reviewed-by: Peter Krempa
---
src/conf/network_conf.c | 23 ---
src/conf/virnetworkportdef.c | 20 ++--
2 files changed, 10 insert
The hostdev version of the subelement appears in four places:
* The domain XML in the and
elements (that's 2)
* The network XML inside when the network is a pool of
SRIOV VFs
* the XML, which is used to communicate between the
hypervisor driver and network driver.
In order to m
The next step in consolidating parsing/formatting of the
element of these objects using a common struct and common code. This
eliminates the virNetworkForwardDriverNameType enum which is nearly
identical to virDeviceHostdevPCIDriverName (the only non-identical bit
was just because they'd gotten ou
virHostdevIsVFIODevice() and virDomainDefHasVFIOHostdev() are only ever
called from the QEMU driver, and in the case of the QEMU driver, any
PCI hostdev by definition uses VFIO, so really all these callers only
need to know if the device is a PCI hostdev.
(It turned out that the less specific virH
The new struct is virDeviceHostdevPCIDriverInfo, and the "backend"
enum in the hostdevDef will be replaced with a
virDeviceHostdevPCIDriverInfo named "driver'. Since the enum value in
this new struct is called "name", it means that all references to
"backend" will become "driver.name".
This will a
Xen only supports a single type of PCI hostdev assignment, so it is
superfluous to have peppered throughout the
config. It *is* necessary to have the driver type explicitly set in
the hostdev object before calling into the hypervisor-agnostic "hostdev
manager" though (otherwise the hostdev manager
This is "V3 of Part 2".
"V2 of Part 2": is here:
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/EVHMTCQ2XWUQR5RPH5TPGDAAUFGWNTQC/
Part 1 (which simply made it possible to use virsh nodedev-detach to
bind a device to a manually-specified variant driver, and at guest
runtim
Rather than always binding to the vfio-pci driver, use the new
function virPCIDeviceFindBestVFIOVariant() to see if the running
kernel has a VFIO variant driver available that is a better match for
the device, and if one is found, use that instead.
virPCIDeviceFindBestVFIOVariant() function reads
This patch makes it possible to manually specify which VFIO variant
driver to use for PCI hostdev device assignment, so that, e.g. you
could force use of a VFIO "variant" driver, with e.g.
or alternately to force use of the generic vfio-pci driver with
when libvirt would have normally (af
The exact same element can appear in and , and nearly identical in and
(these latter two don't include "xen" as a possible driver, but that's
coincidental - there's no reason Xen couldn't also use the VF pools in
virtual networks, it just doesn't).
This patch modifies all 4 to use the same
so
The long-deprecated use of in domain xml
for devices was only ever necessary during the period when
libvirt (and the Linux kernel) supported both VFIO and "legacy KVM"
styles of hostdev device assignment for QEMU. This became pointless
many years ago when legacy KVM device assignment was removed
On Thu, Jan 04, 2024 at 20:01:44 -0500, Laine Stump wrote:
> On 11/28/23 10:39 AM, Peter Krempa wrote:
> > On Mon, Nov 06, 2023 at 02:39:00 -0500, Laine Stump wrote:
> > > Rather than always binding to the vfio-pci driver, use the new
> > > function virPCIDeviceFindBestVFIOVariant() to see if the r
On Thu, Jan 04, 2024 at 23:39:38 +0100, Peter Krempa wrote:
> On Thu, Jan 04, 2024 at 12:24:38 -0600, Jonathon Jongsma wrote:
> > Currently when we build with nbdkit support, libvirt will always try to
> > use nbdkit to access remote disk sources when it is available. But
> > without an up-to-date
ping
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org
> On 1/4/24 01:16, Artem Chernyshev wrote:
>
> It doesn't really fix anything. The code is not broken.
>
>
True, just mentioned commit which I addressed in my patch
>
> No. This changes semantics. Prior to your change, if
> qemuMonitorJSONParseCPUx86FeatureWord() failed then 'return NULL' pat
On Fri, Jan 05, 2024 at 09:43:52AM +0100, Peter Krempa wrote:
> On Thu, Jan 04, 2024 at 23:39:38 +0100, Peter Krempa wrote:
> > On Thu, Jan 04, 2024 at 12:24:38 -0600, Jonathon Jongsma wrote:
> > > Currently when we build with nbdkit support, libvirt will always try to
> > > use nbdkit to access re
On Fri, Jan 05, 2024 at 01:30:19 -0800, Andrea Bolognani wrote:
> On Fri, Jan 05, 2024 at 09:43:52AM +0100, Peter Krempa wrote:
> > On Thu, Jan 04, 2024 at 23:39:38 +0100, Peter Krempa wrote:
> > > On Thu, Jan 04, 2024 at 12:24:38 -0600, Jonathon Jongsma wrote:
> > > > Currently when we build with
rhel-8 lacks 'pidfd_open()' support and thus nbdkit can't be enabled
there.
mingw builds explicitly disable nbdkit support, but use
'--auto-features=enabled' thus omitting setting of
'nbdkit_config_default' results in meson thinking we want to enable it:
../meson.build:1018:2: ERROR: Problem en
On Fri, Jan 05, 2024 at 10:57:46AM +0100, Peter Krempa wrote:
> rhel-8 lacks 'pidfd_open()' support and thus nbdkit can't be enabled
> there.
>
> mingw builds explicitly disable nbdkit support, but use
> '--auto-features=enabled' thus omitting setting of
> 'nbdkit_config_default' results in meson t
On Fri, Jan 05, 2024 at 10:53:10AM +0100, Peter Krempa wrote:
> - mingw builds for some unkonwn-to-me reason use
>'--auto-features=enabled' which is weird
> - the logic handling errors in use of the 'nbdkit_config_default' meson
>option is a bit questionable:
>
> --auto-features=enabl
On Fri, Jan 05, 2024 at 02:18:08 -0800, Andrea Bolognani wrote:
> On Fri, Jan 05, 2024 at 10:53:10AM +0100, Peter Krempa wrote:
> > - mingw builds for some unkonwn-to-me reason use
> >'--auto-features=enabled' which is weird
> > - the logic handling errors in use of the 'nbdkit_config_default
On Fri, Jan 05, 2024 at 03:20:13 -0500, Laine Stump wrote:
> Xen only supports a single type of PCI hostdev assignment, so it is
> superfluous to have peppered throughout the
> config. It *is* necessary to have the driver type explicitly set in
> the hostdev object before calling into the hypervis
v2 of:
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/MWYGWDC7D7DOQCZ6CLSIRYRNAFNS3OGQ/
diff to v1:
- Don't set .unplugged-inaccessible because it's not compatible with
!x84_64 and even on x86_64 it's likely to get deprecated soon. Thanks
David for pointing this out!
Introduced in v8.2.0-rc0~74^2~2, QEMU now allows setting
.dynamic-memslots attribute for virtio-mem-pci devices. When
turned on, it allows memory exposed to guest to be split into
multiple memslots and thus smaller memory footprint (see the
original commit for detailed explanation).
Therefore, int
Starting from v8.2.0-rc0~74^2~2 QEMU has .dynamic-memslots
attribute for virtio-mem-pci device. Introduce a capability which
reflects that.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_capabilities.c | 2 ++
src/qemu/qemu_capabilities.h | 1 +
tests/q
The QEMU_CAPS_DEVICE_VIRTIO_MEM_PCI_DYNAMIC_MEMSLOTS reflects
whether QEMU is capable of .dynamic-memslots for virtio-mem.
Use it when validating domain configuration.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_validate.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/qemu
This is pretty straightforward.
Resolves: https://issues.redhat.com/browse/RHEL-15316
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_command.c| 3 +++
.../memory-hotplug-virtio-mem.x86_64-latest.args | 2 +-
2 files changed, 4 insertions(+
On Fri, Jan 05, 2024 at 03:20:15 -0500, Laine Stump wrote:
> This patch makes it possible to manually specify which VFIO variant
> driver to use for PCI hostdev device assignment, so that, e.g. you
> could force use of a VFIO "variant" driver, with e.g.
>
>
>
> or alternately to force use of t
On Fri, Jan 05, 2024 at 13:33:32 +0100, Michal Privoznik wrote:
> Introduced in v8.2.0-rc0~74^2~2, QEMU now allows setting
> .dynamic-memslots attribute for virtio-mem-pci devices. When
> turned on, it allows memory exposed to guest to be split into
> multiple memslots and thus smaller memory footp
Test pipeline: https://gitlab.com/abologna/libvirt/-/pipelines/1128046264
Andrea Bolognani (2):
tests: Drop some unused qemunbdkit data files
tests: Ensure test files are newline-terminated
...69d019_36ea_4111_8f0a_8c9a70e21366-create.json | 2 +-
...69d019_36ea_4111_8f0a_8c9a70e21366-defin
Currently we only append a newline to 'actual' if 'expected'
(as loaded from file) already ends in a newline, but that
results in inconsistent behavior.
For example, some of the test files used by virhostcputest are
newline-terminated and some aren't. If we were to remove
existing newlines from th
The test still passes after deleting them, which seems to
indicate that they're unnecessary.
Signed-off-by: Andrea Bolognani
---
.../disk-network-source-curl.args.disk2.pipe.782 | 1 -
tests/qemunbdkitdata/disk-network-ssh.args.disk1 | 8
.../qemunbdkitdata/disk-network-
On Fri, Jan 05, 2024 at 13:33:35 +0100, Michal Privoznik wrote:
> This is pretty straightforward.
>
> Resolves: https://issues.redhat.com/browse/RHEL-15316
> Signed-off-by: Michal Privoznik
> ---
> src/qemu/qemu_command.c| 3 +++
> .../memory-hotplug-virti
On 1/5/24 14:02, Andrea Bolognani wrote:
> Test pipeline: https://gitlab.com/abologna/libvirt/-/pipelines/1128046264
>
> Andrea Bolognani (2):
> tests: Drop some unused qemunbdkit data files
> tests: Ensure test files are newline-terminated
>
> ...69d019_36ea_4111_8f0a_8c9a70e21366-create.js
On Fri, Jan 05, 2024 at 13:33:33 +0100, Michal Privoznik wrote:
> Starting from v8.2.0-rc0~74^2~2 QEMU has .dynamic-memslots
> attribute for virtio-mem-pci device. Introduce a capability which
> reflects that.
>
> Signed-off-by: Michal Privoznik
> ---
> src/qemu/qemu_capabilities.c
On Fri, Jan 05, 2024 at 13:33:34 +0100, Michal Privoznik wrote:
> The QEMU_CAPS_DEVICE_VIRTIO_MEM_PCI_DYNAMIC_MEMSLOTS reflects
> whether QEMU is capable of .dynamic-memslots for virtio-mem.
> Use it when validating domain configuration.
>
> Signed-off-by: Michal Privoznik
> ---
> src/qemu/qemu_
On 05.01.24 13:40, Peter Krempa wrote:
On Fri, Jan 05, 2024 at 13:33:32 +0100, Michal Privoznik wrote:
Introduced in v8.2.0-rc0~74^2~2, QEMU now allows setting
.dynamic-memslots attribute for virtio-mem-pci devices. When
turned on, it allows memory exposed to guest to be split into
multiple mems
On Fri, Jan 05, 2024 at 03:20:16 -0500, Laine Stump wrote:
> Rather than always binding to the vfio-pci driver, use the new
> function virPCIDeviceFindBestVFIOVariant() to see if the running
> kernel has a VFIO variant driver available that is a better match for
> the device, and if one is found, u
On Fri, Jan 05, 2024 at 14:34:53 +0100, David Hildenbrand wrote:
> On 05.01.24 13:40, Peter Krempa wrote:
> > On Fri, Jan 05, 2024 at 13:33:32 +0100, Michal Privoznik wrote:
> > > Introduced in v8.2.0-rc0~74^2~2, QEMU now allows setting
> > > .dynamic-memslots attribute for virtio-mem-pci devices.
On Fri, Jan 05, 2024 at 03:20:04 -0500, Laine Stump wrote:
> Historically libvirt hasn't differentiated between the name of a
> loadable kernel module, and the name of the device driver that module
> implements, but these two names can be (and usually are) at least
> subtly different.
>
> For exam
On 1/5/24 8:46 AM, Peter Krempa wrote:
On Fri, Jan 05, 2024 at 03:20:16 -0500, Laine Stump wrote:
Rather than always binding to the vfio-pci driver, use the new
function virPCIDeviceFindBestVFIOVariant() to see if the running
kernel has a VFIO variant driver available that is a better match for
On 1/5/24 7:36 AM, Peter Krempa wrote:
On Fri, Jan 05, 2024 at 03:20:15 -0500, Laine Stump wrote:
This patch makes it possible to manually specify which VFIO variant
driver to use for PCI hostdev device assignment, so that, e.g. you
could force use of a VFIO "variant" driver, with e.g.
or
On a Thursday in 2024, Peter Krempa wrote:
See 4/6 for docs, 6/6 for examples
Peter Krempa (6):
qemucapabilitiesdata: Add data for the qemu-9.0 development cycle
util: xml: Return GPtrArray from virXMLNodeGetSubelement
qemu: capabilities: Introduce QEMU_CAPS_VIRTIO_BLK_IOTHREAD_MAPPING
conf:
On a Thursday in 2024, Peter Krempa wrote:
Add validation and formatting of the commandline arguments for
'iothread-vq-mapping' parameter. The validation logic mirrors waht qemu
what
allows.
Signed-off-by: Peter Krempa
---
src/hypervisor/domain_driver.c | 15 -
src/qemu/qemu_command.c
On Fri, Jan 05, 2024 at 10:06:13 -0500, Laine Stump wrote:
> On 1/5/24 8:46 AM, Peter Krempa wrote:
> > On Fri, Jan 05, 2024 at 03:20:16 -0500, Laine Stump wrote:
> > > Rather than always binding to the vfio-pci driver, use the new
> > > function virPCIDeviceFindBestVFIOVariant() to see if the runn
On 1/5/24 9:22 AM, Peter Krempa wrote:
On Fri, Jan 05, 2024 at 03:20:04 -0500, Laine Stump wrote:
Historically libvirt hasn't differentiated between the name of a
loadable kernel module, and the name of the device driver that module
implements, but these two names can be (and usually are) at lea
On 1/5/24 10:30 AM, Peter Krempa wrote:
On Fri, Jan 05, 2024 at 10:06:13 -0500, Laine Stump wrote:
On 1/5/24 8:46 AM, Peter Krempa wrote:
On Fri, Jan 05, 2024 at 03:20:16 -0500, Laine Stump wrote:
Rather than always binding to the vfio-pci driver, use the new
function virPCIDeviceFindBestVFIOV
See 1/3 for details.
https://issues.redhat.com/browse/RHEL-7100
Jiri Denemark (3):
Introduce VIR_MIGRATE_POSTCOPY_PREEMPT flag
virsh migrate: Add --postcopy-preempt option
qemu_migration: Implement VIR_MIGRATE_POSTCOPY_PREEMPT
docs/manpages/virsh.rst | 9 ++---
include/libvi
During post-copy migration (once it actually switches to post-copy mode)
dirty memory pages are continued to be migrated iteratively, while the
destination can explicitly request a specific page to be migrated before
the iterative process gets to it (which happens when a guest wants to
read a page
Signed-off-by: Jiri Denemark
---
src/qemu/qemu_migration.c| 21 ++---
src/qemu/qemu_migration.h| 1 +
src/qemu/qemu_migration_params.c | 6 ++
src/qemu/qemu_migration_params.h | 1 +
4 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qe
This new option will enable VIR_MIGRATE_POSTCOPY_PREEMPT flag.
Signed-off-by: Jiri Denemark
---
docs/manpages/virsh.rst | 9 ++---
tools/virsh-domain.c| 6 ++
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst
index ed102
On a Friday in 2024, Jiri Denemark wrote:
See 1/3 for details.
https://issues.redhat.com/browse/RHEL-7100
Jiri Denemark (3):
Introduce VIR_MIGRATE_POSTCOPY_PREEMPT flag
virsh migrate: Add --postcopy-preempt option
qemu_migration: Implement VIR_MIGRATE_POSTCOPY_PREEMPT
docs/manpages/virsh.rs
On Fri, Jan 5, 2024 at 4:55 PM Jiri Denemark wrote:
> During post-copy migration (once it actually switches to post-copy mode)
> dirty memory pages are continued to be migrated iteratively, while the
> destination can explicitly request a specific page to be migrated before
> the iterative proces
On Fri, Jan 05, 2024 at 17:11:57 +0100, Peter Krempa wrote:
> On Fri, Jan 5, 2024 at 4:55 PM Jiri Denemark wrote:
>
> > During post-copy migration (once it actually switches to post-copy mode)
> > dirty memory pages are continued to be migrated iteratively, while the
> > destination can explicitl
On 05.01.24 14:58, Peter Krempa wrote:
On Fri, Jan 05, 2024 at 14:34:53 +0100, David Hildenbrand wrote:
On 05.01.24 13:40, Peter Krempa wrote:
On Fri, Jan 05, 2024 at 13:33:32 +0100, Michal Privoznik wrote:
Introduced in v8.2.0-rc0~74^2~2, QEMU now allows setting
.dynamic-memslots attribute fo
On Fri, Jan 05, 2024 at 03:20:04 -0500, Laine Stump wrote:
> Historically libvirt hasn't differentiated between the name of a
> loadable kernel module, and the name of the device driver that module
> implements, but these two names can be (and usually are) at least
> subtly different.
>
> For exam
On Fri, Jan 05, 2024 at 10:33:33 -0500, Laine Stump wrote:
> On 1/5/24 9:22 AM, Peter Krempa wrote:
> > On Fri, Jan 05, 2024 at 03:20:04 -0500, Laine Stump wrote:
[...]
> > > Change from V1: I tried to simplify the explanation in the commit log
> > > message
> >
> > I don't think this addresses
On 1/5/24 3:03 PM, Peter Krempa wrote:
On Fri, Jan 05, 2024 at 03:20:04 -0500, Laine Stump wrote:
Historically libvirt hasn't differentiated between the name of a
loadable kernel module, and the name of the device driver that module
implements, but these two names can be (and usually are) at lea
61 matches
Mail list logo
