On 5/5/21 10:11 PM, Andrea Bolognani wrote:
> Plus a couple additional cleanups.
>
> Test pipeline: https://gitlab.com/abologna/libvirt/-/pipelines/297950317
>
> Andrea Bolognani (3):
> spec: Don't disable LTO in Fedora 34
> spec: Bump min_fedora and min_rhel
> spec: Drop supported_platform
> -Original Message-
> From: Qemu-riscv
> [mailto:qemu-riscv-bounces+jiangyifei=huawei@nongnu.org] On Behalf Of
> Anup Patel
> Sent: Friday, April 30, 2021 12:54 PM
> To: Jiangyifei
> Cc: Bin Meng ; open list:RISC-V
> ; Sagar Karandikar ;
> KVM General ; libvir-list@redhat.com; Basti
Hi all,
Sorry to bother again.
Since I'm new to the libvirt community, and also this is my first time to
submit patches, I'm truly sorry for the format problems that I emailed before.
Could you kindly help me review it again, and let me know if there is anything
I need to change.
For background
The 'below4g' attribute added in 'memory' element can be used to specify
the low memory area, which allows to get a larger PCI I/O window below
4G when reduce it to a smaller value, and when raise value allows legacy
non-PAE guests to have as much memory as possible in the 32bit address
space below
On Wed, May 05, 2021 at 04:58:02PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> We are going to deprecate drive-backup, so use modern interface here.
> In examples where target image creation is shown, show blockdev-add as
> well. If target creation omitted, omit blockdev-add as well.
>
> Signed-o
On Wed, May 05, 2021 at 04:58:03PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Modern way is using blockdev-add + blockdev-backup, which provides a
> lot more control on how target is opened.
>
> As example of drive-backup problems consider the following:
>
> User of drive-backup expects that ta
On 5/4/21 7:43 PM, Daniel P. Berrangé wrote:
> When creating the system identity set the system token. The system
> token is currently stored in a local path
>
>/var/run/libvirt/common/system.token
>
> Obviously with only traditional UNIX DAC in effect, this is largely
> security through obsc
On 5/4/21 7:43 PM, Daniel P. Berrangé wrote:
> The current identity object represents the identity of the application
> which initiated the currently executing public API operation. Normally
> this is the libvirt client application identity.
>
> There are times when the libvirt daemon has to make
On 5/4/21 7:43 PM, Daniel P. Berrangé wrote:
> If you define a secret with private="yes", then libvirt won't let any
> client query the secret value after it is set. Only other libvirt
> drivers inside the daemon can query it by passing a special internal
> only flag to the virSecretGetValue API. T
On 5/4/21 7:43 PM, Daniel P. Berrangé wrote:
> Signed-off-by: Daniel P. Berrangé
> ---
> src/util/viridentity.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/util/viridentity.c b/src/util/viridentity.c
> index 065db06e49..83044a3de1 100644
> --- a/src/util/viridentity.c
> +++
On Thu, May 06, 2021 at 12:13:01PM +0200, Michal Prívozník wrote:
> On 5/4/21 7:43 PM, Daniel P. Berrangé wrote:
> > When creating the system identity set the system token. The system
> > token is currently stored in a local path
> >
> >/var/run/libvirt/common/system.token
> >
> > Obviously w
On 5/5/21 12:55 PM, Tim Wiederhake wrote:
> For background, see
> https://listman.redhat.com/archives/libvir-list/2021-April/msg00668.html
>
> V1: https://listman.redhat.com/archives/libvir-list/2021-April/msg01184.html
> V2: https://listman.redhat.com/archives/libvir-list/2021-April/msg01238.html
Dear list,
in the light of recent development of secure virtualization (for instance AMD
SEV-SNP [1]) I'd like us to be prepared for when QEMU adopts these new
technologies and thus would like to discuss our options. So far, I've came
across AMD SEV-SNP [2]. While it's true that we do support SEV,
On a Tuesday in 2021, Tim Wiederhake wrote:
For background, see
https://listman.redhat.com/archives/libvir-list/2021-April/msg00668.html
Tim Wiederhake (10):
virDomainAudioIOCommon: Change type of format to virDomainAudioFormat
virDomainAudioCommonParse: Use virXMLProp*
virDomainMemballoonDef
On Thu, May 06, 2021 at 12:22:26PM +0200, Michal Prívozník wrote:
Hi,
(Just chiming in as a curious libvirt API user :-))
[...]
> This is where attestation comes to help - it enables the guest owner (which in
> this example is different to the one running it) verify - with cryptographic
> level
On Thu, May 06, 2021 at 12:22:26PM +0200, Michal Prívozník wrote:
> Dear list,
>
> in the light of recent development of secure virtualization (for instance AMD
> SEV-SNP [1]) I'd like us to be prepared for when QEMU adopts these new
> technologies and thus would like to discuss our options. So fa
On 5/4/21 4:02 PM, Tim Wiederhake wrote:
> For background, see
> https://listman.redhat.com/archives/libvir-list/2021-April/msg00668.html
>
> Note that patch #1 depends on
> https://listman.redhat.com/archives/libvir-list/2021-April/msg01260.html
> from part VII.
>
> Tim Wiederhake (10):
> virD
On 5/6/21 5:31 AM, Yanzheng (A) wrote:
> Introduce a new virDomainReloadTLSCertificates API for notify domain
> reload its certificates without restart, and avoid service interruption.
>
> Take reload QEMU VNC TLS certificates as an example, we can call:
>
> virDomainReloadTLSCertificates(dom,
On 5/6/21 6:35 AM, Kashyap Chamarthy wrote:
>> It looks like QEMU will expose commands needed for attestation via QMP [3].
>> But question then is, how to expose those at Libvirt level? Should we allow
>> users to bypass Libvirt and communicate to QEMU directly or wrap those QMPs
>> in
>> public A
On 5/6/21 6:51 AM, Daniel P. Berrangé wrote:
>> It looks like QEMU will expose commands needed for attestation via QMP [3].
>
> As mentioned in my reply to that thread, I believe we can already do
> pretty much all of that via a combination of libvirt APIs & guest XML.
This is not a good user exp
On Thu, May 06, 2021 at 08:04:44AM -0500, Connor Kuehl wrote:
> On 5/6/21 6:51 AM, Daniel P. Berrangé wrote:
> >> It looks like QEMU will expose commands needed for attestation via QMP [3].
> >
> > As mentioned in my reply to that thread, I believe we can already do
> > pretty much all of that via
On 5/6/21 8:32 AM, Daniel P. Berrangé wrote:
> On Thu, May 06, 2021 at 08:04:44AM -0500, Connor Kuehl wrote:
>> On 5/6/21 6:51 AM, Daniel P. Berrangé wrote:
It looks like QEMU will expose commands needed for attestation via QMP [3].
>>>
>>> As mentioned in my reply to that thread, I believe we
On Thu, May 06, 2021 at 08:43:53AM -0500, Connor Kuehl wrote:
> On 5/6/21 8:32 AM, Daniel P. Berrangé wrote:
> > On Thu, May 06, 2021 at 08:04:44AM -0500, Connor Kuehl wrote:
> >> On 5/6/21 6:51 AM, Daniel P. Berrangé wrote:
> It looks like QEMU will expose commands needed for attestation via
On 5/6/21 8:51 AM, Daniel P. Berrangé wrote:
>> I see. So it sounds like the way forward for libvirt is that it will
>> need to essentially duplicate the SEV-related QMP message types into its
>> own protocol since expecting the client to understand QMP discloses the
>> fact that the underlying hyp
On Thu, May 06, 2021 at 07:57:43AM -0500, Connor Kuehl wrote:
> On 5/6/21 6:35 AM, Kashyap Chamarthy wrote:
> >> It looks like QEMU will expose commands needed for attestation via QMP [3].
> >> But question then is, how to expose those at Libvirt level? Should we allow
> >> users to bypass Libvirt
This series enables and adds AddressSanitizer and UndefinedBehaviorSanitizer
builds to the CI.
See:
https://clang.llvm.org/docs/AddressSanitizer.html and
https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
These sanitizers already found some issues in libvirt, e.g.
4eb7c621985dad4de911ec3
When enabling sanitizers, gcc adds some instrumentation to the code
that may enlarge stack frames. Some function's stack frames are already
close to the limit of 4096 and are enlarged past that threshold,
e.g. virLXCProcessStart which reaches a frame size of 4624 bytes.
Signed-off-by: Tim Wiederha
When enabling sanitizers, clang adds some function symbols when
instrumenting the code. The exact names of those functions are an
implementation detail and should therefore not be added to any
syms file. This patch prevents build failures due to those symbols
not present in the syms file when build
When other preloaded libraries wrap and / or make calls to `realpath`
(e.g. LLVM's AddessSanitizer), the second parameter is no longer
guaranteed to be NULL.
Signed-off-by: Tim Wiederhake
---
build-aux/syntax-check.mk | 2 +-
tests/virfilemock.c | 20
2 files changed,
"virt-aa-helper" links, amongst others, against "datatypes.o" and
"libvirt.so". The latter links against "libvirt_driver.a" which in turn
also links against "datatypes.o", leading to a One-Definition-Rule
violoation for "virConnectClass" et al. in "datatypes.c".
Signed-off-by: Tim Wiederhake
Revi
Signed-off-by: Tim Wiederhake
---
src/libvirt_openvz.syms | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/libvirt_openvz.syms b/src/libvirt_openvz.syms
index ac0ed0d23e..a1038e51a4 100644
--- a/src/libvirt_openvz.syms
+++ b/src/libvirt_openvz.syms
@@ -3,10 +3,12 @@
#
# openvz/openvz
meson supports the following sanitizers: "address" (e.g. out-of-bounds
memory access, use-after-free, etc.), "thread" (data races), "undefined"
(e.g. signed integer overflow), and "memory" (use of uninitialized
memory). Note that not all sanitizers are supported by all compilers,
and that more sani
"openvzutilstest" links, amongst others, against "libvirt_openvz.a" and
"libvirt.so". The latter also links against "libvirt_openvz.a", leading
to a One-Definition-Rule violation for "openvzLocateConfFile" in
"openvz_conf.c".
Signed-off-by: Tim Wiederhake
---
tests/meson.build | 2 +-
1 file cha
On Thu, May 06, 2021 at 05:08:32PM +0200, Tim Wiederhake wrote:
> When enabling sanitizers, gcc adds some instrumentation to the code
> that may enlarge stack frames. Some function's stack frames are already
> close to the limit of 4096 and are enlarged past that threshold,
> e.g. virLXCProcessStar
Automatically free 'iothrid' and remove all the cleanup cruft.
Signed-off-by: Peter Krempa
---
src/conf/domain_conf.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index baf5d31606..78775bb2b3 100644
--- a/src/c
Set the backup mode to VIR_TRISTATE_BOOL_YES after virXMLPropTristateBool
left it set to VIR_TRISTATE_BOOL_ABSENT. This will allow fixing
virXMLPropTristateBool to always initialize @result.
Signed-off-by: Peter Krempa
---
src/conf/backup_conf.c | 5 +++--
1 file changed, 3 insertions(+), 2 dele
There are few cases where we set a default value when using
virXMLPropEnum which can be converted to virXMLPropEnumDefault.
Signed-off-by: Peter Krempa
---
src/conf/domain_conf.c | 74 +++---
1 file changed, 40 insertions(+), 34 deletions(-)
diff --git a/src/
Compilers aren't able to see whether @result is set or not and thus
don't warn of a potential use of uninitialized value. Always set @result
to prevent uninitialized use.
Signed-off-by: Peter Krempa
---
src/util/virxml.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
The helper is almost identical to virXMLPropEnum but it allows to pass a
default value to initialize the result to.
Signed-off-by: Peter Krempa
---
src/libvirt_private.syms | 1 +
src/util/virxml.c| 30 ++
src/util/virxml.h| 11 +++
3 files ch
Assign the vcpu count when virXMLPropUInt returns '0' meaning that the
cpu count was not present in the XML. This will allow to always
initialize the value of @result in virXMLPropUInt to prevent use of
uninitialized values.
Signed-off-by: Peter Krempa
---
src/conf/domain_conf.c | 8 +---
1
VIR_XML_PROP_NONE has value of 0 so it's pointless to include it in an
binary-or expression.
Signed-off-by: Peter Krempa
---
src/conf/domain_conf.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index a2dd7d649f..baf5d31606
virXMLPropTristateBool already initializes the value to
VIR_TRISTATE_BOOL_ABSENT so we no longer need to do that for certain
local variables.
Signed-off-by: Peter Krempa
---
src/conf/domain_conf.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/conf/domain_conf.c b/
virXMLPropTristateBool/virXMLPropTristateSwitch/virXMLPropEnum can be
implemented using the same internal code. Extract it into a new function
called virXMLPropEnumInternal, which will also simplify adding versions
of these functions with a custom default value.
This way we'll be able to always in
Compilers aren't able to see that the value passed via a pointer from
the new virXMLProp helpers may be uninitialized in certain cases.
Fix 3 such cases, prepare the code and then ensure that the new
virXMLProp* helpers always initialize the memory.
CI pipeline (once it finishes) can be viewed at
Register virDomainIOThreadIDDefFree to do the cleanup.
Signed-off-by: Peter Krempa
---
src/conf/domain_conf.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 64465dd8d6..2d5462bb55 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain
Compilers aren't able to see whether @result is set or not and thus
don't warn of a potential use of uninitialized value. Always set @result
to prevent uninitialized use.
This is done by adding a @defaultResult argument to virXMLPropInt since
many places have a non-0 default.
In certain cases suc
Compilers aren't able to see whether @result is set or not and thus
don't warn of a potential use of uninitialized value. Always set @result
to prevent uninitialized use.
Signed-off-by: Peter Krempa
---
src/util/virxml.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/util/virxml.c b/
Compilers aren't able to see whether @result is set or not and thus
don't warn of a potential use of uninitialized value. Always set @result
to prevent uninitialized use.
Signed-off-by: Peter Krempa
---
src/util/virxml.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/util/virxml.c b/
Commit 38180f87f5b converted the code to use virXMLPropEnum unfaithfully
ommitting the check where 'format' must be non-zero when parsed from the
user.
Signed-off-by: Peter Krempa
---
src/conf/domain_conf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/conf/domain_conf.
Compilers aren't able to see whether @result is set or not and thus
don't warn of a potential use of uninitialized value. Always set @result
to prevent uninitialized use.
In two cases the code needed to be adjusted to preserve functionality.
Signed-off-by: Peter Krempa
---
src/conf/domain_conf.
On Thu, May 06, 2021 at 05:08:33PM +0200, Tim Wiederhake wrote:
> When enabling sanitizers, clang adds some function symbols when
> instrumenting the code. The exact names of those functions are an
> implementation detail and should therefore not be added to any
> syms file. This patch prevents bui
Commit 8391cfbc2dbc converted the code to use virXMLPropEnum unfaithfully
ommitting the check where 'backend' must be non-zero when parsed from the
user.
Signed-off-by: Peter Krempa
---
src/conf/domain_conf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/conf/domain_con
Compilers aren't able to see whether @result is set or not and thus
don't warn of a potential use of uninitialized value. Always set @result
to prevent uninitialized use.
Signed-off-by: Peter Krempa
---
src/util/virxml.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/util/virxml.c b
On Thu, May 06, 2021 at 17:08:38 +0200, Tim Wiederhake wrote:
> meson supports the following sanitizers: "address" (e.g. out-of-bounds
> memory access, use-after-free, etc.), "thread" (data races), "undefined"
> (e.g. signed integer overflow), and "memory" (use of uninitialized
> memory). Note that
On 5/6/21 5:31 PM, Peter Krempa wrote:
> Compilers aren't able to see whether @result is set or not and thus
> don't warn of a potential use of uninitialized value. Always set @result
> to prevent uninitialized use.
>
> This is done by adding a @defaultResult argument to virXMLPropInt since
> many
On 5/6/21 5:30 PM, Peter Krempa wrote:
> Compilers aren't able to see that the value passed via a pointer from
> the new virXMLProp helpers may be uninitialized in certain cases.
>
> Fix 3 such cases, prepare the code and then ensure that the new
> virXMLProp* helpers always initialize the memory.
On Thu, May 06, 2021 at 19:07:59 +0200, Michal Prívozník wrote:
> On 5/6/21 5:31 PM, Peter Krempa wrote:
> > Compilers aren't able to see whether @result is set or not and thus
> > don't warn of a potential use of uninitialized value. Always set @result
> > to prevent uninitialized use.
> >
> > Th
On Wed, May 05, 2021 at 10:25:06 +0300, Gavi Teitz wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1925363
>
> Add support for setting the page-per-vq flag, which is important for
> vdpa with vhost-user performance.
>
> Signed-off-by: Gavi Teitz
> ---
> docs/formatdomain.rst
> -Original Message-
> From: Peter Krempa
> Sent: Thursday, May 6, 2021 8:16 PM
> To: Gavi Teitz
> Cc: libvir-list@redhat.com; Moshe Levi
> Subject: Re: [PATCH v2] Add page_per_vq flag to the 'driver' element of
> virtio devices
>
> External email: Use caution opening links or attach
On Thu, May 06, 2021 at 05:34:55PM +0200, Peter Krempa wrote:
> On Thu, May 06, 2021 at 17:08:38 +0200, Tim Wiederhake wrote:
> > meson supports the following sanitizers: "address" (e.g. out-of-bounds
> > memory access, use-after-free, etc.), "thread" (data races), "undefined"
> > (e.g. signed inte
60 matches
Mail list logo
