On Wed, Feb 02, 2022 at 08:17:53AM +0100, Michal Prívozník wrote:
On 2/2/22 01:06, Martin Kletzander wrote:
On Tue, Feb 01, 2022 at 05:23:33PM +0100, Tim Wiederhake wrote:
On Tue, 2022-02-01 at 16:07 +, Daniel P. Berrangé wrote:
On Tue, Feb 01, 2022 at 03:25:55PM +0100, Martin Kletzander
On 2/2/22 06:00, Michal Privoznik wrote:
When virNodeDeviceObjListRemove() is called, the passed
virNodeDeviceObj is removed from internal list of node devices
and then unrefed and unlocked. While the former is warranted (the
object was refed at the beginning of the function) the unlock is
> The reason is that when somebody backports these patches onto one
of previous releases then they would get needless conflict only because
of this file.
Ack, I'll make a note of that for the future changes, thanks guiding me
with this!
Best Regards,
Dmitrii Shcherbakov
LP/MM/oftc: dmitriis
On
Hi Michal,
No problem, thanks for coming back to re-review it, I also acknowledge
that it was late in the year and during the holiday season so things
got slower.
> and if you agree, I'd squash them in respective commits and merge.
I looked at the fixup commits - I agree with the changes and
On 2/1/22 09:28, Dmitrii Shcherbakov wrote:
> SmartNIC DPUs may not expose some privileged eswitch operations
> to the hypervisor hosts. For example, this happens with Bluefield
> devices running in the ECPF (default) mode [1] for security reasons. While
> VF MAC address programming is possible
On 2/1/22 09:28, Dmitrii Shcherbakov wrote:
> SmartNIC DPUs may not expose some privileged eswitch operations
> to the hypervisor hosts. For example, this happens with Bluefield
> devices running in the ECPF (default) mode for security reasons. While
> VF MAC address programming is possible via an
On 2/1/22 09:28, Dmitrii Shcherbakov wrote:
> There should be a way to show no intent in programming a VLAN at all
> (including clearing it). This allows handling error conditions
> differently when VLAN clearing is explicit (vlan id == 0) vs implicit
> (vlanid == NULL - try to clear it if
On 2/1/22 09:28, Dmitrii Shcherbakov wrote:
> This has a benefit of being able to handle error codes for those
> operations separately which is useful when drivers allow setting a MAC
> address but do not allow setting a VLAN (which is the case with some
> SmartNIC DPUs).
>
> Signed-off-by:
On Wed, Feb 02, 2022 at 05:39:20PM +0100, Ján Tomko wrote:
> Ján Tomko (2):
> ch: virCHMonitorGetIOThreads: fix g_steal_pointer usage
> ch: virCHProcessSetupIOThreads: use correct type for return value
>
> src/ch/ch_monitor.c | 2 +-
> src/ch/ch_process.c | 6 --
> 2 files changed, 5
Fixes: 81226d88034fd460855ac75dd2c985ca91ff6219
Signed-off-by: Ján Tomko
---
src/ch/ch_monitor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/ch/ch_monitor.c b/src/ch/ch_monitor.c
index 4d5d2c69b8..60905e36c2 100644
--- a/src/ch/ch_monitor.c
+++ b/src/ch/ch_monitor.c
Ján Tomko (2):
ch: virCHMonitorGetIOThreads: fix g_steal_pointer usage
ch: virCHProcessSetupIOThreads: use correct type for return value
src/ch/ch_monitor.c | 2 +-
src/ch/ch_process.c | 6 --
2 files changed, 5 insertions(+), 3 deletions(-)
--
2.34.1
virCHMonitorGetIOThreads returns an int, not size_t.
Also return early if it's negative, because promoting it to
an unsigned type in the for loop condition could lead to
an infinte loop.
Signed-off-by: Ján Tomko
---
src/ch/ch_process.c | 6 --
1 file changed, 4 insertions(+), 2
Access to /proc/[pid]/exe may be restricted in certain environments (e.g.
in containers) and any attempt to stat(2) or readlink(2) the file will
result in 'permission denied' error if the calling process does not have
CAP_SYS_PTRACE capability. According to proc(5) manpage:
Permission to
The binary validation in virPidFileReadPathIfAlive may fail with EACCES
if the calling process does not have CAP_SYS_PTRACE capability.
Therefore instead do only the check that the pidfile is locked by the
correct process.
Fixes the same issue as with swtpm.
Signed-off-by: Vasiliy Ulyanov
---
[v1] https://listman.redhat.com/archives/libvir-list/2022-January/msg8.html
[v2] https://listman.redhat.com/archives/libvir-list/2022-January/msg00582.html
As suggesed in the review comments:
- dropped virFileGetLockOwner;
- simplified lock validation by using VIR_AUTOCLOSE and just trying to
The function will attempt to read a pid from @path, and store it in
@pid. The @pid will only be set, however, if @path is locked by
virFileLock() at byte 0 and the pid in @path is running.
Signed-off-by: Vasiliy Ulyanov
---
src/libvirt_private.syms | 1 +
src/util/virpidfile.c| 34
On Wed, Feb 02, 2022 at 07:47:37AM -0800, Andrea Bolognani wrote:
> On Wed, Feb 02, 2022 at 03:38:59PM +, Daniel P. Berrangé wrote:
> > On Wed, Feb 02, 2022 at 06:46:25AM -0800, Andrea Bolognani wrote:
> > > I think it would still make sense to reflect QEMU's current default
> > > in the XML,
On Wed, Feb 02, 2022 at 03:38:59PM +, Daniel P. Berrangé wrote:
> On Wed, Feb 02, 2022 at 06:46:25AM -0800, Andrea Bolognani wrote:
> > I think it would still make sense to reflect QEMU's current default
> > in the XML, which would make sure that the same input XML results in
> > the same
On Wed, Feb 02, 2022 at 06:46:25AM -0800, Andrea Bolognani wrote:
> On Wed, Feb 02, 2022 at 02:32:32PM +, Daniel P. Berrangé wrote:
> > On Wed, Feb 02, 2022 at 06:29:32AM -0800, Andrea Bolognani wrote:
> > > On Wed, Feb 02, 2022 at 12:44:44PM +, Daniel P. Berrangé wrote:
> > > > Introduce
On 2/2/22 15:59, Andrea Bolognani wrote:
> This is a perfectly valid configuration that we need to keep
> working, so add test coverage for it.
>
> Signed-off-by: Andrea Bolognani
> ---
> .../memory-hotplug-virtio-mem.x86_64-latest.args | 3 ++-
>
On Wed, Feb 02, 2022 at 06:57:09AM -0800, Andrea Bolognani wrote:
> I was imagining some change happening in the future under the
> assumption that memory devices will only ever be plugged into
> pci(e).0: the current test suite would not catch that, but if we had
> at least one case in which a
This is a perfectly valid configuration that we need to keep
working, so add test coverage for it.
Signed-off-by: Andrea Bolognani
---
.../memory-hotplug-virtio-mem.x86_64-latest.args | 3 ++-
tests/qemuxml2argvdata/memory-hotplug-virtio-mem.xml | 7 ++-
2 files changed, 8
On Wed, Feb 02, 2022 at 03:11:03PM +0100, Michal Prívozník wrote:
> On 2/2/22 14:34, Andrea Bolognani wrote:
> > On Wed, Feb 02, 2022 at 02:26:23PM +0100, Michal Prívozník wrote:
> >> On 2/2/22 13:44, Andrea Bolognani wrote:
> >>> Maybe we should add a test case where the memory device is not on
On 2/2/22 13:28, Andrea Bolognani wrote:
> Test pipeline: https://gitlab.com/abologna/libvirt/-/pipelines/461702102
>
> The Ubuntu failures are due to connection issues and should be
> transient; all RPM builds passed.
>
> Andrea Bolognani (3):
> rpm: List one more directory
> meson: Sort
On Wed, Feb 02, 2022 at 02:32:32PM +, Daniel P. Berrangé wrote:
> On Wed, Feb 02, 2022 at 06:29:32AM -0800, Andrea Bolognani wrote:
> > On Wed, Feb 02, 2022 at 12:44:44PM +, Daniel P. Berrangé wrote:
> > > Introduce support for
> > >
> > >
> > >
> > >
> > >
> > >
>
On Wed, Feb 02, 2022 at 12:44:45PM +, Daniel P. Berrangé wrote:
> +++ b/tests/qemuxml2argvdata/serial-debugcon.xml
> @@ -0,0 +1,29 @@
> +
> + QEMUGuest1
> + c7a5fdbd-edaf-9455-926a-d65c16db1809
> + 219136
> + 219136
> + 1
> +
> +hvm
> +
> +
> +
> + destroy
> + restart
> +
On Wed, Feb 02, 2022 at 06:29:32AM -0800, Andrea Bolognani wrote:
> On Wed, Feb 02, 2022 at 12:44:44PM +, Daniel P. Berrangé wrote:
> > Introduce support for
> >
> >
> >
> >
> >
> >
> >
> >
> > which is used as a way to receive debug messages from the
> > firmware
On Wed, Feb 02, 2022 at 12:44:44PM +, Daniel P. Berrangé wrote:
> Introduce support for
>
>
>
>
>
>
>
>
> which is used as a way to receive debug messages from the
> firmware on x86 platforms.
>
> Note that the default port is 0x0xe9 since that's the original
>
On 2/2/22 14:34, Andrea Bolognani wrote:
> On Wed, Feb 02, 2022 at 02:26:23PM +0100, Michal Prívozník wrote:
>> On 2/2/22 13:44, Andrea Bolognani wrote:
>>> Maybe we should add a test case where the memory device is not on the
>>> root bus? We can't catch the QEMU error of course, but that would
On Wed, Feb 02, 2022 at 12:44:43PM +, Daniel P. Berrangé wrote:
> The serial port model cannot be allowed to change across migration
> as it affects ABI.
>
> Signed-off-by: Daniel P. Berrangé
> ---
> src/conf/domain_conf.c | 8
> 1 file changed, 8 insertions(+)
Reviewed-by: Andrea
On Wed, Feb 02, 2022 at 02:26:23PM +0100, Michal Prívozník wrote:
> On 2/2/22 13:44, Andrea Bolognani wrote:
> > Maybe we should add a test case where the memory device is not on the
> > root bus? We can't catch the QEMU error of course, but that would at
> > least serve as some sort of implicit
On 2/2/22 13:44, Andrea Bolognani wrote:
> On Thu, Jan 27, 2022 at 02:47:43PM +0100, Michal Privoznik wrote:
>> Currently, memory device (def->mems) part of cmd line is
>> generated before any controller. In majority of cases it doesn't
>> matter because neither of memory devices live on a bus
Hi Michal,
I think it probably makes sense then to just do the lock checking specifically
for tpm and gpu cases and not to change the behavior of
virPidFileReadPathIfAlive (since it is used in several places in the project).
Thank you for the review. I will also follow your other suggestions and
The XML-to-XML test validates that we don't accidentally copy the
isa-debug into a .
Signed-off-by: Daniel P. Berrangé
---
.../serial-debugcon.x86_64-latest.args| 39 +
tests/qemuxml2argvdata/serial-debugcon.xml| 29 +
tests/qemuxml2argvtest.c
Introduce support for
which is used as a way to receive debug messages from the
firmware on x86 platforms.
Note that the default port is 0x0xe9 since that's the original
Bochs debug port. Thus for use with SeaBIOS/OVMF, the iobase
port needs to be explicitly set to
The serial port model cannot be allowed to change across migration
as it affects ABI.
Signed-off-by: Daniel P. Berrangé
---
src/conf/domain_conf.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 58e696416d..9415ecb13b 100644
---
# virsh dumpxml fedora34x86_64 | xmllint -xpath '/domain/devices/console[2]' -
# virsh console --devname console1 fedora34x86_64
Of course you really want to start the guest paused initially to allow
time to connect to the console before resuming CPUs,
On Thu, Jan 27, 2022 at 02:47:43PM +0100, Michal Privoznik wrote:
> Currently, memory device (def->mems) part of cmd line is
> generated before any controller. In majority of cases it doesn't
> matter because neither of memory devices live on a bus that's
> created by an exposed controller (e.g.
On Wed, Feb 02, 2022 at 02:51:55AM -0800, Andrea Bolognani wrote:
> On Wed, Feb 02, 2022 at 09:46:47AM +0100, Michal Prívozník wrote:
> > On 2/1/22 18:50, Andrea Bolognani wrote:
> > > Andrea Bolognani (3):
> > > rpm: Move /etc/libvirt from -daemon to -libs
> > > rpm: Move /var/lib/libvirt
We recently started listing these in the spec file and, since we
were not creating them during the installation phase, that broke
RPM builds.
Fixes: 4b43da0bff9b78dcf1189388d4c89e524238b41d
Signed-off-by: Andrea Bolognani
---
src/ch/meson.build | 1 +
src/interface/meson.build | 4
This will make subsequent patches nicer.
Signed-off-by: Andrea Bolognani
---
src/libxl/meson.build | 2 +-
src/lxc/meson.build | 2 +-
src/qemu/meson.build | 8
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/libxl/meson.build b/src/libxl/meson.build
index
Commit 4b43da0bff9b missed it.
Signed-off-by: Andrea Bolognani
---
libvirt.spec.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 4a56ace1d6..0cbdd45baf 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -1910,6 +1910,7 @@ exit 0
%ghost %dir
Test pipeline: https://gitlab.com/abologna/libvirt/-/pipelines/461702102
The Ubuntu failures are due to connection issues and should be
transient; all RPM builds passed.
Andrea Bolognani (3):
rpm: List one more directory
meson: Sort virt_install_dirs
meson: Add missing virt_install_dirs
On 1/17/22 16:50, Andrea Bolognani wrote:
>
>
> Andrea Bolognani (2):
> qemu: Correctly translate QEMU_AUDIO_DRV=wav
> qemu: Drop qemuAudioDriver enumeration
>
> src/qemu/qemu_command.c | 46 +
> src/qemu/qemu_command.h | 3 +++
>
On Wed, Feb 02, 2022 at 09:46:47AM +0100, Michal Prívozník wrote:
> On 2/1/22 18:50, Andrea Bolognani wrote:
> > With respect to the permissions topic mentioned in patch 3/3, I'm
> > currently working on some patches that aim to improve that situation
> > as well.
> >
> > Andrea Bolognani (3):
> >
On 1/13/22 13:42, Vasiliy Ulyanov wrote:
> The function is used to retrieve the PID of the process holding an
> exclusive lock on the file.
>
> Signed-off-by: Vasiliy Ulyanov
> ---
> src/libvirt_private.syms | 1 +
> src/util/virfile.c | 45
>
On 1/13/22 13:42, Vasiliy Ulyanov wrote:
> If the binary path is not provided check that the pid file is locked by
> the owner process.
>
> Signed-off-by: Vasiliy Ulyanov
> ---
> src/util/virpidfile.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git
On 1/13/22 13:42, Vasiliy Ulyanov wrote:
> Access to /proc/[pid]/exe may be restricted in certain environments (e.g.
> in containers) and any attempt to stat(2) or readlink(2) the file will
> result in 'permission denied' error if the calling process does not have
> CAP_SYS_PTRACE capability.
On Fri, Jan 28, 2022 at 09:58:45PM +0100, Ján Tomko wrote:
> -int virParseVersionString(const char *str,
> - unsigned long *version,
> +int virStringParseVersion(unsigned long *version,
> + const char *str,
>bool
On Thu, Jan 27, 2022 at 07:22:50PM +0100, Ján Tomko wrote:
> Report an error upfront if the binary does not exist
> or is not executable.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1999372
>
> Signed-off-by: Ján Tomko
> ---
> src/qemu/qemu_virtiofs.c | 7 +++
> 1 file changed, 7
On Mon, Jan 17, 2022 at 04:50:45PM +0100, Andrea Bolognani wrote:
> Andrea Bolognani (2):
> qemu: Correctly translate QEMU_AUDIO_DRV=wav
> qemu: Drop qemuAudioDriver enumeration
>
> src/qemu/qemu_command.c | 46 +
> src/qemu/qemu_command.h | 3 +++
>
On 2/1/22 15:33, Lubomir Rintel wrote:
> My day started like this:
>
> # virt-install --connect qemu:///system --arch mips --machine malta
> --memory 256 --disk none --import
> Using default --name vm-mips
>
> Starting install...
> ERRORXML error: No PCI buses available
>
>
When virNodeDeviceObjListRemove() is called, the passed
virNodeDeviceObj is removed from internal list of node devices
and then unrefed and unlocked. While the former is warranted (the
object was refed at the beginning of the function) the unlock is
not. In fact, it's wrong from conceptual POV. We
On 2/1/22 18:50, Andrea Bolognani wrote:
> With respect to the permissions topic mentioned in patch 3/3, I'm
> currently working on some patches that aim to improve that situation
> as well.
>
> Andrea Bolognani (3):
> rpm: Move /etc/libvirt from -daemon to -libs
> rpm: Move /var/lib/libvirt
54 matches
Mail list logo
