Markus Armbruster writes:
> This series extends QMP introspection to cover deprecation.
> Additionally, new option -compat lets you configure what to do when
> deprecated interfaces get used. This is intended for testing users of
> the management interfaces. It is experimental.
>
> -compat depr
Ping
Also CC'ing Shiva since he implemented the QEMU side of this feature and
might be interested in it.
Shiva, mind tossing a review in patch 3/5? This is the one that contains
the alignment logic and I'd like to be certain that I didn't mess it up.
Thanks,
DHB
On 3/11/20 6:29 PM, Daniel
On Tue, Mar 17, 2020 at 05:25:38PM +0100, Pino Toscano wrote:
It seems like CD-ROMs may have no 'fileName' property specified in case
there is nothing configured as attachment for the drive. Hence, make
sure that virVMXParseDisk() do not consider it mandatory anymore,
considering it an empty bloc
On 17. 3. 2020 17:39, Julio Faracco wrote:
> I'm good with that.
> I verified other resources that use rtc... they are checking for rtc0.
> Thanks, Michal
>
Cool, I've fixed patches (actually I did slightly change them to make it
easier to add new timer) and pushed.
Reviewed-by: Michal Privoznik
Introduce new 'multidevs' option for filesystem.
This option prevents misbheaviours on guest if a 9pfs export
contains multiple devices, due to the potential file ID collisions
this otherwise may cause.
Signed-off-by: Christian Schoenebeck
---
docs/formatdomain.html.in | 47
QEMU 4.2 added a new option 'multidevs' for 9pfs. The following patch adds
support for this new option to libvirt.
In short, what is this about: to distinguish files uniquely from each other
in general, numeric file IDs are typically used for comparison, which in
practice is the combination of a f
The loop which checks whether the vcpus are in proper configuration for
the requested hot(un)plug skips the first modified vcpu. This means
that 'firstvcpu' which is used to print the error message in case the
configuration is not suitable would never point to the first modified
vcpu.
In cases suc
On Tue, Mar 17, 2020 at 05:25:38PM +0100, Pino Toscano wrote:
> It seems like CD-ROMs may have no 'fileName' property specified in case
> there is nothing configured as attachment for the drive. Hence, make
> sure that virVMXParseDisk() do not consider it mandatory anymore,
> considering it an empt
On a Tuesday in 2020, Pino Toscano wrote:
It seems like CD-ROMs may have no 'fileName' property specified in case
there is nothing configured as attachment for the drive. Hence, make
sure that virVMXParseDisk() do not consider it mandatory anymore,
considering it an empty block cdrom device. Sadl
I'm good with that.
I verified other resources that use rtc... they are checking for rtc0.
Thanks, Michal
--
Julio Cesar Faracco
Em ter., 17 de mar. de 2020 às 12:32, Michal Prívozník
escreveu:
>
> On 17. 3. 2020 14:41, Julio Faracco wrote:
> > Hi Michal,
> >
> > /dev/rtc symlink is created by u
It seems like CD-ROMs may have no 'fileName' property specified in case
there is nothing configured as attachment for the drive. Hence, make
sure that virVMXParseDisk() do not consider it mandatory anymore,
considering it an empty block cdrom device. Sadly virVMXParseDisk() is
used also to parse di
On Thu, Mar 12, 2020 at 02:28:22PM -0500, Eric Blake wrote:
> Creating an image that requires format probing of the backing image is
> inherently unsafe (we've had several CVEs over the years based on
> probes leaking information to the guest on a subsequent boot, although
> these days tools like l
On 3/17/20 10:11 AM, Daniel P. Berrangé wrote:
On Tue, Mar 17, 2020 at 03:07:34PM +, Peter Maydell wrote:
On Tue, 17 Mar 2020 at 15:05, Daniel P. Berrangé wrote:
On Tue, Mar 17, 2020 at 03:00:48PM +, Peter Maydell wrote:
On Tue, 17 Mar 2020 at 14:57, Daniel P. Berrangé wrote:
I don
On 17. 3. 2020 14:41, Julio Faracco wrote:
> Hi Michal,
>
> /dev/rtc symlink is created by udev default rules.
> Maybe we can check for both: /dev/rtc and /dev/rtc0.
I think it's safe to rely on default udev behavior and just create rtc0.
What do you think? No need to send another version, I can
Marc-André Lureau writes:
> Hi
>
> On Tue, Mar 17, 2020 at 12:55 PM Markus Armbruster wrote:
>>
>> This series extends QMP introspection to cover deprecation.
>> Additionally, new option -compat lets you configure what to do when
>> deprecated interfaces get used. This is intended for testing u
On Tue, Mar 17, 2020 at 04:05:12PM +0100, Peter Krempa wrote:
> String list was allocated without extra element.
>
> Peter Krempa (3):
> qemuBlockBitmapsHandleCommitStart: Fix allocation of string list
> qemuBlockBitmapsHandleCommitFinish: Use proper variable to iterate
> qemublocktest: Add
On a Tuesday in 2020, Peter Krempa wrote:
String list was allocated without extra element.
Peter Krempa (3):
qemuBlockBitmapsHandleCommitStart: Fix allocation of string list
qemuBlockBitmapsHandleCommitFinish: Use proper variable to iterate
qemublocktest: Add tests for re-enabling of bitmaps
On a Tuesday in 2020, Peter Krempa wrote:
The function repeatedly checked the first element rather than interating
iterating
through the array.
Reported-by: Daniel P. Berrangé
Signed-off-by: Peter Krempa
---
src/qemu/qemu_block.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Jano
On Tue, Mar 17, 2020 at 03:07:34PM +, Peter Maydell wrote:
> On Tue, 17 Mar 2020 at 15:05, Daniel P. Berrangé wrote:
> >
> > On Tue, Mar 17, 2020 at 03:00:48PM +, Peter Maydell wrote:
> > > On Tue, 17 Mar 2020 at 14:57, Daniel P. Berrangé
> > > wrote:
> > > > I don't feel like -Wno-unuse
On Tue, 17 Mar 2020 at 15:05, Daniel P. Berrangé wrote:
>
> On Tue, Mar 17, 2020 at 03:00:48PM +, Peter Maydell wrote:
> > On Tue, 17 Mar 2020 at 14:57, Daniel P. Berrangé
> > wrote:
> > > I don't feel like -Wno-unused-function looses anything significant, as
> > > the GCC builds will still
Allocate space also for the terminating NULL.
Reported-by: Daniel P. Berrangé
Signed-off-by: Peter Krempa
---
src/qemu/qemu_block.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qemu/qemu_block.c b/src/qemu/qemu_block.c
index cc2edff5e0..115682c39d 100644
--- a/src/qem
The function repeatedly checked the first element rather than interating
through the array.
Reported-by: Daniel P. Berrangé
Signed-off-by: Peter Krempa
---
src/qemu/qemu_block.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qemu/qemu_block.c b/src/qemu/qemu_block.c
ind
Some branches were not covered and thus we didn't catch that the bitmaps
are not re-enabled if nothing is merged into them. Two bitmaps are
necessary to reliably test the case due to hash table ordering.
Signed-off-by: Peter Krempa
---
.../bitmap/snapshots-synthetic-broken.json| 18
String list was allocated without extra element.
Peter Krempa (3):
qemuBlockBitmapsHandleCommitStart: Fix allocation of string list
qemuBlockBitmapsHandleCommitFinish: Use proper variable to iterate
qemublocktest: Add tests for re-enabling of bitmaps after commit
src/qemu/qemu_block.c
On Tue, Mar 17, 2020 at 03:00:48PM +, Peter Maydell wrote:
> On Tue, 17 Mar 2020 at 14:57, Daniel P. Berrangé wrote:
> > I don't feel like -Wno-unused-function looses anything significant, as
> > the GCC builds will still be reporting unused functions which will
> > catch majority of cases.
>
On Tue, 17 Mar 2020 at 14:57, Daniel P. Berrangé wrote:
> I don't feel like -Wno-unused-function looses anything significant, as
> the GCC builds will still be reporting unused functions which will
> catch majority of cases.
The most interesting difference is that clang will catch unused
static i
On Tue, Mar 17, 2020 at 09:40:00AM -0500, Eric Blake wrote:
> On 3/17/20 9:00 AM, Peter Maydell wrote:
> > On Tue, 17 Mar 2020 at 04:38, John Snow wrote:
>
> > >
> > >block/qcow2-bitmap: use bdrv_dirty_bitmap_next_dirty (2020-03-12
> > > 16:36:46 -0400)
> > >
> > >
On 3/17/20 9:00 AM, Peter Maydell wrote:
On Tue, 17 Mar 2020 at 04:38, John Snow wrote:
block/qcow2-bitmap: use bdrv_dirty_bitmap_next_dirty (2020-03-12 16:36:46
-0400)
Pull request
---
On Tue, 17 Mar 2020 at 04:38, John Snow wrote:
>
> The following changes since commit 6e8a73e911f066527e775e04b98f31ebd19db600:
>
> Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request'
> into staging (2020-03-11 14:41:27 +)
>
> are available in the Git repository at:
>
>
Hi Michal,
/dev/rtc symlink is created by udev default rules.
Maybe we can check for both: /dev/rtc and /dev/rtc0.
--
Julio Cesar Faracco
Em seg., 16 de mar. de 2020 às 15:16, Michal Prívozník
escreveu:
>
> On 2. 3. 2020 1:54, Julio Faracco wrote:
> > This commit share host Real Time Clock devi
Hi
On Tue, Mar 17, 2020 at 12:55 PM Markus Armbruster wrote:
>
> This series extends QMP introspection to cover deprecation.
> Additionally, new option -compat lets you configure what to do when
> deprecated interfaces get used. This is intended for testing users of
> the management interfaces.
On Tue, Mar 17, 2020 at 12:06:45PM +0100, Christophe de Dinechin wrote:
> +1 on the initial thread b
>
> > On 6 Mar 2020, at 15:54, Daniel Henrique Barboza
> > wrote:
> >
> >
> >
> > On 3/6/20 8:44 AM, Daniel P. Berrangé wrote:
> >
> >
> > [...]
> >
> >
> > What happens with this mailing
This series extends QMP introspection to cover deprecation.
Additionally, new option -compat lets you configure what to do when
deprecated interfaces get used. This is intended for testing users of
the management interfaces. It is experimental.
-compat deprecated-input= configures what to do whe
+1 on the initial thread b
> On 6 Mar 2020, at 15:54, Daniel Henrique Barboza
> wrote:
>
>
>
> On 3/6/20 8:44 AM, Daniel P. Berrangé wrote:
>
>
> [...]
>
>
> What happens with this mailing list when the migration to the new workflow is
> completed with all the repos? Is it still going to
On Tue, Mar 17, 2020 at 11:12:54AM +0100, Peter Krempa wrote:
> On Tue, Mar 17, 2020 at 09:47:22 +, Daniel Berrange wrote:
> > On Tue, Mar 17, 2020 at 09:26:44AM +0100, Peter Krempa wrote:
> > > On Tue, Mar 17, 2020 at 09:20:07 +0100, Michal Privoznik wrote:
> > > > On 17. 3. 2020 8:52, Peter K
On Tue, Mar 17, 2020 at 09:47:22 +, Daniel Berrange wrote:
> On Tue, Mar 17, 2020 at 09:26:44AM +0100, Peter Krempa wrote:
> > On Tue, Mar 17, 2020 at 09:20:07 +0100, Michal Privoznik wrote:
> > > On 17. 3. 2020 8:52, Peter Krempa wrote:
> > > > On Fri, Mar 06, 2020 at 11:44:07 +, Daniel Be
On Tue, Mar 17, 2020 at 10:01:24AM +0100, Peter Krempa wrote:
> On Tue, Mar 17, 2020 at 09:42:30 +0100, Michal Privoznik wrote:
> > On 17. 3. 2020 9:26, Peter Krempa wrote:
> > > On Tue, Mar 17, 2020 at 09:20:07 +0100, Michal Privoznik wrote:
> > >> On 17. 3. 2020 8:52, Peter Krempa wrote:
>
> [..
On Fri, Mar 13, 2020 at 09:45:15 +0100, Christian Ehrhardt wrote:
> On Tue, Mar 10, 2020 at 11:48 AM Christian Ehrhardt <
> christian.ehrha...@canonical.com> wrote:
>
> > One of the mitigation methods for TAA[1] is to disable TSX
> > support on the host system. Linux added a mechanism to disable
On Tue, Mar 17, 2020 at 09:26:44AM +0100, Peter Krempa wrote:
> On Tue, Mar 17, 2020 at 09:20:07 +0100, Michal Privoznik wrote:
> > On 17. 3. 2020 8:52, Peter Krempa wrote:
> > > On Fri, Mar 06, 2020 at 11:44:07 +, Daniel Berrange wrote:
> > >> We've discussed the idea of replacing our mailing
On 17. 3. 2020 1:01, Daniel Henrique Barboza wrote:
> Commit 7b79ee2f78 makes assumptions about die_id parsing in
> the sysfs that aren't true for Power hosts. In both Power8
> and Power9, running 5.6 and 4.18 kernel respectively,
> 'die_id' is set to -1:
>
> $ cat /sys/devices/system/cpu/cpu0/top
On Tue, Mar 17, 2020 at 09:42:30 +0100, Michal Privoznik wrote:
> On 17. 3. 2020 9:26, Peter Krempa wrote:
> > On Tue, Mar 17, 2020 at 09:20:07 +0100, Michal Privoznik wrote:
> >> On 17. 3. 2020 8:52, Peter Krempa wrote:
[...]
> >> I don't think I share this view. The way qemu developers notify u
On 17. 3. 2020 9:26, Peter Krempa wrote:
> On Tue, Mar 17, 2020 at 09:20:07 +0100, Michal Privoznik wrote:
>> On 17. 3. 2020 8:52, Peter Krempa wrote:
>>> On Fri, Mar 06, 2020 at 11:44:07 +, Daniel Berrange wrote:
We've discussed the idea of replacing our mailing list review workflow with
On Tue, Mar 17, 2020 at 09:20:07 +0100, Michal Privoznik wrote:
> On 17. 3. 2020 8:52, Peter Krempa wrote:
> > On Fri, Mar 06, 2020 at 11:44:07 +, Daniel Berrange wrote:
> >> We've discussed the idea of replacing our mailing list review workflow with
> >> a merge request workflow in various pla
On 17. 3. 2020 8:52, Peter Krempa wrote:
> On Fri, Mar 06, 2020 at 11:44:07 +, Daniel Berrange wrote:
>> We've discussed the idea of replacing our mailing list review workflow with
>> a merge request workflow in various places, over the last 6 months or so,
>> but never made a concrete decision
On Fri, Mar 06, 2020 at 11:44:07 +, Daniel Berrange wrote:
> We've discussed the idea of replacing our mailing list review workflow with
> a merge request workflow in various places, over the last 6 months or so,
> but never made a concrete decision.
One other thing that worries me about this
45 matches
Mail list logo
