virProcessKillPainfullyDelay() currently almost always returns 1 or -1,
even though the documentation indicates that it should return 0 if the
process was terminated gracefully. The only case that it currently
returns 0 is when it is called with the pid of a process that does not
exist.
This
Commit 93af79fb removed a cleanup label in favor of returning error
values directly in certain cases. But the final return value was changed
from -1 to 0. If we get to the end of the function, that means that
we've waited for the process to exit but it still exists. So we should
return -1. The
In a modular daemon configuration, virtxend does not support the
virNetwork* APIs. It should open a connection to virtnetworkd when
using those APIs, but currently always opens a connection to
"xen:///system". Switch to using virGetConnectNetwork to obtain a
valid connection instead of using the
On 9/21/23 1:10 PM, Peter Krempa wrote:
On Thu, Sep 21, 2023 at 12:50:52 -0500, Jonathon Jongsma wrote:
On 9/20/23 7:24 AM, Pavel Hrdina wrote:
On Thu, Aug 31, 2023 at 04:39:50PM -0500, Jonathon Jongsma wrote:
Add some helper functions to build a virCommand object and run the
nbdkit process
As of v9.4.0-rc2~5 it is possible to specify guest address where
a virtio-mem/virtio-pmem memory device is mapped to. What that
commit forgot to introduce was a check for overlaps.
And yes, this is technically an O(n^2) algorithm, as
virDomainMemoryDefValidate() is called over each memory device
QEMU mandates the VIRTIO_PMEM address is aligned to a pagesize.
This is a very reasonable requirement. So much so, that it
deserves to be in hypervisor agnostic validation code
(virDomainMemoryDefValidate()). Not that any other hypervisor
would support VIRTIO_PMEM yet. But even if they did, this
*** BLURB HERE ***
Michal Prívozník (3):
domain_validate: Validate VIRTIO_PMEM address alignment
virDomainMemoryDefValidate: Fix VIRTIO_MEM alignment check
virDomainMemoryDefValidate: Check for overlapping memory devices
src/conf/domain_validate.c| 59
Inside of virDomainMemoryDefValidate() there's a check that
address where a virtio-mem memory device is mapped to is a
multiple of its block size. But this check is off by a couple of
bits, because the memory address is in bytes while the block size
is in kibibytes. Therefore, when checking
On 9/22/23 15:26, Andrea Bolognani wrote:
> The current message can be misleading, because it seems to suggest
> that no firmware of the requested type is available on the system.
>
> What actually happens most of the time, however, is that despite
> having multiple firmwares of the right type to
On Fri, Sep 22, 2023 at 03:44:55PM +0200, Michal Prívozník wrote:
> On 9/22/23 15:26, Andrea Bolognani wrote:
> > src/qemu/qemu_firmware.c| 2 +-
> > .../firmware-auto-efi-loader-path-nonstandard.x86_64-latest.err | 2 +-
> >
The current message can be misleading, because it seems to suggest
that no firmware of the requested type is available on the system.
What actually happens most of the time, however, is that despite
having multiple firmwares of the right type to choose from, none
of them is suitable because of
On a Friday in 2023, Michal Privoznik wrote:
*** BLURB HERE ***
Michal Prívozník (3):
domain_validate: Validate VIRTIO_PMEM address alignment
virDomainMemoryDefValidate: Fix VIRTIO_MEM alignment check
virDomainMemoryDefValidate: Check for overlapping memory devices
12 matches
Mail list logo
