On Wed, Jul 29, 2020 at 10:38 AM Pavel Hrdina wrote:
>
> The second time around I will not post the complete series as it doesn't
> make that much sense. Instead I'll post a diff between the two series to
> provide the changes between these series together with links to both
> versions pushed to
We do not auto-align down pSeries NVDIMMs anymore.
This reverts commit 8f474ceea05aec349be19726e394a62e300efe77.
Signed-off-by: Daniel Henrique Barboza
---
docs/formatdomain.html.in | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/docs/formatdomain.html.in
After the recent changes, this function is now always returning
zero. Turn it to 'void' to relieve callers from checking it.
Signed-off-by: Daniel Henrique Barboza
---
src/qemu/qemu_domain.c | 4 +---
src/qemu/qemu_domain.h | 4 ++--
src/qemu/qemu_hotplug.c | 6 ++
3 files changed, 5
Next patch will use it outside of qemu_domain.c.
Signed-off-by: Daniel Henrique Barboza
---
src/qemu/qemu_domain.c | 2 +-
src/qemu/qemu_domain.h | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 2058290870..dfe3c3b64b
We don't need the auto-alignment now that the user is handling
it by hand.
Signed-off-by: Daniel Henrique Barboza
---
src/qemu/qemu_domain.c | 51 --
1 file changed, 4 insertions(+), 47 deletions(-)
diff --git a/src/qemu/qemu_domain.c
The existing auto-align behavior for pSeries has the idea to
alleviate user configuration of the NVDIMM size, given that the
alignment calculation is not trivial to do (256MiB alignment
of mem->size - mem->label_size value, a.k.a guest area). We
align mem->size down to avoid end of file problems.
Hi,
In [1] Andrea proposed that we should *not* auto-align down
the NVDIMM size for pSeries guests. Instead we should error
out and provide users with a suggested aligned value. This
patch implements it.
[1] https://www.redhat.com/archives/libvir-list/2020-July/msg01471.html
Daniel Henrique
On 7/30/20 6:41 PM, Nicolás Brignone wrote:
Hi!
Is this going to be merged? Do I need to do something else?
Thanks!
Hi, unfortunately it missed the feature freeze for the upcoming release.
We are expecting the release to happen by start of the next week. I will
merge it afterwards.
On Thu, 30 Jul 2020 11:41:04 +0800
Yan Zhao wrote:
> On Wed, Jul 29, 2020 at 01:12:55PM -0600, Alex Williamson wrote:
> > On Wed, 29 Jul 2020 12:28:46 +0100
> > Sean Mooney wrote:
> >
> > > On Wed, 2020-07-29 at 16:05 +0800, Yan Zhao wrote:
> > > > On Mon, Jul 27, 2020 at 04:23:21PM -0600,
Hi!
Is this going to be merged? Do I need to do something else?
Thanks!
On Fri, Jul 24, 2020 at 5:08 PM Jonathon Jongsma
wrote:
> On Wed, 2020-07-22 at 14:56 -0300, Nicolas Brignone wrote:
> > Existing virDomainDefPostParseGraphics function seems to be the right
> > place to put this
On 7/30/20 10:49 AM, Peter Krempa wrote:
QEMU is going to drop 'vxhs' in the upcomming release so we'll need to
upcoming
track these separately to prevent test suite breakage.
Signed-off-by: Peter Krempa
---
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
On 7/30/20 10:49 AM, Peter Krempa wrote:
We already test with real caps so there's no real need for this special
case. While it technically tested the state without TLS encryption key
secrets, it doesn't really matter that much.t
s/t&//
Signed-off-by: Peter Krempa
---
--
Eric Blake,
On 7/30/20 5:49 PM, Peter Krempa wrote:
Peter Krempa (4):
tests: qemuxml2argv: Use only modern versions of
'disk-network-tlsx509' test
tests: qemu: Split NBD and VXHS protocol tests
tests: qemuxml2argv: Lock in "disk-network-tlsx509-vxhs" case to
qemu-5.0.0
tests:
On 7/30/20 2:03 PM, Hao Wang wrote:
From: Hao Wang
Subject: [PATCH] virNodeDevPCICapSRIOVVirtualParseXML: fix memleak of addr
virPCIDeviceAddressPtr 'addr' is forgotten to be freed in the branch
'VIR_APPEND_ELEMENT() < 0'. Use g_autoptr instead.
Signed-off-by: Hao Wang
---
We already test with real caps so there's no real need for this special
case. While it technically tested the state without TLS encryption key
secrets, it doesn't really matter that much.t
Signed-off-by: Peter Krempa
---
.../disk-network-tlsx509.args | 56 ---
QEMU 5.1 will drop the vxhs driver.
Signed-off-by: Peter Krempa
---
...-latest.args => disk-network-tlsx509-vxhs.x86_64-5.0.0.args} | 2 +-
tests/qemuxml2argvtest.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
rename
QEMU is going to drop 'vxhs' in the upcomming release so we'll need to
track these separately to prevent test suite breakage.
Signed-off-by: Peter Krempa
---
tests/qemusecuritytest.c | 3 +-
...isk-network-tlsx509-nbd.x86_64-2.12.0.args | 43 +++
On 30.07.2020 17:56, Peter Krempa wrote:
> On Thu, Jul 30, 2020 at 17:27:35 +0300, Nikolay Shirokovskiy wrote:
>> Most of bitmap setBit/clearBit/getBit users know that the bitmap index is
>> not out of bound and thus don't check the return value. More precisely
>> the stats is next:
>>
>>
Peter Krempa (4):
tests: qemuxml2argv: Use only modern versions of
'disk-network-tlsx509' test
tests: qemu: Split NBD and VXHS protocol tests
tests: qemuxml2argv: Lock in "disk-network-tlsx509-vxhs" case to
qemu-5.0.0
tests: qemucapabitilies: Bump for 5.1 caps to rc2 for x86_64
On 7/30/20 5:23 PM, Peter Krempa wrote:
Note that 'numa-mem-supported' turned off for certain machine types
which in turn forced us to generate a newer command line in certain
tests.
Signed-off-by: Peter Krempa
---
.../caps_5.1.0.x86_64.replies | 3644 ++---
On Thu, Jul 30, 2020 at 17:23:49 +0200, Peter Krempa wrote:
> Note that 'numa-mem-supported' turned off for certain machine types
> which in turn forced us to generate a newer command line in certain
> tests.
>
> Signed-off-by: Peter Krempa
> ---
> .../caps_5.1.0.x86_64.replies
On Thu, Jul 30, 2020 at 17:27:35 +0300, Nikolay Shirokovskiy wrote:
> Most of bitmap setBit/clearBit/getBit users know that the bitmap index is
> not out of bound and thus don't check the return value. More precisely
> the stats is next:
>
> Methodall check
>
On Thu, Jul 30, 2020 at 17:27:36 +0300, Nikolay Shirokovskiy wrote:
What's the justification for this change? We enforce the return value
check so that the caller is aware that it can fail.
Signed-off-by: Peter Krempa
---
NEWS.rst | 20
1 file changed, 20 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index 8b53d21b8a..1e4c4df1d6 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -31,6 +31,16 @@ v6.6.0 (unreleased)
Specifying a virtualHW version greater or equal to
On Thu, Jul 30, 2020 at 01:19:54PM +0200, Peter Krempa wrote:
> On Wed, Jul 29, 2020 at 16:38:20 +0200, Pavel Hrdina wrote:
> > The second time around I will not post the complete series as it doesn't
> > make that much sense. Instead I'll post a diff between the two series to
> > provide the
On 30 July 2020 17:17:56 GMT+03:00, Andrea Bolognani wrote:
>
>That makes sense. The Web UI provides links to all other instances of
>a certain task when it gets rescheduled, however, so I wonder whether
>the API also exposes that information and whether cirrus-run would be
>able to "chase" after
Signed-off-by: Nikolay Shirokovskiy
---
src/conf/capabilities.c | 2 +-
src/conf/checkpoint_conf.c| 2 +-
src/conf/domain_addr.c| 6 +++---
src/conf/domain_conf.c| 4 ++--
src/conf/node_device_conf.c | 2 +-
src/conf/snapshot_conf.c |
Signed-off-by: Nikolay Shirokovskiy
---
src/qemu/qemu_migration_cookie.c | 4 ++--
src/qemu/qemu_migration_params.c | 10 +-
src/util/virbitmap.h | 2 +-
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/qemu/qemu_migration_cookie.c
Signed-off-by: Nikolay Shirokovskiy
---
src/conf/domain_addr.c | 2 +-
src/conf/domain_conf.c | 5 ++---
src/network/bridge_driver.c | 4 ++--
src/qemu/qemu_capabilities.c | 2 +-
src/qemu/qemu_domain.c | 2 +-
src/qemu/qemu_driver.c | 2 +-
Most of bitmap setBit/clearBit/getBit users know that the bitmap index is
not out of bound and thus don't check the return value. More precisely
the stats is next:
Methodall check
===
virBitmapSetBit85 14
virBitmapClearBit 15
On Thu, 2020-07-30 at 15:59 +0200, Pavel Hrdina wrote:
> On Thu, Jul 30, 2020 at 03:04:37PM +0200, Andrea Bolognani wrote:
> > If you
> > look at this recent pipeline
> >
> > https://gitlab.com/libvirt/libvirt/-/pipelines/170028119
> >
> > you'll see that the x86-freebsd-12-build job has
On Thu, Jul 30, 2020 at 03:59:17PM +0200, Pavel Hrdina wrote:
> On Thu, Jul 30, 2020 at 03:04:37PM +0200, Andrea Bolognani wrote:
> > On Thu, 2020-07-30 at 13:58 +0300, Vitaly Potyarkin wrote:
> > > Hello, my name is Vitaly - I'm the author of cirrus-run.
> > >
> > > I was amazed to see that a
On Thu, Jul 30, 2020 at 03:04:37PM +0200, Andrea Bolognani wrote:
> On Thu, 2020-07-30 at 13:58 +0300, Vitaly Potyarkin wrote:
> > Hello, my name is Vitaly - I'm the author of cirrus-run.
> >
> > I was amazed to see that a project of such importance and scale uses the
> > tool I created! Thank
On Thu, Jul 30, 2020 at 01:58:28PM +0300, Vitaly Potyarkin wrote:
> Hello, my name is Vitaly - I'm the author of cirrus-run.
>
> I was amazed to see that a project of such importance and scale uses the
> tool I created! Thank you very much! I never expected it to receive much
> recognition
On Thu, 2020-07-30 at 11:41 +0800, Yan Zhao wrote:
> > > >interface_version=3
> >
> > Not much granularity here, I prefer Sean's previous
> > .[.bugfix] scheme.
> >
>
> yes, .[.bugfix] scheme may be better, but I'm not sure if
> it works for a complicated scenario.
> e.g for pv_mode,
> (1)
On Thu, 2020-07-30 at 09:56 +0800, Yan Zhao wrote:
> On Wed, Jul 29, 2020 at 12:28:46PM +0100, Sean Mooney wrote:
> > On Wed, 2020-07-29 at 16:05 +0800, Yan Zhao wrote:
> > > On Mon, Jul 27, 2020 at 04:23:21PM -0600, Alex Williamson wrote:
> > > > On Mon, 27 Jul 2020 15:24:40 +0800
> > > > Yan
On Thu, 2020-07-30 at 13:58 +0300, Vitaly Potyarkin wrote:
> Hello, my name is Vitaly - I'm the author of cirrus-run.
>
> I was amazed to see that a project of such importance and scale uses the
> tool I created! Thank you very much! I never expected it to receive much
> recognition outside of a
From: Hao Wang
Subject: [PATCH] virNodeDevPCICapSRIOVVirtualParseXML: fix memleak of addr
virPCIDeviceAddressPtr 'addr' is forgotten to be freed in the branch
'VIR_APPEND_ELEMENT() < 0'. Use g_autoptr instead.
Signed-off-by: Hao Wang
---
src/conf/node_device_conf.c | 6 ++
1 file changed,
On Wed, Jul 29, 2020 at 16:38:20 +0200, Pavel Hrdina wrote:
> The second time around I will not post the complete series as it doesn't
> make that much sense. Instead I'll post a diff between the two series to
> provide the changes between these series together with links to both
> versions pushed
Hello, my name is Vitaly - I'm the author of cirrus-run.
I was amazed to see that a project of such importance and scale uses the
tool I created! Thank you very much! I never expected it to receive much
recognition outside of a few random hobbyists, after all I wrote it just
to cheap out on CI
On Tue, Jul 28, 2020 at 06:58:42PM +0400, Roman Bogorodskiy wrote:
> Allow to map sound playback and recording devices to host devices
> using "" OSS audio backend.
>
> Signed-off-by: Roman Bogorodskiy
> ---
> src/bhyve/bhyve_command.c | 37 +--
>
On 7/30/20 12:30 PM, Peter Krempa wrote:
This patchset:
1) converts the 'kbase' directory page to RST
2) increases width of the container holding the kbase articles:
before:
https://libvirt.org/kbase.html
after:
On Tue, Jul 28, 2020 at 06:58:43PM +0400, Roman Bogorodskiy wrote:
> Signed-off-by: Roman Bogorodskiy
> ---
> tests/virschematest.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Reviewed-by: Daniel P. Berrangé
Regards,
Daniel
--
|: https://berrange.com -o-
On Tue, Jul 28, 2020 at 06:58:41PM +0400, Roman Bogorodskiy wrote:
> Introduce a new device element "" which allows
> to map guest sound device specified using the ""
> element to specific audio backend.
>
> Example:
>
>
>
>
>
>
>
>
>
> This block maps to OSS audio
On Tue, Jul 28, 2020 at 06:58:40PM +0400, Roman Bogorodskiy wrote:
> bhyve supports intel hda sound devices that could be specified
> on the command like using "-1:0,hda,play=$play_dev,rec=$rec_dev",
> where "1:0" is a PCI address, and "$play_dev" and "$rec_dev"
> point to the playback and
Signed-off-by: Peter Krempa
---
docs/kbase.html.in | 54 --
docs/kbase.rst | 43
docs/meson.build | 2 +-
3 files changed, 44 insertions(+), 55 deletions(-)
delete mode 100644 docs/kbase.html.in
create mode
Set the width to our default value of 70em (max 95%) to prevent
unnecessary line breaks if we have just one panel as it's in the kbase
directory.
Signed-off-by: Peter Krempa
---
docs/kbase.rst | 2 +-
docs/libvirt.css | 8
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git
This patchset:
1) converts the 'kbase' directory page to RST
2) increases width of the container holding the kbase articles:
before:
https://libvirt.org/kbase.html
after:
https://pipo.sk.gitlab.io/-/libvirt/-/jobs/663385238/artifacts/website/kbase.html
3) ports 'debuglogs' wiki
Provide debug log configuration insight in our kbase.
There are two modifications of the document compared to the wiki
version:
1) The link for reporting a bug agains libvirt was modified to use the
gitlab issue tracker.
2) The link to URI specification details is changed to 'https'
On 7/24/20 8:48 AM, Han Han wrote:
Signed-off-by: Han Han
---
docs/formatdomain.html.in | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Reviewed-by: Michal Privoznik
Michal
On 7/29/20 8:03 PM, Daniel P. Berrangé wrote:
If a Ctrl-C arrives while we are in the middle of executing the
virDomainCreateXML call, we will have no "virDomainPtr" object
available, but QEMU may none the less be running.
This means we'll never try to stop the QEMU process before we
honour the
On 7/29/20 6:56 PM, Daniel P. Berrangé wrote:
There is a race between vir_event_thread_finalize and
virEventThreadWorker in releasing the last reference on
the GMainContext. If virEventThreadDataFree() runs after
vir_event_thread_finalize releases its reference, then
it will release the last
On 7/29/20 9:51 PM, Laine Stump wrote:
I thought about not pushing this until after the freeze is over and
6.7.0 is released (since it is a bug, but a bug that's been in the code
for 9 years), but in the end decided to push it, because 1) it's a
bonafide leak in the *non*-error path of a
On 7/29/20 6:10 PM, Daniel P. Berrangé wrote:
A while ago Cole reported that libvirt is exposing a long
term bug in GLib's event loop that results in non-deterministic
crashes:
https://www.redhat.com/archives/libvir-list/2020-February/msg00422.html
I kept forgetting to investigate it until
54 matches
Mail list logo
