https://bugzilla.redhat.com/show_bug.cgi?id=1612009
Check sev capability pointer in function qemuGetSEVInfoToParams to avoid
null pointer dereferences.
Signed-off-by: Han Han
---
src/qemu/qemu_driver.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/qemu/qemu_driver.c
On Mon, 6 Aug 2018 23:45:21 +0530
Kirti Wankhede wrote:
> On 8/3/2018 11:26 PM, Alex Williamson wrote:
> > On Fri, 3 Aug 2018 12:07:58 +
> > "Wang, Zhi A" wrote:
> >
> >> Hi:
> >>
> >> Thanks for unfolding your idea. The picture is clearer to me now. I didn't
> >> realize that you also
On 8/3/2018 11:26 PM, Alex Williamson wrote:
> On Fri, 3 Aug 2018 12:07:58 +
> "Wang, Zhi A" wrote:
>
>> Hi:
>>
>> Thanks for unfolding your idea. The picture is clearer to me now. I didn't
>> realize that you also want to support cross hardware migration. Well, I
>> thought for a
Support the vhost-vsock-ccw device on S390.
Since v2
- instead of reusing CAPS_LATEST adding CAPS_ARCH_LATEST (Peter Krempa)
Since v1
- adjusted vsock command line generation (Ján Tomko)
- added CAPS_LATEST test coverage to s390 (Ján Tomko)
- adjusted new vsock tests to use CAPS_LATEST
Signed-off-by: Boris Fiuczynski
---
docs/news.xml | 8
1 file changed, 8 insertions(+)
diff --git a/docs/news.xml b/docs/news.xml
index afafb9c337..2f0c0107a9 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -46,6 +46,14 @@
+
+
+ qemu: Add
Add support and tests for vhost-vsock-ccw.
Signed-off-by: Boris Fiuczynski
---
src/qemu/qemu_command.c | 8 +++--
src/qemu/qemu_domain.c| 10 --
src/qemu/qemu_domain_address.c| 7 +++-
.../vhost-vsock-ccw-auto.s390x-latest.args
From: Bjoern Walk
Testing with the latest capabilities is possible with the x86_64 centric
implemented macro CAPS_LATEST. The new macro CAPS_ARCH_LATEST provides
the user the ability to specify the desired architecture when testing with
the latest capabilities.
Signed-off-by: Bjoern Walk
On Sat, Jul 28, 2018 at 11:31:40PM +0530, Sukrit Bhatnagar wrote:
> By making use of GNU C's cleanup attribute handled by the
> VIR_AUTOPTR macro for declaring aggregate pointer variables,
> majority of the calls to *Free functions can be dropped, which
> in turn leads to getting rid of most of
On Sat, Jul 28, 2018 at 11:31:39PM +0530, Sukrit Bhatnagar wrote:
> By making use of GNU C's cleanup attribute handled by the
> VIR_AUTOFREE macro for declaring scalar variables, majority
> of the VIR_FREE calls can be dropped, which in turn leads to
> getting rid of most of our cleanup sections.
On Sat, Jul 28, 2018 at 11:31:38PM +0530, Sukrit Bhatnagar wrote:
> By making use of GNU C's cleanup attribute handled by the
> VIR_AUTOPTR macro for declaring aggregate pointer variables,
> majority of the calls to *Free functions can be dropped, which
> in turn leads to getting rid of most of
On Sat, Jul 28, 2018 at 11:31:37PM +0530, Sukrit Bhatnagar wrote:
> Using the new VIR_DEFINE_AUTOPTR_FUNC macro defined in
> src/util/viralloc.h, define a new wrapper around an existing
> cleanup function which will be called when a variable declared
> with VIR_AUTOPTR macro goes out of scope.
Multiple cputune elements specified microseconds as the unit
without putting a space before the parenthesis.
There were also other occurrences.
Signed-off-by: Ján Tomko
---
Pushed as trivial.
docs/formatdomain.html.in | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
On Wed, Aug 01, 2018 at 12:37:13PM +0200, Katerina Koukiou wrote:
We need to first perform the checks for changed/missing elements
If we copy all the missing elements,
and then we can overwrite the missing ones. Otherwise we might
there's no need to overwrite them again.
falsely report
On Tue, Jul 31, 2018 at 09:36:26AM +0200, Katerina Koukiou wrote:
All rest of blkiotune parameters are not updatable through UpdateDeviceFlags
API.
s/All rest/The rest/
https://bugzilla.redhat.com/show_bug.cgi?id=1601677
Signed-off-by: Katerina Koukiou
---
The BZ was requesting to add
On Thu, Aug 02, 2018 at 05:07:33PM +0200, Jiri Denemark wrote:
When a domain is killed on the source host while it is being migrated
and libvirtd is waiting for the migration to finish (waiting for the
domain condition in qemuMigrationSrcWaitForCompletion), the run-time
state including
On Mon, Aug 06, 2018 at 01:20:23PM +0200, Christian Ehrhardt wrote:
> On Mon, Aug 6, 2018 at 11:03 AM Daniel P. Berrangé
> wrote:
>
> > On Mon, Aug 06, 2018 at 07:04:32AM +0200, Christian Ehrhardt wrote:
> > > On Sun, Aug 5, 2018 at 10:53 AM Daniel P. Berrangé
> > > wrote:
> > >
> > > > It is
On Mon, Aug 6, 2018 at 11:03 AM Daniel P. Berrangé
wrote:
> On Mon, Aug 06, 2018 at 07:04:32AM +0200, Christian Ehrhardt wrote:
> > On Sun, Aug 5, 2018 at 10:53 AM Daniel P. Berrangé
> > wrote:
> >
> > > It is increasingly likely that some distro is going to change the
> > > default "x86"
In cases where virProcessKillPainfully already reailizes that
SIGTERM wasn't enough we are on a bad path already.
Maybe the system is overloaded or having serious trouble to free and
reap resources in time.
In those case give the SIGKILL that was sent after 10 seconds some more
time to take
It was found that in cases with host devices virProcessKillPainfully
might be able to send signal zero to the target PID for quite a while
with the process already being gone from /proc/.
That is due to cleanup and reset of devices which might include a
secondary bus reset that on top of the
On Mon, Aug 6, 2018 at 10:47 AM Daniel P. Berrangé
wrote:
> On Mon, Aug 06, 2018 at 07:20:10AM +0200, Christian Ehrhardt wrote:
> > In that case I wonder what the libvirt community thinks of the proposed
> > general "Pid is gone means we can assume it is dead" approach?
>
> The key thing with
On 07/31/2018 10:44 AM, c...@lse.epita.fr wrote:
> From: Clementine Hayat
>
> Hello,
>
> This is the implementation of the iscsi-direct backend storage pool
> version 3.
>
> v1: https://www.redhat.com/archives/libvir-list/2018-July/msg00918.html
> v2:
On Mon, Aug 06, 2018 at 12:01:03PM +0200, Michal Prívozník wrote:
> On 08/06/2018 10:30 AM, Daniel P. Berrangé wrote:
>
> >>
> >> So do we really need virtlockd for this? I mean, the whole purpose of it
> >> is to hold locks so that libvirtd can restart independently, without
> >> losing the lock
On 08/06/2018 10:30 AM, Daniel P. Berrangé wrote:
>>
>> So do we really need virtlockd for this? I mean, the whole purpose of it
>> is to hold locks so that libvirtd can restart independently, without
>> losing the lock attached. However, since the metadata lock will be held
>> only for a
Okay it took a bit longer than usual but the relrase is out, it's tagged
in git and signed tarball and rpms have been pushed to the usual place, but
there was quite a few bug fixes going in after RC2 was cut.
ftp://libvirt.org/libvirt/
I also made libvirt-python 4.6.0 bindings release in a
On Fri, 2018-08-03 at 13:59 +0100, Daniel P. Berrangé wrote:
> It is increasingly likely that some distro is going to change the
> default "x86" machine type in QEMU from "pc" to "q35". This will
> certainly break existing applications which write their XML on the
> assumption that its using a
On Mon, Aug 06, 2018 at 10:03:52AM +0100, Daniel P. Berrangé wrote:
> There's multiple things at play. First all the canonical machine type
> names which are versioned
>
> pc-i440fx-2.5.0
> pc-i440fx-2.6.0
> pc-i440fx-2.7.0
> ...
> pc-i440fx-2.10.0
> pc-q35-2.5.0
> pc-q35-2.6.0
>
On Mon, Aug 06, 2018 at 10:31:07AM +0200, Martin Kletzander wrote:
> The proper file that should be included is `sys/xattr.h` as that comes from
> `glibc` and not `attr/xattr.h` which ships with the `attr` utility.
>
> We're most probably not the only ones because `attr/xattr.h` added a #warning
On Mon, Aug 06, 2018 at 07:04:32AM +0200, Christian Ehrhardt wrote:
> On Sun, Aug 5, 2018 at 10:53 AM Daniel P. Berrangé
> wrote:
>
> > It is increasingly likely that some distro is going to change the
> > default "x86" machine type in QEMU from "pc" to "q35". This will
> > certainly break
On Mon, Aug 06, 2018 at 07:20:10AM +0200, Christian Ehrhardt wrote:
> In that case I wonder what the libvirt community thinks of the proposed
> general "Pid is gone means we can assume it is dead" approach?
The key thing with the shutdown process is that we use the dissapperance of
the PID as the
On Thu, Aug 02, 2018 at 09:35:49AM +0200, Michal Privoznik wrote:
> If nbits is 64 (or greater) then shifting 1ULL left is undefined.
>
> Signed-off-by: Michal Privoznik
> ---
> src/util/virrandom.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git
On Wed, Aug 01, 2018 at 12:53:24PM +0200, Peter Krempa wrote:
> Explicitly call virJSONInitialize at startup of the libvirt daemon so
> that we are sure that the symbols in the compat library are properly
> loaded. This will prevent any random failure from happening later on
> when the daemon
On Sun, Aug 05, 2018 at 05:42:02PM +0530, Sukrit Bhatnagar wrote:
> On Fri, 3 Aug 2018 at 19:02, Erik Skultety wrote:
> >
> > On Sat, Jul 28, 2018 at 11:31:32PM +0530, Sukrit Bhatnagar wrote:
> > > By making use of GNU C's cleanup attribute handled by the
> > > VIR_AUTOFREE macro for declaring
The proper file that should be included is `sys/xattr.h` as that comes from
`glibc` and not `attr/xattr.h` which ships with the `attr` utility.
We're most probably not the only ones because `attr/xattr.h` added a #warning to
their include resulting in the following compilation errors:
In file
On Mon, Aug 06, 2018 at 10:02:44AM +0200, Michal Prívozník wrote:
> On 07/27/2018 11:01 AM, Daniel P. Berrangé wrote:
> > On Fri, Jul 27, 2018 at 09:56:23AM +0200, Michal Privoznik wrote:
> >> Dear list,
> >>
> >> we have this very old bug [1] that I just keep pushing in front of me. I
> >> made
On Fri, Aug 03, 2018 at 10:56:40PM +0530, Sukrit Bhatnagar wrote:
> On Fri, 3 Aug 2018 at 18:49, Erik Skultety wrote:
> >
> > On Sat, Jul 28, 2018 at 11:31:31PM +0530, Sukrit Bhatnagar wrote:
> > > By making use of GNU C's cleanup attribute handled by the
> > > VIR_AUTOPTR macro for declaring
On 07/27/2018 11:01 AM, Daniel P. Berrangé wrote:
> On Fri, Jul 27, 2018 at 09:56:23AM +0200, Michal Privoznik wrote:
>> Dear list,
>>
>> we have this very old bug [1] that I just keep pushing in front of me. I
>> made several attempts to fix it. However, none of them made into the
>> tree. I
36 matches
Mail list logo
