[PATCH RFC 3/6] iotests: get rid of '..' in path environment output

2023-06-20 Thread John Snow
Resolve the build_root before we append more items onto it so that the environment output is more concise with less parent directory confetti in it. Signed-off-by: John Snow --- tests/qemu-iotests/testenv.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH RFC 0/6] Switch iotests to pyvenv

2023-06-20 Thread John Snow
Hi, this is ... a fairly incomplete series about trying to get iotests to run out of the configure-time venv. I'm looking for some feedback, so out to the list it goes. Primarily, I'm having doubts about these points: 1) I think I need something like "mkvenv install" in the first patch, but

[PATCH RFC 6/6] iotests: don't add qemu.git/python to PYTHONPATH

2023-06-20 Thread John Snow
qemu.* should be provided by the configure-time venv, now. Signed-off-by: John Snow --- tests/qemu-iotests/testenv.py | 4 1 file changed, 4 deletions(-) diff --git a/tests/qemu-iotests/testenv.py b/tests/qemu-iotests/testenv.py index 1b095d70f2..6441145701 100644 ---

[PATCH RFC 4/6] iotests: use the correct python to run linters

2023-06-20 Thread John Snow
Whichever python is used to run iotest 297 should be the one used to actually run the linters. Signed-off-by: John Snow --- tests/qemu-iotests/linters.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/qemu-iotests/linters.py b/tests/qemu-iotests/linters.py index

[PATCH RFC 5/6] iotests: use pyvenv/bin/python3 to launch child test processes

2023-06-20 Thread John Snow
Now that there's a fancy venv set up for us by configure, we should take care to use it even when check is invoked directly. ./check will now use the pyvenv environment when launching python tests, which allows those tests to find and access the 'qemu.*' packages without PYTHONPATH modifications.

[PATCH RFC 1/6] experiment: add mkvenv install

2023-06-20 Thread John Snow
This is just so I can do "mkvenv install './python'" or "mkvenv install file:python" to install the in-tree packages to pyvenv. It probably isn't quite appropriate to bypass do_ensure in its entirety like this because we miss out on a lot of error handling, but as a quick proof of concept it

[PATCH RFC 2/6] build, tests: Add qemu in-tree packages to pyvenv at configure time.

2023-06-20 Thread John Snow
though, ouch: on my machine this takes 3-4 entire seconds to do. I wish it wasn't so slow, but we can't rely on these packages not having any dependencies any more. We could theoretically use a .pth hack when creating the venv to automatically include this directory as an "installed packages"

Re: [PATCH 12/12] hw/vmapple/vmapple: Add vmapple machine type

2023-06-20 Thread Bernhard Beschow
Am 14. Juni 2023 22:57:34 UTC schrieb Alexander Graf : >Apple defines a new "vmapple" machine type as part of its proprietary >macOS Virtualization.Framework vmm. This machine type is similar to the >virt one, but with subtle differences in base devices, a few special >vmapple device additions

Re: Open qcow2 on multiple hosts simultaneously.

2023-06-20 Thread Vivek Goyal
On Mon, Jun 19, 2023 at 07:20:34PM +0200, kvaps wrote: > Hi Kevin and the community, [ CC Alberto, Alice, Stefan ] > > I am designing a CSI driver for Kubernetes that allows efficient > utilization of SAN (Storage Area Network) and supports thin > provisioning, snapshots, and ReadWriteMany mode

Re: [PATCH 05/12] hw/virtio: Add support for apple virtio-blk

2023-06-20 Thread Kevin Wolf
Am 20.06.2023 um 16:35 hat Stefan Hajnoczi geschrieben: > On Wed, Jun 14, 2023 at 10:56:22PM +, Alexander Graf wrote: > > diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c > > index 39e7f23fab..76b85bb3cb 100644 > > --- a/hw/block/virtio-blk.c > > +++ b/hw/block/virtio-blk.c > > @@

Re: [RFC 2/4] qcow2: add configurations for zoned format extension

2023-06-20 Thread Sam Li
Stefan Hajnoczi 于2023年6月20日周二 22:48写道: > > On Mon, Jun 19, 2023 at 10:50:31PM +0800, Sam Li wrote: > > Stefan Hajnoczi 于2023年6月19日周一 22:42写道: > > > > > > On Mon, Jun 19, 2023 at 06:32:52PM +0800, Sam Li wrote: > > > > Stefan Hajnoczi 于2023年6月19日周一 18:10写道: > > > > > On Mon, Jun 05, 2023 at

