On a Thursday in 2021, Kristina Hanicova wrote:
Signed-off-by: Kristina Hanicova
---
tools/virsh-completer-domain.c | 72 ++
tools/virsh-completer-domain.h | 8 +++-
tools/virsh-domain.c | 1 +
3 files changed, 79 insertions(+), 2 deletions(-)
diff
On Mon, 15 Feb 2021 18:22:41 +0100
Erik Skultety wrote:
> On Wed, Feb 03, 2021 at 11:38:47AM -0600, Jonathon Jongsma wrote:
> > Add two flag values for virConnectListAllNodeDevices() so that we
> > can list only node devices that are active or inactive.
> >
> > Signed-off-by: Jonathon Jongsma
Signed-off-by: Kristina Hanicova
---
tools/virsh-completer-domain.c | 72 ++
tools/virsh-completer-domain.h | 8 +++-
tools/virsh-domain.c | 1 +
3 files changed, 79 insertions(+), 2 deletions(-)
diff --git a/tools/virsh-completer-domain.c
On Wed, 17 Feb 2021 14:35:51 +0100
Erik Skultety wrote:
> > +static void
> > +mdevctlEventHandleCallback(GFileMonitor *monitor G_GNUC_UNUSED,
> > + GFile *file,
> > + GFile *other_file G_GNUC_UNUSED,
> > +
On Thu, Feb 18, 2021 at 16:50:43 +0100, Peter Krempa wrote:
> On Thu, Feb 18, 2021 at 15:54:37 +0100, Jiri Denemark wrote:
> > On Thu, Feb 11, 2021 at 16:37:57 +0100, Peter Krempa wrote:
> > > Preserve block dirty bitmaps after migration with
> > > QEMU_MONITOR_MIGRATE_NON_SHARED_(DISK|INC).
> > >
On Thu, Feb 18, 2021 at 14:31:08 +0100, Michal Privoznik wrote:
> This commit adds new memorydevices.rst page which should serve
> all models of memory devices. Yet, I'm documenting virtio-mem
> quirks only.
>
> Signed-off-by: Michal Privoznik
> ---
> docs/kbase/index.rst | 4 +
>
On Thu, Feb 18, 2021 at 14:31:05 +0100, Michal Privoznik wrote:
> If the QEMU driver restarts it loses the track of the actual size
> of virtio-mem (because it's runtime type of information and thus
> not stored in XML) and therefore, we have to refresh it when
> reconnecting to the domain
On Thu, Feb 18, 2021 at 14:31:06 +0100, Michal Privoznik wrote:
s/update-memory/update-memory-device/ in subject
> New 'update-memory' command is introduced which aims on making it
and here.
> user friendly to change device. So far I just need to
> change so I'm introducing --requested-size
On Thu, Feb 18, 2021 at 14:31:04 +0100, Michal Privoznik wrote:
> New event is introduced that is emitted whenever guest
> acknowledges allocation change request of a virtio-mem.
> The aim is to let applications know when that happens,
> because changes in allocation are not synchronous with
>
On Thu, Feb 11, 2021 at 16:37:58 +0100, Peter Krempa wrote:
> For incremental backup we need QEMU_CAPS_BLOCKDEV,
> QEMU_CAPS_BLOCKDEV_REOPEN, QEMU_CAPS_MIGRATION_PARAM_BLOCK_BITMAP_MAPPING.
>
> Signed-off-by: Peter Krempa
> ---
> src/qemu/qemu_capabilities.c | 6 --
> 1 file changed, 4
On Thu, Feb 18, 2021 at 15:54:37 +0100, Jiri Denemark wrote:
> On Thu, Feb 11, 2021 at 16:37:57 +0100, Peter Krempa wrote:
> > Preserve block dirty bitmaps after migration with
> > QEMU_MONITOR_MIGRATE_NON_SHARED_(DISK|INC).
> >
> > This patch implements functions which offer the bitmaps to the
>
On Thu, Feb 18, 2021 at 14:31:00 +0100, Michal Privoznik wrote:
> The virtio-mem is paravirtualized mechanism of adding/removing
> memory to/from a VM. A virtio-mem-pci device is split into blocks
> of equal size which are then exposed (all or only a requested
> portion of them) to the guest
On 18.02.21 14:31, Michal Privoznik wrote:
The virtio-mem is paravirtualized mechanism of adding/removing
memory to/from a VM. A virtio-mem-pci device is split into blocks
of equal size which are then exposed (all or only a requested
portion of them) to the guest kernel to use as regular memory.
On Thu, Feb 11, 2021 at 16:37:57 +0100, Peter Krempa wrote:
> Preserve block dirty bitmaps after migration with
> QEMU_MONITOR_MIGRATE_NON_SHARED_(DISK|INC).
>
> This patch implements functions which offer the bitmaps to the
> destination, check for eligibility on destination and then configure
>
On Thu, Feb 18, 2021 at 02:55:25PM +0100, Ján Tomko wrote:
> Ján Tomko (4):
> security: dac: remove leftover virPCIDeviceFree
> qemu: saveimage: only steal domXML on success
> qemu: monitor: clear cpu props properly in CPUInfoClear
> hyperv: check return value of virUUIDGenerate
>
>
On Thu, Feb 18, 2021 at 14:30:56 +0100, Michal Privoznik wrote:
> New virHostMemGetTHPSize() is introduced which allows caller to
> obtain THP PMD (Page Middle Directory) size, which is equal to
> the minimal size that THP can use, taken from kernel doc
>
The comment and the caller assume virQEMUSaveDataNew only steals
domXML on success, but it is copied even on failure.
Also remove the misleading g_steal_pointer call on a local variable.
Reported by coverity.
Signed-off-by: Ján Tomko
---
src/qemu/qemu_saveimage.c | 3 +--
1 file changed, 1
The switch to g_auto left this one call behind.
Reported by Coverity.
Fixes: 4ab0d1844a1e60def576086edc8b2c3775e7c10d
Signed-off-by: Ján Tomko
---
src/security/security_dac.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/security/security_dac.c
Fixes: fa66bd8cad2359b7d21676e0fd69bec472b36514
Signed-off-by: Ján Tomko
---
src/hyperv/hyperv_driver.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/hyperv/hyperv_driver.c b/src/hyperv/hyperv_driver.c
index c1ed4b5c7c..701456cdb3 100644
---
Stay true to the name of the function and clear the pointer
after freeing it.
This also silences a bogus Coverity report about a double
free in qemuMonitorGetCPUInfo where qemuMonitorCPUInfoClear
is called right after allocating a new qemuMonitorCPUInfo
to fill out the non-zero defaults.
Ján Tomko (4):
security: dac: remove leftover virPCIDeviceFree
qemu: saveimage: only steal domXML on success
qemu: monitor: clear cpu props properly in CPUInfoClear
hyperv: check return value of virUUIDGenerate
src/hyperv/hyperv_driver.c | 4 +++-
src/qemu/qemu_monitor.c | 1 +
Signed-off-by: Michal Privoznik
---
NEWS.rst | 7 +++
1 file changed, 7 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index 440dbf2601..abb3f5d867 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -47,6 +47,13 @@ v7.1.0 (unreleased)
to set the hostdev device's MAC address (which is a necessary
New 'update-memory' command is introduced which aims on making it
user friendly to change device. So far I just need to
change so I'm introducing --requested-size only; but
the idea is that this is extensible for other cases too. For
instance, want to change ? A new --my-element
argument can be
If the QEMU driver restarts it loses the track of the actual size
of virtio-mem (because it's runtime type of information and thus
not stored in XML) and therefore, we have to refresh it when
reconnecting to the domain monitor.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_domain.c |
This commit adds new memorydevices.rst page which should serve
all models of memory devices. Yet, I'm documenting virtio-mem
quirks only.
Signed-off-by: Michal Privoznik
---
docs/kbase/index.rst | 4 +
docs/kbase/memorydevices.rst | 160 +++
Nothing special is happening here. All important changes were
done when for 'virtio-pmem' (adjusting the code to put virtio
memory on PCI bus, generating alias using
qemuDomainDeviceAliasIndex(). The only bit that might look
suspicious is no prealloc for virtio-mem. But if you think about
it, the
New event is introduced that is emitted whenever guest
acknowledges allocation change request of a virtio-mem.
The aim is to let applications know when that happens,
because changes in allocation are not synchronous with
issuing the request. Under the hood, the event is
emitted whenever QEMU emits
As advertised in one of previous commits, we want to be able to
change 'requested-size' attribute of virtio-mem on the fly. This
commit does exactly that. Changing anything else is checked for
and forbidden.
Once guest has changed the allocation, QEMU emits an event which
we will use to track the
As advertised in previous commit, this event is delivered to us
when virtio-mem module changes the allocation inside the guest.
It comes with one attribute - size - which holds the new size of
the virtio-mem (well, allocated size), in bytes.
Mind you, this is not necessarily the same number as
This commit introduces a new capability that reflects virtio-mem-pci
device support in QEMU:
QEMU_CAPS_DEVICE_VIRTIO_MEM_PCI, /* -device virtio-mem-pci */
The virtio-mem-pci device was introduced in QEMU 5.1.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_capabilities.c
The aim of this function is to return whether domain definition
and/or memory device that user intents to hotplug needs a private
path inside cfg->memoryBackingDir. The rule for the memory device
that's being hotplug includes checking whether corresponding
guest NUMA node needs memoryBackingDir.
The virtio-mem is paravirtualized mechanism of adding/removing
memory to/from a VM. A virtio-mem-pci device is split into blocks
of equal size which are then exposed (all or only a requested
portion of them) to the guest kernel to use as regular memory.
Therefore, the device has two important
Resend of:
https://listman.redhat.com/archives/libvir-list/2021-February/msg00534.html
We had couple of changes made (new capabilities added mostly) and the
original patch set no long applies cleanly. This is pure rebase of the
original patch set, no functional change (hence I'm keeping version
The aim of qemuProcessNeedHugepagesPath() is to return whether
guest needs private path inside HugeTLBFS mounts (deducted from
domain definition @def) or whether the memory device that user is
hotplugging in needs the private path (deducted from the @mem
argument). The actual creation of the path
New virHostMemGetTHPSize() is introduced which allows caller to
obtain THP PMD (Page Middle Directory) size, which is equal to
the minimal size that THP can use, taken from kernel doc
(Documentation/admin-guide/mm/transhuge.rst):
Some userspace (such as a test program, or an optimized memory
On 2/18/21 9:52 AM, John Ferlan wrote:
On 2/18/21 7:33 AM, Daniel Henrique Barboza wrote:
Commit 76f47889326c4 made qemuNodeDeviceDetachFlags() unusable due to an
'if then else if' chain that will always results in a 'return -1',
regardless of 'driverName' input. This slipped through
Reported by Coverity.
Fixes: 213662813cd846d045be8857dc7b917d33a40989
Signed-off-by: Ján Tomko
---
Pushed as trivial.
src/esx/esx_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/esx/esx_driver.c b/src/esx/esx_driver.c
index e49975de86..96cc8bda0d 100644
---
On 2/18/21 7:33 AM, Daniel Henrique Barboza wrote:
> Commit 76f47889326c4 made qemuNodeDeviceDetachFlags() unusable due to an
> 'if then else if' chain that will always results in a 'return -1',
> regardless of 'driverName' input. This slipped through review process
> and Gitlab CI, making it
On a Thursday in 2021, Daniel Henrique Barboza wrote:
Commit 76f47889326c4 made qemuNodeDeviceDetachFlags() unusable due to an
'if then else if' chain that will always results in a 'return -1',
regardless of 'driverName' input. This slipped through review process
and Gitlab CI, making it clear
Commit 76f47889326c4 made qemuNodeDeviceDetachFlags() unusable due to an
'if then else if' chain that will always results in a 'return -1',
regardless of 'driverName' input. This slipped through review process
and Gitlab CI, making it clear now that there is no unit tests
exercising this code ATM.
On 2/18/21 8:30 AM, John Ferlan wrote:
On 2/2/21 8:06 PM, Daniel Henrique Barboza wrote:
The validation of 'driverName' does not depend on any other state and can be
done right on the start of the function. We can fail earlier while avoiding
a cleanup jump.
Reviewed-by: Ján Tomko
On 2/2/21 8:06 PM, Daniel Henrique Barboza wrote:
> The validation of 'driverName' does not depend on any other state and can be
> done right on the start of the function. We can fail earlier while avoiding
> a cleanup jump.
>
> Reviewed-by: Ján Tomko
> Signed-off-by: Daniel Henrique Barboza
On Thu, Feb 11, 2021 at 16:37:56 +0100, Peter Krempa wrote:
> In case when the block migration job required temporary bitmaps for
> merging the appropriate checkpoints we need to clean them up when
> cancelling the job. On success we don't need to do that though as the
> bitmaps are just temporary
On Thu, Feb 11, 2021 at 16:37:53 +0100, Peter Krempa wrote:
> Add status XML infrastructure for storing a list of block dirty bitmaps
> which are temporarily used when migrating a VM with
> VIR_MIGRATE_NON_SHARED_DISK for cleanup after a libvirtd restart during
> migration.
>
> Signed-off-by:
On Thu, Feb 11, 2021 at 16:37:52 +0100, Peter Krempa wrote:
> 'qemuMigrationCookieBlockDirtyBitmapsMatchDisks' maps the bitmaps from
> the migration cookie to actual disk objects definition pointers.
>
> 'qemuMigrationCookieBlockDirtyBitmapsToParams' converts the bitmap
> definitions from the
On Thu, Feb 11, 2021 at 16:37:51 +0100, Peter Krempa wrote:
> In cases where we are copying the storage we need to ensure that also
> bitmaps are copied properly. This patch adds migration cookie XML
> infrastructure which will allow the migration sides reach consensus on
> which bitmaps to
On Thu, Feb 11, 2021 at 16:37:55 +0100, Peter Krempa wrote:
> Test the XML infrastructure for migration cookie
> element as well as the conversion to migration parameters for QMP schema
> validation.
>
> Signed-off-by: Peter Krempa
> ---
> tests/meson.build | 2 +-
On Thu, Feb 11, 2021 at 16:37:54 +0100, Peter Krempa wrote:
> The XML sample shows the status XML when migrating with bitmaps
> including the element added in previous commit.
>
> It will also be used for the migration cookie test.
>
> Signed-off-by: Peter Krempa
> ---
>
We are getting close to the next release of libvirt. To aim for the
release on Mar 01 I suggest entering the freeze on Monday Feb 22 and
tagging RC2 on Thursday Feb 25.
I hope this works for everyone.
Jirka
49 matches
Mail list logo
