Philippe Mathieu-Daudé writes:
> On 5/26/20 11:31 AM, Philippe Mathieu-Daudé wrote:
>> +Laurent
>>
>> On 5/26/20 11:04 AM, Markus Armbruster wrote:
>>> Philippe Mathieu-Daudé writes:
>>>
On 5/26/20 9:38 AM, Markus Armbruster wrote:
> Philippe Mathieu-Daudé writes:
>
>>
On 5/25/20 1:08 PM, Alberto Garcia wrote:
There are situations in which we want to know how many contiguous
subclusters of the same type there are in a given cluster. This can be
done by simply iterating over the subclusters and repeatedly calling
qcow2_get_subcluster_type() for each one of
On 5/25/20 5:08 AM, Vladimir Sementsov-Ogievskiy wrote:
Like for read/write in a previous commit, drop extra indirection layer,
generate directly bdrv_readv_vmstate() and bdrv_writev_vmstate().
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/coroutines.h| 10 +++
On 5/25/20 5:08 AM, Vladimir Sementsov-Ogievskiy wrote:
Now, when we are not more paying extra code for coroutine wrappers,
there no more sence in extra indirection layer: bdrv_prwv(). Let's drop
it and instead genereate pure bdrv_preadv() and bdrv_pwritev().
Typos and grammar; I suggest:
Now
On 5/25/20 5:07 AM, Vladimir Sementsov-Ogievskiy wrote:
We have a very frequent pattern of creating coroutine from function
with several arguments:
- create structure to pack parameters
- create _entry function to call original function taking parameters
from struct
- do different
From: Vladimir Sementsov-Ogievskiy
Fix Makefile usage for VPATH builds
Signed-off-by: Eric Blake
---
This fixup lets me build locally with my VPATH build; it probably also
explains why patchew and other CLI tools (which use VPATH) were
failing.
Makefile | 4 +++-
1 file changed, 3
On 5/25/20 8:48 AM, Vladimir Sementsov-Ogievskiy wrote:
25.05.2020 16:14, no-re...@patchew.org wrote:
Patchew
URL:https://patchew.org/QEMU/20200525100801.13859-1-vsement...@virtuozzo.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find
the testing commands and
On 5/25/20 1:08 PM, Alberto Garcia wrote:
This patch adds QCow2SubclusterType, which is the subcluster-level
version of QCow2ClusterType. All QCOW2_SUBCLUSTER_* values have the
the same meaning as their QCOW2_CLUSTER_* equivalents (when they
exist). See below for details and caveats.
In images
Add dirty bitmap information to QCOW2 metadata dump in qcow2.py script.
The sample output:
Header extension: Bitmaps
magic 0x23852875
length24
nb_bitmaps2
reserved320
bitmap_directory_size 0x40
On 5/24/20 9:51 AM, Alberto Garcia wrote:
Subcluster allocation in qcow2 is implemented by extending the
existing L2 table entries and adding additional information to
indicate the allocation status of each subcluster.
This patch documents the changes to the qcow2 format and how they
affect the
On 5/25/20 5:07 AM, Vladimir Sementsov-Ogievskiy wrote:
We are going to keep coroutine-wrappers code (structure-packing
parameters, BDRV_POLL wrapper functions) in a separate auto-generated
s/a //
files. So, we'll need a header with declaration of original _co_
functions, for those which are
On 5/25/20 5:07 AM, Vladimir Sementsov-Ogievskiy wrote:
Most of our coroutine wrappers already follow this convention:
We have 'coroutine_fn bdrv_co_()' as
the core function, and a wrapper 'bdrv_()' which does a polling loop.
The only outsiders are the bdrv_prwv_co and
On 5/26/20 9:54 AM, Andrey Shinkevich wrote:
Add dirty bitmap information to QCOW2 metadata dump in qcow2.py script.
The sample output:
Header extension (Bitmaps):
This change to the output is independently useful. However, per
patchew, it does cause 'make check' to fail:
Patchew URL:
https://patchew.org/QEMU/1590504866-679474-1-git-send-email-andrey.shinkev...@virtuozzo.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
ret may be > 0 on success path at this point. Fix assertion, which may
crash currently.
Fixes: 4ce5dd3e9b5ee0fac18625860eb3727399ee965e
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/block-copy.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/block/block-copy.c
* Stefan Hajnoczi (stefa...@redhat.com) wrote:
> The packed virtqueue layout was introduced in VIRTIO 1.1. It is a single
> ring instead of a split avail/used ring design. There are CPU cache
> advantages to this layout and it is also suited better to hardware
> implementation.
>
> The vhost-net
The next patch will add another client that wants to merge dirty
bitmaps; it will be easier to refactor the code to construct the QAPI
struct correctly into a helper function.
Signed-off-by: Eric Blake
Message-Id: <20200521192137.1120211-4-ebl...@redhat.com>
Reviewed-by: Vladimir
From: Vladimir Sementsov-Ogievskiy
It actually never worked with libvirt, as auto-generated names are
different on source and destination.
It's unsafe and useless to migrate by auto-generated node-names, so
let's forbid it.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Andrey
From: Vladimir Sementsov-Ogievskiy
Important thing for bitmap migration is to select destination block
node to obtain the migrated bitmap.
Prepatch, on source we use bdrv_get_device_or_node_name() to identify
the node, and on target we do bdrv_lookup_bs.
bdrv_get_device_or_node_name() returns
It's useful to know how much space can be occupied by qcow2 persistent
bitmaps, even though such metadata is unrelated to the guest-visible
data. Report this value as an additional QMP field, present when
measuring an existing image and output format that both support
bitmaps. Update iotest 178
Make it easier to copy all the persistent bitmaps of (the top layer
of) a source image along with its guest-visible contents, by adding a
boolean flag for use with qemu-img convert. This is basically
shorthand, as the same effect could be accomplished with a series of
'qemu-img bitmap --add' and
Add a new test covering the 'qemu-img bitmap' subcommand, as well as
'qemu-img convert --bitmaps', both added in recent patches.
Signed-off-by: Eric Blake
Reviewed-by: Max Reitz
Reviewed-by: Vladimir Sementsov-Ogievskiy
Message-Id: <20200521192137.1120211-6-ebl...@redhat.com>
---
Am 25.05.2020 um 18:41 hat Kevin Wolf geschrieben:
> Am 25.05.2020 um 16:18 hat Stefan Reiter geschrieben:
> > On 5/12/20 4:43 PM, Kevin Wolf wrote:
> > > Coroutine functions that are entered through bdrv_run_co() are already
> > > safe to call from synchronous code in a different AioContext
From: Vladimir Sementsov-Ogievskiy
To be used for bitmap migration in further commit.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Andrey Shinkevich
Reviewed-by: Eric Blake
Message-Id: <20200521220648.3255-3-vsement...@virtuozzo.com>
Signed-off-by: Eric Blake
---
From: Vladimir Sementsov-Ogievskiy
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Andrey Shinkevich
Reviewed-by: Eric Blake
Message-Id: <20200521220648.3255-6-vsement...@virtuozzo.com>
[eblake: shorter subject line]
Signed-off-by: Eric Blake
---
migration/block-dirty-bitmap.c | 17
A recent change to qemu-img changed expected error message output, but
178 takes long enough to execute that it does not get run by 'make
check' or './check -g quick'.
Fixes: 43d589b074
Signed-off-by: Eric Blake
Reviewed-by: Vladimir Sementsov-Ogievskiy
Message-Id:
From: Vladimir Sementsov-Ogievskiy
Split out handling one bs, it is needed for the following commit, which
will handle BlockBackends separately.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Eric Blake
Message-Id: <20200521220648.3255-2-vsement...@virtuozzo.com>
[eblake: shorter
From: Vladimir Sementsov-Ogievskiy
Test that dirty bitmap migration works when we deal with mirror.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Eric Blake
Message-Id: <20200521220648.3255-5-vsement...@virtuozzo.com>
Signed-off-by: Eric Blake
---
tests/qemu-iotests/194 | 14
On 5/25/20 2:51 AM, Vladimir Sementsov-Ogievskiy wrote:
21.05.2020 22:21, Eric Blake wrote:
Make it easier to copy all the persistent bitmaps of (the top layer
of) a source image along with its guest-visible contents, by adding a
boolean flag for use with qemu-img convert. This is basically
On 5/26/20 6:03 PM, Philippe Mathieu-Daudé wrote:
> On 5/14/20 7:53 AM, John Snow wrote:
>> In truth, if you don't do this, you'll just get a TypeError
>> exception. Now, you'll get an AssertionError.
>>
>> Is this tangibly better? No.
>> Does mypy complain less? Yes.
>>
>> Signed-off-by: John
On 5/14/20 7:53 AM, John Snow wrote:
> mypy and python type hints are not powerful enough to properly describe
> JSON messages in Python 3.6. The best we can do, generally, is describe
> them as Dict[str, Any].
>
> Add casts to coerce this type for static analysis; but do NOT enforce
> this type
On 5/14/20 7:53 AM, John Snow wrote:
> In truth, if you don't do this, you'll just get a TypeError
> exception. Now, you'll get an AssertionError.
>
> Is this tangibly better? No.
> Does mypy complain less? Yes.
>
> Signed-off-by: John Snow
> ---
> python/qemu/lib/qmp.py | 1 +
> 1 file
On 5/14/20 7:53 AM, John Snow wrote:
> mypy considers it incorrect to use `bool` to statically return false,
> because it will assume that it could conceivably return True, and gives
> different analysis in that case. Use a None return to achieve the same
> effect, but make mypy happy.
>
> Note:
On 5/14/20 7:53 AM, John Snow wrote:
> NB: I am choosing Python 3.6 here. Although our minimum requirement is
> 3.5, this code is used only by iotests (so far) under which we have been
> using a minimum version of 3.6.
Preferably with another Ack-by from someone familiar with Python iotests:
On 5/14/20 7:53 AM, John Snow wrote:
> Mostly, ignore the "no bare except" rule, because flake8 is not
> contextual and cannot determine if we re-raise. Pylint can, though, so
> always prefer pylint for that.
>
> Signed-off-by: John Snow
> ---
> python/qemu/lib/.flake8| 2 ++
>
On 5/14/20 7:53 AM, John Snow wrote:
> Bring our these files up to speed with pylint 2.5.0.
> Add a pylintrc file to formalize which pylint subset
> we are targeting.
>
> The similarity ignore is there to suppress similarity
> reports across imports, which for typing constants,
> are going to
On 5/14/20 7:53 AM, John Snow wrote:
> There's more wrong with these scripts; They are in various stages of
> disrepair. That's beyond the scope of this current patchset.
>
> This just mechanically corrects the imports and the shebangs, as part of
> ensuring that the python/qemu/lib refactoring
On 5/26/20 11:31 AM, Philippe Mathieu-Daudé wrote:
> +Laurent
>
> On 5/26/20 11:04 AM, Markus Armbruster wrote:
>> Philippe Mathieu-Daudé writes:
>>
>>> On 5/26/20 9:38 AM, Markus Armbruster wrote:
Philippe Mathieu-Daudé writes:
> Signed-off-by: Philippe Mathieu-Daudé
A
On Tue, May 26, 2020 at 05:23:42PM +0200, Philippe Mathieu-Daudé wrote:
> On 5/26/20 5:22 PM, Daniel P. Berrangé wrote:
> > On Mon, May 18, 2020 at 08:27:54PM -0400, John Snow wrote:
> >>
> >>
> >> On 5/18/20 3:33 PM, Vladimir Sementsov-Ogievskiy wrote:
> >>> 18.05.2020 21:23, John Snow wrote:
>
On 5/26/20 5:22 PM, Daniel P. Berrangé wrote:
> On Mon, May 18, 2020 at 08:27:54PM -0400, John Snow wrote:
>>
>>
>> On 5/18/20 3:33 PM, Vladimir Sementsov-Ogievskiy wrote:
>>> 18.05.2020 21:23, John Snow wrote:
On 5/18/20 2:14 PM, Vladimir Sementsov-Ogievskiy wrote:
> 14.05.2020
On Mon, May 18, 2020 at 08:27:54PM -0400, John Snow wrote:
>
>
> On 5/18/20 3:33 PM, Vladimir Sementsov-Ogievskiy wrote:
> > 18.05.2020 21:23, John Snow wrote:
> >>
> >>
> >> On 5/18/20 2:14 PM, Vladimir Sementsov-Ogievskiy wrote:
> >>> 14.05.2020 08:53, John Snow wrote:
> move
On 5/26/20 4:55 PM, Philippe Mathieu-Daudé wrote:
> On 5/19/20 7:11 PM, Stefan Hajnoczi wrote:
>> Passing around both BDRVNVMeState and NVMeQueuePair is unwiedly. Reduce
Oh, and typo "unwieldy".
>> the number of function arguments by keeping the BDRVNVMeState pointer in
>> NVMeQueuePair. This
On 5/14/20 7:53 AM, John Snow wrote:
> Catch only the timeout error; if there are other problems, allow the
> stack trace to be visible.
>
> Signed-off-by: John Snow
> ---
> python/qemu/lib/machine.py | 33 +
> 1 file changed, 21 insertions(+), 12 deletions(-)
>
On 5/14/20 4:26 PM, John Snow wrote:
>
>
> On 5/14/20 9:55 AM, Eric Blake wrote:
>> On 5/14/20 12:53 AM, John Snow wrote:
>>> Catch only the timeout error; if there are other problems, allow the
>>> stack trace to be visible.
>>>
>>
>> A lot of patches in this series start with "python//" - is
On 5/19/20 12:54 PM, Vladimir Sementsov-Ogievskiy wrote:
> 19.05.2020 03:27, John Snow wrote:
>>
>>
>> On 5/18/20 3:33 PM, Vladimir Sementsov-Ogievskiy wrote:
>>> 18.05.2020 21:23, John Snow wrote:
On 5/18/20 2:14 PM, Vladimir Sementsov-Ogievskiy wrote:
> 14.05.2020 08:53, John
On Mon, 16 Mar 2020 01:03:42 +0100
Philippe Mathieu-Daudé wrote:
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Igor Mammedov
> ---
> qapi/machine.json| 32
> qapi/misc.json | 32
>
On 5/19/20 7:11 PM, Stefan Hajnoczi wrote:
> Passing around both BDRVNVMeState and NVMeQueuePair is unwiedly. Reduce
> the number of function arguments by keeping the BDRVNVMeState pointer in
> NVMeQueuePair. This will come in handly when a BH is introduced in a
> later patch and only one argument
Add dirty bitmap information to QCOW2 metadata dump in qcow2.py script.
The sample output:
Header extension (Bitmaps):
magic 0x23852875
length24
nb_bitmaps2
reserved320
bitmap_directory_size 0x40
bitmap_directory_offset
On Thu, May 14, 2020 at 06:45:58AM +0200, Klaus Jensen wrote:
> From: Klaus Jensen
>
> First, since the device only supports MSI-X or pin-based interrupt, if
> MSI-X is not enabled, it should not accept interrupt vectors different
> from 0 when creating completion queues.
>
> Secondly, the
Patchew URL: https://patchew.org/QEMU/cover.1590429901.git.be...@igalia.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
On 5/19/20 7:11 PM, Stefan Hajnoczi wrote:
> Existing users access free_req_queue under q->lock. Document this.
>
> Signed-off-by: Stefan Hajnoczi
> ---
> block/nvme.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/block/nvme.c b/block/nvme.c
> index
On 5/19/20 7:11 PM, Stefan Hajnoczi wrote:
> Do not access a CQE after incrementing q->cq.head and releasing q->lock.
> It is unlikely that this causes problems in practice but it's a latent
> bug.
>
> The reason why it should be safe at the moment is that completion
> processing is not
On 5/19/20 7:11 PM, Stefan Hajnoczi wrote:
> nvme_process_completion() explicitly checks cid so the assertion that
> follows is always true:
>
> if (cid == 0 || cid > NVME_QUEUE_SIZE) {
> ...
> continue;
> }
> assert(cid <= NVME_QUEUE_SIZE);
>
> Signed-off-by: Stefan Hajnoczi
On Tue 26 May 2020 04:54:50 AM CEST, no-re...@patchew.org wrote:
> /tmp/qemu-test/src/block/qcow2-cluster.c: In function 'qcow2_get_host_offset':
> /tmp/qemu-test/src/block/qcow2-cluster.c:473:19: error: 'expected_type' may
> be used uninitialized in this function [-Werror=maybe-uninitialized]
>
Please ignore the series, I forgot xen-block device.
Roman.
On Tue, May 26, 2020 at 11:17:35AM +0300, Roman Kagan wrote:
> BlockConf includes several properties counted in bytes.
>
> Enhance their handling in a some aspects, specifically
>
> - accept common size suffixes (k, m)
> - perform
Patchew URL:
https://patchew.org/QEMU/20200526081740.256236-1-rvka...@yandex-team.ru/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20200526081740.256236-1-rvka...@yandex-team.ru
Subject: [PATCH v5 0/5] block: widen and check
Patchew URL:
https://patchew.org/QEMU/20200526081740.256236-1-rvka...@yandex-team.ru/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
Patchew URL:
https://patchew.org/QEMU/20200526081740.256236-1-rvka...@yandex-team.ru/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT
Patchew URL: https://patchew.org/QEMU/cover.1590429901.git.be...@igalia.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
+Laurent
On 5/26/20 11:04 AM, Markus Armbruster wrote:
> Philippe Mathieu-Daudé writes:
>
>> On 5/26/20 9:38 AM, Markus Armbruster wrote:
>>> Philippe Mathieu-Daudé writes:
>>>
Signed-off-by: Philippe Mathieu-Daudé
>>>
>>> A brief note on why restricting "to machine code" is useful would
Philippe Mathieu-Daudé writes:
> On 5/26/20 9:38 AM, Markus Armbruster wrote:
>> Philippe Mathieu-Daudé writes:
>>
>>> Signed-off-by: Philippe Mathieu-Daudé
>>
>> A brief note on why restricting "to machine code" is useful would be
>> nice. Same for the other patches.
>>
>> Acked-by:
Philippe Mathieu-Daudé writes:
> On 5/26/20 9:23 AM, Philippe Mathieu-Daudé wrote:
>> On 5/26/20 8:45 AM, Markus Armbruster wrote:
>>> Philippe Mathieu-Daudé writes:
>>>
Move out x86-specific structures from generic machine code.
Acked-by: Richard Henderson
Signed-off-by:
Make it easier (more visible) to maintain the limits on the blocksize
properties in sync with the respective description, by using macros both
in the code and in the description.
Signed-off-by: Roman Kagan
---
v4 -> v5:
- split out into separate patch [Philippe]
hw/core/qdev-properties.c | 21
Philippe Mathieu-Daudé writes:
> Acked-by: Igor Mammedov
> Signed-off-by: Philippe Mathieu-Daudé
Acked-by: Markus Armbruster
All patches: drop the /misc from qapi/misc: in the title, if you don't
mind.
Observation:
before series after
Logical and physical block sizes in QEMU are limited to 32 KiB.
This appears unnecessary tight, and we've seen bigger block sizes handy
at times.
Lift the limitation up to 2 MiB which appears to be good enough for
everybody, and matches the qcow2 cluster size limit.
Signed-off-by: Roman Kagan
Several BlockConf properties represent respective sizes in bytes so it
makes sense to accept size suffixes for them.
Turn them into uint64_t and use size-suffix-capable setters/getters on
them.
Also, as some of them are exposed to the guest by scsi and virtio-blk
devices as an integer of a
The width of opt_io_size in virtio_blk_config is 32bit. However, it's
written with virtio_stw_p; this may result in value truncation, and on
big-endian systems with legacy virtio in completely bogus readings in
the guest.
Use the appropriate accessor to store it.
Signed-off-by: Roman Kagan
Several block device properties related to blocksize configuration must
be in certain relationship WRT each other: physical block must be no
smaller than logical block; min_io_size, opt_io_size, and
discard_granularity must be a multiple of a logical block.
To ensure these requirements are met,
BlockConf includes several properties counted in bytes.
Enhance their handling in a some aspects, specifically
- accept common size suffixes (k, m)
- perform consistency checks on the values, to prevent their silent
truncation and rounding
- lift the upper limit on physical_block_size and
On 5/26/20 9:38 AM, Markus Armbruster wrote:
> Philippe Mathieu-Daudé writes:
>
>> Signed-off-by: Philippe Mathieu-Daudé
>
> A brief note on why restricting "to machine code" is useful would be
> nice. Same for the other patches.
>
> Acked-by: Markus Armbruster
>
What about this?
"QEMU
Patchew URL: https://patchew.org/QEMU/cover.1590429901.git.be...@igalia.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
Philippe Mathieu-Daudé writes:
> Acked-by: Igor Mammedov
> Signed-off-by: Philippe Mathieu-Daudé
Acked-by: Markus Armbruster
Philippe Mathieu-Daudé writes:
> Signed-off-by: Philippe Mathieu-Daudé
Acked-by: Markus Armbruster
On 25.05.20 17:06, Philippe Mathieu-Daudé wrote:
> The documentation incorrectly uses the "size of the balloon"
> description when it should be "logical size of the VM". Fix it.
>
> The relation between both values is:
>
> logical_vm_size = vm_ram_size - balloon_size
>
> Reported-by: David
Why is this patch titled "Move FOO command to machine code", while other
patches are titled "Restrict FOO command to machine code"?
Philippe Mathieu-Daudé writes:
> Signed-off-by: Philippe Mathieu-Daudé
Acked-by: Markus Armbruster
Philippe Mathieu-Daudé writes:
> Acked-by: Igor Mammedov
> Signed-off-by: Philippe Mathieu-Daudé
Acked-by: Markus Armbruster
Philippe Mathieu-Daudé writes:
> Signed-off-by: Philippe Mathieu-Daudé
A brief note on why restricting "to machine code" is useful would be
nice. Same for the other patches.
Acked-by: Markus Armbruster
On 26.05.20 09:35, David Hildenbrand wrote:
> On 25.05.20 17:06, Philippe Mathieu-Daudé wrote:
>> Signed-off-by: Philippe Mathieu-Daudé
>> ---
>> qapi/machine.json | 90 ++
>> qapi/misc.json | 90 --
>>
On 5/26/20 9:23 AM, Philippe Mathieu-Daudé wrote:
> On 5/26/20 8:45 AM, Markus Armbruster wrote:
>> Philippe Mathieu-Daudé writes:
>>
>>> Move out x86-specific structures from generic machine code.
>>>
>>> Acked-by: Richard Henderson
>>> Signed-off-by: Philippe Mathieu-Daudé
>>> ---
>>>
On 25.05.20 17:06, Philippe Mathieu-Daudé wrote:
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> qapi/machine.json | 90 ++
> qapi/misc.json | 90 --
> include/sysemu/balloon.h | 2 +-
> balloon.c
Philippe Mathieu-Daudé writes:
> Signed-off-by: Philippe Mathieu-Daudé
Acked-by: Markus Armbruster
On 5/26/20 8:45 AM, Markus Armbruster wrote:
> Philippe Mathieu-Daudé writes:
>
>> Move out x86-specific structures from generic machine code.
>>
>> Acked-by: Richard Henderson
>> Signed-off-by: Philippe Mathieu-Daudé
>> ---
>> qapi/machine-target.json | 45
Philippe Mathieu-Daudé writes:
> Move out x86-specific structures from generic machine code.
>
> Acked-by: Richard Henderson
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> qapi/machine-target.json | 45 ++
> qapi/machine.json | 42
Patchew URL: https://patchew.org/QEMU/cover.1590429901.git.be...@igalia.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
84 matches
Mail list logo