Re: [RFC 2/4] qcow2: add configurations for zoned format extension

2023-06-20 Thread Stefan Hajnoczi
On Mon, Jun 19, 2023 at 10:50:31PM +0800, Sam Li wrote: > Stefan Hajnoczi 于2023年6月19日周一 22:42写道: > > > > On Mon, Jun 19, 2023 at 06:32:52PM +0800, Sam Li wrote: > > > Stefan Hajnoczi 于2023年6月19日周一 18:10写道: > > > > On Mon, Jun 05, 2023 at 06:41:06PM +0800, Sam Li wrote: > > > > > diff --git

Re: [RFC 4/6] migration: Deprecate -incoming

2023-06-20 Thread Peter Xu
On Tue, Jun 20, 2023 at 01:10:55PM +0100, Daniel P. Berrangé wrote: > In some cases it is worth having a convenience option for user friendliness. > > In this case, however, users are already needing to use QMP/HMP on the > source side to set migration parameters. I think it is reasonable to say

Re: [PATCH 05/12] hw/virtio: Add support for apple virtio-blk

2023-06-20 Thread Stefan Hajnoczi
On Wed, Jun 14, 2023 at 10:56:22PM +, Alexander Graf wrote: > diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c > index 39e7f23fab..76b85bb3cb 100644 > --- a/hw/block/virtio-blk.c > +++ b/hw/block/virtio-blk.c > @@ -1120,6 +1120,20 @@ static int

Re: [PATCH 00/12] Introduce new vmapple machine type

2023-06-20 Thread Mads Ynddal
> On 15 Jun 2023, at 00.40, Alexander Graf wrote: > > This patch set introduces a new ARM and HVF specific machine type > called "vmapple". It mimicks the device model that Apple's proprietary > Virtualization.Framework exposes, but implements it in QEMU. > > With this new machine type, you

Re: [RFC 4/6] migration: Deprecate -incoming

2023-06-20 Thread Daniel P . Berrangé
On Mon, Jun 12, 2023 at 05:19:40PM -0400, Peter Xu wrote: > On Mon, Jun 12, 2023 at 10:51:08PM +0200, Juan Quintela wrote: > > Peter Xu wrote: > > > On Mon, Jun 12, 2023 at 09:33:42PM +0200, Juan Quintela wrote: > > >> Only "defer" is recommended. After setting all migation parameters, > > >>

Re: [RFC 4/6] migration: Deprecate -incoming

2023-06-20 Thread Daniel P . Berrangé
On Mon, Jun 12, 2023 at 10:51:08PM +0200, Juan Quintela wrote: > Peter Xu wrote: > > On Mon, Jun 12, 2023 at 09:33:42PM +0200, Juan Quintela wrote: > >> Only "defer" is recommended. After setting all migation parameters, > >> start incoming migration with "migrate-incoming uri" command. > >> >

Re: [RFC 3/6] migration: migrate 'blk' command option is deprecated.

2023-06-20 Thread Daniel P . Berrangé
On Mon, Jun 12, 2023 at 09:33:41PM +0200, Juan Quintela wrote: > Use 'migrate_set_capability block true' instead. > > Signed-off-by: Juan Quintela > --- > docs/about/deprecated.rst | 7 +++ > qapi/migration.json | 11 +++ > migration/migration.c | 5 + > 3 files

Re: [RFC 2/6] migration: migrate 'inc' command option is deprecated.

2023-06-20 Thread Daniel P . Berrangé
On Mon, Jun 12, 2023 at 09:33:40PM +0200, Juan Quintela wrote: > Use 'migrate_set_parameter block_incremental true' instead. > > Signed-off-by: Juan Quintela > --- > docs/about/deprecated.rst | 7 +++ > qapi/migration.json | 11 +-- > migration/migration.c | 5 + > 3

Re: [RFC 1/6] migration: skipped field is really obsolete.

2023-06-20 Thread Daniel P . Berrangé
On Mon, Jun 12, 2023 at 09:33:39PM +0200, Juan Quintela wrote: > Has return zero for more than 10 years. Just mark it deprecated. Specifically we introduced the field in 1.5.0 commit f1c72795af573b24a7da5eb52375c9aba8a37972 Author: Peter Lieven Date: Tue Mar 26 10:58:37 2013 +0100