I use
-device usb-host,vendorid=0x046d,productid=0x081b
But in this case the webcam belongs to the guest and the host can't use
the webcam.
I want a dynamical sharing like the mouse sharing for example.
Thanks
--
You received this bug notification because you are a member of qemu-
devel-ml, w
On 14.05.2021 19:06, Alex Bennée wrote:
Hi,
I've been playing around with QEMU's reverse debugging support which
I have working with Pavel's latest patches for supporting virtio with
record/replay. Once you get the right command line it works well enough
although currently each step backwards re
Thanks for looking into this patch David
David Gibson writes:
> On Thu, May 06, 2021 at 08:19:24AM +0530, Vaibhav Jain wrote:
>> Add support for H_SCM_PERFORMANCE_STATS described at [1] for
>> spapr nvdimms. This enables guest to fetch performance stats[2] like
>> expected life of an nvdimm ('Me
It can be closed. The added documentation is very helpful.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1921092
Title:
gdbstub debug of multi-cluster machines is undocumented and confusing
Status
On 5/6/21 5:57 AM, Kashyap Chamarthy wrote:
TODO: We also need to deprecate drive-backup transaction action..
But union members in QAPI doesn't support 'deprecated' feature. I tried
to dig a bit, but failed :/ Markus, could you please help with it? At
least by advice?
Oho, I see.
OK, I'm not M
we want to get from shres here, after possible call to
block_copy_task_shrink(), as task->bytes may be reduced.
Ah right, I missed that. So I guess if we want the caller to protect
co-shared-resource, get_from_shres stays where it is, and put_
instead can still go into task_end (with a bool
** Changed in: qemu
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1921061
Title:
Corsair iCUE Install Fails, qemu VM Reboots
Status in QEMU:
Confirmed
Bug
On 14/05/21 19:27, Roman Kagan wrote:
AFAICS your patch has basically the same effect as Vladimir's
patch "util/async: aio_co_enter(): do aio_co_schedule in general case"
(https://lore.kernel.org/qemu-devel/20210408140827.332915-4-vsement...@virtuozzo.com/).
That one was found to break e.g. aio=
On 14/05/21 15:13, Mirela Grujic wrote:
However, if you believe it should rather be just renamed I can do so.
I am just not sure it's such an advantage to replace phase_check with
separate functions. The rename is a constraint of QAPI, so we have to
live with the long names.
Paolo
14.05.2021 20:28, Emanuele Giuseppe Esposito wrote:
On 14/05/2021 17:30, Vladimir Sementsov-Ogievskiy wrote:
14.05.2021 17:32, Emanuele Giuseppe Esposito wrote:
On 14/05/2021 16:26, Vladimir Sementsov-Ogievskiy wrote:
14.05.2021 17:10, Emanuele Giuseppe Esposito wrote:
On 12/05/2021 17:
On 5/5/21 9:58 AM, 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-off-by: Vladimir Sementsov-Ogiev
On 5/5/21 9:58 AM, Vladimir Sementsov-Ogievskiy wrote:
We are going to deprecate drive-backup, so don't mention it here.
Moreover, blockdev-backup seems more correct in the context.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
---
docs/block-replication.txt | 4 ++--
On 5/14/21 4:16 AM, Emanuele Giuseppe Esposito wrote:
On 13/05/2021 20:47, John Snow wrote:
On 4/14/21 1:03 PM, Emanuele Giuseppe Esposito wrote:
As with gdbserver, valgrind delays the test execution, so
the default QMP socket timeout timeout too soon.
Signed-off-by: Emanuele Giuseppe Esposi
The situation is still the same in QEMU 6.0.0.
$ powerpc64le-linux-gnu-gcc-5 test-fmadds.c -static
$ ~/inst-qemu/6.0.0/bin/qemu-ppc64le ./a.out ; echo $?
32
** Changed in: qemu
Status: Incomplete => New
--
You received this bug notification because you are a member of qemu-
devel-ml, wh
The situation in version 6.0.0 is the same as in version 2.11.0: The
cases ppc, ppc64, ppc64le, s390x are fixed, but the sparc64 executable
still crashes.
** Changed in: qemu
Status: Incomplete => New
--
You received this bug notification because you are a member of qemu-
devel-ml, which
The issue seems to be fixed, even without the symlink for
/usr/-linux-gnu/etc/ld.so.cache.
For m68k: since version 2.10.0.
For s390x: since version 2.11.0.
For the other platforms, already since 2.9.0 (strange, this contradicts my
original report...).
** Changed in: qemu
Status: Incomplet
On 4/9/21 10:53 AM, Wainer dos Santos Moschetta wrote:
Hi,
On 4/7/21 5:01 PM, Eduardo Habkost wrote:
On Tue, Mar 23, 2021 at 05:01:09PM -0400, John Snow wrote:
On 3/17/21 3:16 PM, Wainer dos Santos Moschetta wrote:
Added John and Eduardo,
On 3/9/21 3:52 PM, Cleber Rosa wrote:
On Wed, Feb 24
This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:
https://gitlab.com/qemu-project/qemu/-/issues/305
** Changed in: qemu
Status: New => Expired
** Bug watch
This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:
https://gitlab.com/qemu-project/qemu/-/issues/307
** Changed in: qemu
Status: New => Expired
** Bug watch
This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:
https://gitlab.com/qemu-project/qemu/-/issues/306
** Changed in: qemu
Status: New => Expired
** Bug watch
This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:
https://gitlab.com/qemu-project/qemu/-/issues/304
** Changed in: qemu
Status: Confirmed => Expired
** Bug
This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:
https://gitlab.com/qemu-project/qemu/-/issues/310
** Changed in: qemu
Status: New => Expired
** Bug watch
This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:
https://gitlab.com/qemu-project/qemu/-/issues/308
** Changed in: qemu
Status: New => Expired
** Bug watch
This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:
https://gitlab.com/qemu-project/qemu/-/issues/303
** Changed in: qemu
Status: New => Expired
** Bug watch
This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:
https://gitlab.com/qemu-project/qemu/-/issues/309
** Changed in: qemu
Status: New => Expired
** Bug watch
Also, is this a duplicate of
https://bugs.launchpad.net/qemu/+bug/1912107 or do you mean something
different here?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1918975
Title:
[Feature request] Pro
** Changed in: qemu
Status: New => In Progress
** Changed in: qemu
Importance: Undecided => High
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1912780
Title:
QEMU: Null Pointer Failure i
On 5/14/21 3:23 PM, Thomas Huth wrote:
On 23/01/2021 11.03, P J P wrote:
From: Prasad J Pandit
While processing ioport command in 'fdctrl_write_dor', device
controller may select a drive which is not initialised with a
block device. This may result in a NULL pointer dereference.
Add checks to
This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:
https://gitlab.com/qemu-project/qemu/-/issues/302
** Changed in: qemu
Status: New => Expired
** Bug watch
On 23/01/2021 11.03, P J P wrote:
From: Prasad J Pandit
While processing ioport command in 'fdctrl_write_dor', device
controller may select a drive which is not initialised with a
block device. This may result in a NULL pointer dereference.
Add checks to avoid it.
Fixes: CVE-2021-20196
Reporte
The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.
If the bug has already been fixed in the latest upstream version of QEMU,
then plea
On 5/12/21 5:46 PM, John Snow wrote:
pylint 2.8.x adds warnings whenever we use Popen calls without using
'with', so it's desirable to convert synchronous calls to run()
invocations where applicable.
(Though, this trades one pylint warning for another due to a pylint bug,
which I've silenced wit
The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.
If the bug has already been fixed in the latest upstream version of QEMU,
then plea
The patch for QEMU that has been mentioned in comment #38 has been
merged already, so I'm marking this as Fix-Released there.
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
http
The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.
If the bug has already been fixed in the latest upstream version of QEMU,
then plea
On 5/14/21 10:08 AM, Wainer dos Santos Moschetta wrote:
Now it might throw a CalledProcessError given that `check=True`.
Shouldn't it capture the exception and (possible) re-throw as an
QEMUMachineError?
I lied to you again. The existing callers all check for failure
explicitly, so in the int
The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.
If the bug has already been fixed in the latest upstream version of QEMU,
then plea
Have you already tried to simply pass the host USB webcam through to the
guest? ... that's likely easier and faster than adding software
emulation...
** Changed in: qemu
Status: New => Incomplete
** Tags added: feature-request usb
** Changed in: qemu
Importance: Undecided => Wishlist
The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.
If the bug has already been fixed in the latest upstream version of QEMU,
then plea
The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.
If the bug has already been fixed in the latest upstream version of QEMU,
then plea
Is there still anything to do here or could we close the ticket now?
** Changed in: qemu
Status: Confirmed => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1921092
Title:
gdbstub
The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.
If the bug has already been fixed in the latest upstream version of QEMU,
then plea
On 5/14/21 10:42 AM, Wainer dos Santos Moschetta wrote:
Hi,
On 5/12/21 6:46 PM, John Snow wrote:
Shift the open() call later so that the pylint pragma applies *only* to
that one open() call. Add a note that suggests why this is safe: the
resource is unconditionally cleaned up in _post_shutdown(
The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.
If the bug has already been fixed in the latest upstream version of QEMU,
then plea
The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.
If the bug has already been fixed in the latest upstream version of QEMU,
then plea
The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.
If the bug has already been fixed in the latest upstream version of QEMU,
then plea
On 5/14/21 10:08 AM, Wainer dos Santos Moschetta wrote:
Hi,
On 5/12/21 6:46 PM, John Snow wrote:
use run() instead of Popen() -- to assert to pylint that we are not
forgetting to close a long-running program.
Signed-off-by: John Snow
---
python/qemu/machine.py | 15 +--
1 file
This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:
https://gitlab.com/qemu-project/qemu/-/issues/300
** Changed in: qemu
Status: Incomplete => Expired
** Bu
The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.
If the bug has already been fixed in the latest upstream version of QEMU,
then plea
This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:
https://gitlab.com/qemu-project/qemu/-/issues/301
** Changed in: qemu
Status: New => Expired
** Bug watch
So is this working now with the final release of v6.0 ?
** Changed in: qemu
Status: Triaged => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1918084
Title:
Build fails on macOS 1
On 5/13/21 7:57 AM, Peter Maydell wrote:
Maybe we should macroify this, as unless I'm misreading them
gvec_sdot_idx_b, gvec_udot_idx_b, gvec_sudot_idx_b and gvec_usdot_idx_b
only differ in the types of the index and the data.
Done.
r~
On Fri, 14 May 2021 at 12:13, wrote:
>
> From: Marc-André Lureau
>
> The following changes since commit 2d3fc4e2b069494b1e9e2e4a1e3de24cbc036426:
>
> Merge remote-tracking branch 'remotes/armbru/tags/pull-misc-2021-05-12'
> into staging (2021-05-13 20:13:24 +0100)
>
> are available in the Git
Il ven 14 mag 2021, 18:20 Daniel P. Berrangé ha
scritto:
> My gut feeling though is accel-set would be more logical being done
> first, as that also influences the set of features available in other
> areas of QEMU configuration. Was there a reason you listed it after
> machine-set ?
>
That was
On 5/13/21 7:42 AM, Peter Maydell wrote:
On Fri, 30 Apr 2021 at 22:07, Richard Henderson
wrote:
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 9 +
target/arm/sve.decode | 18 ++
target/arm/sve_helper.c| 30 +
On 12/05/2021 15:39, Richard Henderson wrote:
On 5/12/21 9:08 AM, Bruno Larsen (billionai) wrote:
+++ b/target/ppc/tcg-stub.c
@@ -0,0 +1,33 @@
+
+#include "qemu/osdep.h"
All files get copyright boilerplate.
+#include "exec/hwaddr.h"
+#include "cpu.h"
+#include "hw/ppc/spapr.h"
+
+hwaddr ppc
Il ven 14 mag 2021, 16:10 Emanuele Giuseppe Esposito
ha scritto:
> > I'm not sure I like it since callers may still need coarser grained
> > locks to protect their own state or synchronize access to multiple
> > items of data. Also, some callers may not need thread-safety.
> >
> > Can the caller
On 5/14/21 10:13 AM, Richard Henderson wrote:
--- a/target/i386/tcg/translate.c
+++ b/target/i386/tcg/translate.c
@@ -193,6 +193,7 @@ typedef struct DisasContext {
{ qemu_build_not_reached(); }
#ifdef CONFIG_USER_ONLY
+STUB_HELPER(check_io, TCGv_env env, TCGv_i32 port, TCGv_i32 size)
On Fri, May 14, 2021 at 9:06 AM Daniel P. Berrangé wrote:
>
> Several distros have been dropped since the last time we bumped the
> minimum required CLang version.
>
> Per repology, currently shipping versions are:
>
> RHEL-8: 10.0.1
> Debian Buster: 7.0.1
> openSUSE Leap 15.2:
On 14/05/2021 17:30, Vladimir Sementsov-Ogievskiy wrote:
14.05.2021 17:32, Emanuele Giuseppe Esposito wrote:
On 14/05/2021 16:26, Vladimir Sementsov-Ogievskiy wrote:
14.05.2021 17:10, Emanuele Giuseppe Esposito wrote:
On 12/05/2021 17:44, Stefan Hajnoczi wrote:
On Mon, May 10, 2021 at 1
On 5/13/21 2:35 PM, Peter Maydell wrote:
On Fri, 30 Apr 2021 at 22:37, Richard Henderson
wrote:
Signed-off-by: Richard Henderson
---
target/arm/cpu.c | 1 +
target/arm/cpu64.c | 13 +
2 files changed, 14 insertions(+)
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index
On Fri, May 14, 2021 at 9:05 AM Daniel P. Berrangé wrote:
>
> Several distros have been dropped since the last time we bumped the
> minimum required GCC version.
>
> Per repology, currently shipping versions are:
>
> RHEL-8: 8.3.1
> Debian Buster: 8.3.0
> openSUSE Leap 15.2: 7.
On Fri, May 14, 2021 at 9:05 AM Daniel P. Berrangé wrote:
>
> The glib version was not previously constrained by RHEL-7 since it
> rebases fairly often. Instead SLES 12 and Ubuntu 16.04 were the
> constraints in 00f2cfbbec63fb6f5a7789797a62ccedd22466ea. Both of
> these are old enough that they are
From: Vladimir Sementsov-Ogievskiy
We don't need this extra logic: it doesn't make code simpler.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Max Reitz
Message-Id: <20210506090621.11848-8-vsement...@virtuozzo.com>
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Max Reitz
---
tests/u
On 5/13/21 2:49 PM, Peter Maydell wrote:
On Fri, 30 Apr 2021 at 22:36, Richard Henderson
wrote:
This is {S,U,US}MMLA for both AArch64 AdvSIMD and SVE,
and V{S,U,US}MMLA.S8 for AArch32 NEON.
Signed-off-by: Richard Henderson
---
target/arm/helper.h | 7
target/arm/neon-share
This is not relevant to any OS distro that QEMU currently targets.
Signed-off-by: Daniel P. Berrangé
---
qemu.sasl | 4
1 file changed, 4 deletions(-)
diff --git a/qemu.sasl b/qemu.sasl
index abdfc686be..851acc7e8f 100644
--- a/qemu.sasl
+++ b/qemu.sasl
@@ -29,10 +29,6 @@ mech_list: gssapi
On Fri, May 14, 2021 at 9:05 AM Daniel P. Berrangé wrote:
>
> Signed-off-by: Daniel P. Berrangé
> ---
> tests/vm/centos | 17 -
> 1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/tests/vm/centos b/tests/vm/centos
> index efe3dbbb36..5c7bc1c1a9 100755
> --- a/tests
The SHA-256 variant better meats modern security expectations.
Also warn that the password file is storing entries in clear
text.
Signed-off-by: Daniel P. Berrangé
---
docs/system/vnc-security.rst | 7 ---
qemu.sasl| 11 ++-
2 files changed, 10 insertions(+), 8 d
From: Vladimir Sementsov-Ogievskiy
write-notifiers are used only for write-threshold. New code for such
purpose should create filters.
Let's better special-case write-threshold and drop write notifiers at
all. (Actually, write-threshold is special-cased anyway, as the only
user of write-notifier
The authorization framework provides a way to control access to network
services after a client has been authenticated. This documents how to
actually use it.
Signed-off-by: Daniel P. Berrangé
---
docs/system/authz.rst | 263 ++
docs/system/index.rst | 1
Signed-off-by: Daniel P. Berrangé
---
docs/system/index.rst | 1 +
docs/system/secrets.rst | 162
2 files changed, 163 insertions(+)
create mode 100644 docs/system/secrets.rst
diff --git a/docs/system/index.rst b/docs/system/index.rst
index b05af716a
From: Connor Kuehl
The contents of this patch were initially developed and posted by Han
Han[1], however, it appears the original patch was not applied. Since
then, the relevant documentation has been moved and adapted to a new
format.
I've taken most of the original wording and tweaked it accor
On Fri, May 14, 2021 at 9:04 AM Daniel P. Berrangé wrote:
>
> It has been over two years since RHEL-8 was released, and thus per the
> platform build policy, we no longer need to support RHEL-7 as a build
> target. This lets us increment the minimum required nettle version and
> drop a lot of back
These are an important of the overall QEMU network backend security
controls but never previously documented aside from in blog posts.
Daniel P. Berrangé (4):
docs: document how to pass secret data to QEMU
docs: document usage of the authorization framework
docs: recommend SCRAM-SHA-256 SASL
From: Paolo Bonzini
Right now there is no easy way for "check" to print a reproducer command.
Because such a reproducer command line would be huge, we can instead teach
check to start a command of our choice. This can be for example a Python
unit test with arguments to only run a specific subtes
On Thu, May 13, 2021 at 11:04:37PM +0200, Paolo Bonzini wrote:
> On 12/05/21 09:15, Vladimir Sementsov-Ogievskiy wrote:
> > > >
> > >
> > > I don't understand. Why doesn't aio_co_enter go through the ctx !=
> > > qemu_get_current_aio_context() branch and just do aio_co_schedule?
> > > That was a
From: Vladimir Sementsov-Ogievskiy
"qemu/typedefs.h" is enough for include/block/write-threshold.h header
with forward declaration of BlockDriverState. Also drop extra includes
from block/write-threshold.c and tests/unit/test-write-threshold.c
Signed-off-by: Vladimir Sementsov-Ogievskiy
Message
From: Paolo Bonzini
Due to a typo, in this case the SOCK_DIR was not being created.
Reviewed-by: Vladimir Sementsov-Ogievskiy
Signed-off-by: Paolo Bonzini
Tested-by: Emanuele Giuseppe Esposito
Message-Id: <20210323181928.311862-6-pbonz...@redhat.com>
Message-Id: <20210503110110.476887-6-pbonz
From: Vladimir Sementsov-Ogievskiy
Testing set/get of one 64bit variable doesn't seem necessary. We have a
lot of such variables. Also remaining tests do test set/get anyway.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Max Reitz
Message-Id: <20210506090621.11848-7-vsement...@virtu
From: Paolo Bonzini
Instead of buffering the test output into a StringIO, patch it on
the fly by wrapping sys.stdout's write method. This can be
done unconditionally, even if using -d, which makes execute_unittest
a bit simpler.
Signed-off-by: Paolo Bonzini
Reviewed-by: Vladimir Sementsov-Ogie
From: Vladimir Sementsov-Ogievskiy
These tests use bdrv_write_threshold_exceeded() API, which is used only
for test (since pre-previous commit). Better is testing real API, which
is used in block.c as well.
So, let's call bdrv_write_threshold_check_write(), and check is
bs->write_threshold_offse
From: Stefan Hajnoczi
Signed-off-by: Stefan Hajnoczi
Message-Id: <20210309094106.196911-4-stefa...@redhat.com>
Signed-off-by: Kevin Wolf
Message-Id: <20210322092327.150720-3-stefa...@redhat.com>
Signed-off-by: Kevin Wolf
---
tests/qtest/vhost-user-blk-test.c | 81 +
From: Vladimir Sementsov-Ogievskiy
They are unused now.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Max Reitz
Message-Id: <20210506090621.11848-3-vsement...@virtuozzo.com>
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Max Reitz
---
include/block/block_int.h | 12
blo
From: Emanuele Giuseppe Esposito
pylint 2.8 introduces consider-using-with error, suggesting
to use the 'with' block statement when possible.
Modify all subprocess.Popen call to use the 'with' statement,
except the one in __init__ of QemuIoInteractive class, since
it is assigned to a class field
Creating a device with a number of queues that isn't supported by the
backend is pointless, the device won't work properly and the error
messages are rather confusing.
Just fail to create the device if num-queues is higher than what the
backend supports.
Since the relationship between num-queues
From: Vladimir Sementsov-Ogievskiy
Now, after huge update of block graph permission update algorithm, we
don't need this workaround with active state of the filter. Drop it and
use new smart bdrv_drop_filter() function.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Message-Id: <20210506194143.394
From: Stefan Hajnoczi
Exercise input validation code paths in
block/export/vhost-user-blk-server.c.
Signed-off-by: Stefan Hajnoczi
Message-Id: <20210309094106.196911-5-stefa...@redhat.com>
Signed-off-by: Kevin Wolf
Message-Id: <20210322092327.150720-4-stefa...@redhat.com>
Signed-off-by: Kevin
From: Paolo Bonzini
In the next patch, "check" will learn how to execute a test script without
going through TestRunner. To enable this, keep only the text output
and subprocess handling in the TestRunner; move into TestEnv the logic
to prepare for running a subprocess.
Reviewed-by: Vladimir Se
Like other error paths, this one needs to call tran_finalize() and clean
up the BlockReopenQueue, too.
Fixes: CID 1452772
Fixes: 72373e40fbc7e4218061a8211384db362d3e7348
Signed-off-by: Kevin Wolf
Message-Id: <20210503110555.24001-3-kw...@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy
Sign
From: Vladimir Sementsov-Ogievskiy
Max reported the following bug:
$ ./qemu-img create -f raw src.img 1G
$ ./qemu-img create -f raw dst.img 1G
$ (echo '
{"execute":"qmp_capabilities"}
{"execute":"blockdev-mirror",
"arguments":{"job-id":"mirror",
"device":"source",
On Fri, May 14, 2021 at 9:04 AM Daniel P. Berrangé wrote:
>
> Now that we only support modern nettle, we don't need to have local
> typedefs to mask the real nettle types.
>
> Reviewed-by: Thomas Huth
> Reviewed-by: Richard Henderson
> Signed-off-by: Daniel P. Berrangé
> ---
> crypto/cipher-ne
From: Stefan Hajnoczi
The checks in vu_blk_sect_range_ok() assume VIRTIO_BLK_SECTOR_SIZE is
equal to BDRV_SECTOR_SIZE. This is true, but let's add a
QEMU_BUILD_BUG_ON() to make it explicit.
We might as well check that the request buffer size is a multiple of
VIRTIO_BLK_SECTOR_SIZE while we're at
From: Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé
Message-Id: <20210511104157.2880306-3-phi...@redhat.com>
---
hw/block/virtio-blk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index d28979efb8..f139cd7cc9 10
From: Vladimir Sementsov-Ogievskiy
bdrv_write_threshold_exceeded() is unused.
bdrv_write_threshold_is_set() is used only to double check the value of
bs->write_threshold_offset in tests. No real sense in it (both tests do
check real value with help of bdrv_write_threshold_get())
Signed-off-by:
From: Paolo Bonzini
Python test scripts that use unittest consist of multiple tests.
unittest.main allows selecting which tests to run, but currently this
is not possible because the iotests wrapper ignores sys.argv.
unittest.main command line options also allow the user to pick the
desired opti
On Fri, May 14, 2021 at 9:04 AM Daniel P. Berrangé wrote:
>
> It has been over two years since RHEL-8 was released, and thus per the
> platform build policy, we no longer need to support RHEL-7 as a build
> target. This lets us increment the minimum required gnutls version
>
> Per repology, curren
14.05.2021 18:43, Max Reitz wrote:
There are a couple of things pylint takes issue with:
- The "time" import is unused
- The import order (iotests should come last)
- get_bitmap_hash() doesn't use @self and so should be a function
- Semicolons at the end of some lines
- Parentheses after "if"
- S
On Fri, May 14, 2021 at 9:04 AM Daniel P. Berrangé wrote:
>
> It has been over two years since RHEL-8 was released, and thus per the
> platform build policy, we no longer need to support RHEL-7 as a build
> target.
>
> The build-user-centos7 job was to detect a failure specific to CentOS
> 7 and t
From: Vladimir Sementsov-Ogievskiy
If mirror is READY than cancel operation is not discarding the whole
result of the operation, but instead it's a documented way get a
point-in-time snapshot of source disk.
So, we should not cancel any requests if mirror is READ and
force=false. Let's fix that
On Fri, May 14, 2021 at 9:04 AM Daniel P. Berrangé wrote:
>
> It has been over two years since RHEL-8 was released, and thus per the
> platform build policy, we no longer need to support RHEL-7 as a build
> target.
>
> Signed-off-by: Daniel P. Berrangé
> ---
> .patchew.yml | 6 +++---
> 1 file c
1 - 100 of 323 matches
Mail list logo
