On 06/27/2018 07:07 PM, Max Reitz wrote:
The generic bdrv_dirname() implementation would be able to generate some
form of directory name for many NBD nodes, but it would be always wrong.
Therefore, we have to explicitly make it an error (until NBD has some
form of specification for export paths,
On 06/27/2018 07:07 PM, Max Reitz wrote:
Signed-off-by: Max Reitz
---
tests/qemu-iotests/iotests.py | 3 +++
1 file changed, 3 insertions(+)
Wow, we didn't need that before? Matches what shell tests have.
Reviewed-by: Eric Blake
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
On 06/27/2018 07:07 PM, Max Reitz wrote:
Basically, bdrv_refresh_filename() should respect all children of a
BlockDriverState. However, generally those children are driver-specific,
so this function cannot handle the general case. On the other hand,
there are only few drivers which use other
On 06/27/2018 07:07 PM, Max Reitz wrote:
If the backing file is overridden, this most probably does change the
guest-visible data of a BDS. Therefore, we will need to consider this
in bdrv_refresh_filename().
So all in all, there will be false negatives where (as of a future
patch)
On 06/27/2018 07:07 PM, Max Reitz wrote:
bdrv_refresh_filename() should simply skip all implicit nodes. They are
supposed to be invisible to the user, so they should not appear in
filename information.
Signed-off-by: Max Reitz
---
block.c | 14 ++
1 file changed, 14
On 06/28/2018 04:25 PM, John Snow wrote:
Signed-off-by: John Snow
---
tests/qemu-iotests/222 | 152 +
tests/qemu-iotests/222.out | 66
tests/qemu-iotests/group | 1 +
3 files changed, 219 insertions(+)
create mode
Signed-off-by: John Snow
---
tests/qemu-iotests/222 | 152 +
tests/qemu-iotests/222.out | 66
tests/qemu-iotests/group | 1 +
3 files changed, 219 insertions(+)
create mode 100644 tests/qemu-iotests/222
create mode
In the case of image fleecing, the node we choose as the source
for a blockdev-backup is going to be both a root node AND the
backing node for the exported image. It does not qualify as a root
image in this case.
Loosen the restriction.
Signed-off-by: John Snow
Reviewed-by: Eric Blake
---
Formalize the fleecing workflow in patch one,
test that it works in patch two.
V3:
- Added explicit zero checking as per Eblake's suggestion
- Remove stale python code
John Snow (2):
block: allow blockdev-backup from any source
iotests: add 222 to test basic fleecing
blockdev.c
On 06/28/2018 02:05 PM, Eric Blake wrote:
> On 06/28/2018 01:00 PM, John Snow wrote:
>> In the case of image fleecing, the node we choose as the source
>> for a blockdev-backup is going to be both a root node AND the
>> backing node for the exported image. It does not qualify as a root
>> image
We are gradually moving away from sector-based interfaces, towards
byte-based. Make the change for the internals of the qcow
driver write function, by iterating over offset/bytes instead of
sector_num/nb_sectors, and with a rename of index_in_cluster and
repurposing of n to track bytes instead of
We are gradually moving away from sector-based interfaces, towards
byte-based. The qcow driver is now ready to fully utilize the
byte-based callback interface, as long as we override the default
alignment to still be 512 (needed at least for asserts present
because of encryption, but easier to do
We are gradually moving away from sector-based interfaces, towards
byte-based. Make the change for the internals of the qcow
driver read function, by iterating over offset/bytes instead of
sector_num/nb_sectors, and with a rename of index_in_cluster and
repurposing of n to track bytes instead of
We are gradually moving away from sector-based interfaces, towards
byte-based. Make the change for the last few sector-based calls
into the block layer from the replication driver.
Ideally, the replication driver should switch to doing everything
byte-based, but that's a more invasive change
We are gradually moving away from sector-based interfaces, towards
byte-based. Make the change for the internal helper function
get_cluster_offset(), by changing n_start and n_end to be byte
offsets rather than sector indices within the cluster being
allocated. However, assert that these values
We are gradually moving away from sector-based interfaces, towards
byte-based. Now that all callers of vectored I/O have been converted
to use our preferred byte-based bdrv_co_p{read,write}v(), we can
delete the unused bdrv_co_{read,write}v().
Furthermore, this gets rid of the signature
We are gradually moving away from sector-based interfaces, towards
byte-based. Make the change for the last few sector-based calls
into the block layer from the vhdx driver.
Ideally, the vhdx driver should switch to doing everything
byte-based, but that's a more invasive change that requires a
We are gradually moving away from sector-based interfaces, towards
byte-based. Make the change for the last few sector-based calls
into the block layer from the parallels driver.
Ideally, the parallels driver should switch to doing everything
byte-based, but that's a more invasive change that
My quest continues. I spent some time pruning sector-based usage
out of qcow as far as possible (and was dismayed at how long it
took to prove no iotests regressions); so for the other drivers, I
did the bare minimum to get rid of an interface, but will leave it
to those file owners if they want
Le 28/06/2018 à 01:29, Laurent Vivier a écrit :
Co-developed-by: Mark Cave-Ayland
Signed-off-by: Mark Cave-Ayland
Signed-off-by: Laurent Vivier
---
hw/block/Makefile.objs | 1 +
hw/block/swim.c | 284
include/hw/block/swim.h |
When reading a compressed image, we were allocating s->cluster_data
to 32*cluster_size + 512 (possibly over 64 megabytes, for an image
with 2M clusters). Let's check out the history:
Back when qcow2 was first written, we used s->cluster_data for
everything, including copy_sectors() and
We had only a few sector-based stragglers left; convert them to use
our preferred byte-based accesses.
Signed-off-by: Eric Blake
Reviewed-by: Alberto Garcia
---
v5: commit message tweak
v2: indentation fix
---
block/qcow2-cluster.c | 5 ++---
block/qcow2-refcount.c | 6 +++---
2 files
v5 was here:
https://lists.gnu.org/archive/html/qemu-devel/2018-04/msg04542.html
since then:
- 5/6: update iotest number, add R-b
(git-backport-diff doesn't handle renames well)
001/6:[] [--] 'qcow2: Prefer byte-based calls into bs->file'
002/6:[] [--] 'qcow2: Document some maximum size
Match our code to the spec change in the previous patch - there's
no reason for the refcount table to allow larger offsets than the
L1/L2 tables. In practice, no image has more than 64PB of
allocated clusters anyways, as anything beyond that can't be
expressed via L2 mappings to host offsets.
Our code was already checking that we did not attempt to
allocate more clusters than what would fit in an INT64 (the
physical maximimum if we can access a full off_t's worth of
data). But this does not catch smaller limits enforced by
various spots in the qcow2 image description: L1 and normal
If you have a capable file system (tmpfs is good, ext4 not so much;
run ./check with TEST_DIR pointing to a good location so as not
to skip the test), it's actually possible to create a qcow2 file
that expands to a sparse 512T image with just over 38M of content.
The test is not the world's
Although off_t permits up to 63 bits (8EB) of file offsets, in
practice, we're going to hit other limits first. Document some
of those limits in the qcow2 spec, and how choice of cluster size
can influence some of the limits.
While at it, notice that since we cannot map any virtual cluster
to
On 05/10/2018 08:28 AM, Paolo Bonzini wrote:
On 08/05/2018 23:27, Eric Blake wrote:
Detected by Coverity: Multiplying two 32-bit int and assigning
the result to a 64-bit number is a risk of overflow. Prior to
the conversion to byte-based interfaces, the block layer took
care of ensuring that a
On 06/28/2018 10:49 AM, Eric Blake wrote:
On 06/28/2018 10:39 AM, Kevin Wolf wrote:
If we managed to allocate the clusters, but then failed to write the
data, there's a good chance that we'll still be able to free the
clusters again in order to avoid cluster leaks (the refcounts are
cached, so
v4 was here:
https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg08464.html
v5:
- Checks that username is not used when endpoint=server.
(Note it is optional when endpoint=client, defaulting to "qemu")
Rich.
Pre-Shared Keys (PSK) is a simpler mechanism for enabling TLS
connections than using certificates. It requires only a simple secret
key:
$ mkdir -m 0700 /tmp/keys
$ psktool -u rjones -p /tmp/keys/keys.psk
$ cat /tmp/keys/keys.psk
On 06/28/2018 02:10 PM, Eric Blake wrote:
> On 06/28/2018 01:00 PM, John Snow wrote:
>> Signed-off-by: John Snow
>> ---
>> tests/qemu-iotests/222 | 149
>> +
>> tests/qemu-iotests/222.out | 60 ++
>> tests/qemu-iotests/group
On 06/28/2018 02:17 PM, Eric Blake wrote:
> On 06/28/2018 01:00 PM, John Snow wrote:
>> Signed-off-by: John Snow
>> ---
>> tests/qemu-iotests/222 | 149
>> +
>> tests/qemu-iotests/222.out | 60 ++
>> tests/qemu-iotests/group
On 06/28/2018 01:00 PM, John Snow wrote:
Signed-off-by: John Snow
---
tests/qemu-iotests/222 | 149 +
tests/qemu-iotests/222.out | 60 ++
tests/qemu-iotests/group | 1 +
3 files changed, 210 insertions(+)
create mode
On 06/28/2018 01:00 PM, John Snow wrote:
Signed-off-by: John Snow
---
tests/qemu-iotests/222 | 149 +
tests/qemu-iotests/222.out | 60 ++
tests/qemu-iotests/group | 1 +
3 files changed, 210 insertions(+)
create mode
On 06/28/2018 01:00 PM, John Snow wrote:
In the case of image fleecing, the node we choose as the source
for a blockdev-backup is going to be both a root node AND the
backing node for the exported image. It does not qualify as a root
image in this case.
Loosen the restriction.
Signed-off-by:
Formalize the fleecing workflow in patch one,
test that it works in patch two.
John Snow (2):
block: allow blockdev-backup from any source
iotests: add 222 to test basic fleecing
blockdev.c | 2 +-
tests/qemu-iotests/222 | 149
In the case of image fleecing, the node we choose as the source
for a blockdev-backup is going to be both a root node AND the
backing node for the exported image. It does not qualify as a root
image in this case.
Loosen the restriction.
Signed-off-by: John Snow
---
blockdev.c | 2 +-
1 file
Signed-off-by: John Snow
---
tests/qemu-iotests/222 | 149 +
tests/qemu-iotests/222.out | 60 ++
tests/qemu-iotests/group | 1 +
3 files changed, 210 insertions(+)
create mode 100644 tests/qemu-iotests/222
create mode 100644
On Thu, Jun 28, 2018 at 05:51:18PM +0100, Richard W.M. Jones wrote:
> On Thu, Jun 28, 2018 at 05:06:20PM +0100, Daniel P. Berrangé wrote:
> > On Thu, Jun 28, 2018 at 09:42:18AM -0500, Eric Blake wrote:
> > > Does it make sense to forbid this operation on servers (since it only
> > > makes
> > >
Pre-Shared Keys (PSK) is a simpler mechanism for enabling TLS
connections than using certificates. It requires only a simple secret
key:
$ mkdir -m 0700 /tmp/keys
$ psktool -u rjones -p /tmp/keys/keys.psk
$ cat /tmp/keys/keys.psk
v4:
- This addresses points raised by Eric and Dan's reviews.
The only thing I didn't change was using --object in qemu-options.hx,
since that would really be different from everything else in the file.
(However I did change -object -> --object in the header docs)
This version uses
On Thu, Jun 28, 2018 at 05:06:20PM +0100, Daniel P. Berrangé wrote:
> On Thu, Jun 28, 2018 at 09:42:18AM -0500, Eric Blake wrote:
> > Does it make sense to forbid this operation on servers (since it only makes
> > sense for clients)?
>
> We can't validate that here, because we can't guarantee
On 27 June 2018 at 15:48, Stefan Hajnoczi wrote:
> The following changes since commit 00928a421d47f49691cace1207481b7aad31b1f1:
>
> Merge remote-tracking branch
> 'remotes/pmaydell/tags/pull-target-arm-20180626' into staging (2018-06-26
> 18:23:49 +0100)
>
> are available in the Git
On 2018-06-28 17:39, Kevin Wolf wrote:
> Kevin Wolf (3):
> qemu-iotests: Update 026.out.nocache reference output
> qcow2: Free allocated clusters on write error
> qemu-iotests: Test qcow2 not leaking clusters on write error
>
> block/qcow2.h | 1 +
>
On Thu, Jun 28, 2018 at 09:42:18AM -0500, Eric Blake wrote:
> On 06/28/2018 08:22 AM, Richard W.M. Jones wrote:
>
> In the subject line: most commit summaries don't have a trailing '.'.
>
> > Pre-Shared Keys (PSK) is a simpler mechanism for enabling TLS
> > connections than using certificates.
On Thu, Jun 28, 2018 at 04:54:04PM +0100, Richard W.M. Jones wrote:
> On Thu, Jun 28, 2018 at 09:42:18AM -0500, Eric Blake wrote:
> > On 06/28/2018 08:22 AM, Richard W.M. Jones wrote:
> > >+while (fgets(line, sizeof line, fp) != NULL) {
> > >+if (strncmp(line, username, ulen) == 0 &&
On Thu, Jun 28, 2018 at 09:42:18AM -0500, Eric Blake wrote:
> On 06/28/2018 08:22 AM, Richard W.M. Jones wrote:
> >+while (fgets(line, sizeof line, fp) != NULL) {
> >+if (strncmp(line, username, ulen) == 0 && line[ulen] == ':') {
>
> ...can't this misbehave if the user accidentally
On 06/28/2018 10:39 AM, Kevin Wolf wrote:
If we managed to allocate the clusters, but then failed to write the
data, there's a good chance that we'll still be able to free the
clusters again in order to avoid cluster leaks (the refcounts are
cached, so even if we can't write them out right now,
Kevin Wolf (3):
qemu-iotests: Update 026.out.nocache reference output
qcow2: Free allocated clusters on write error
qemu-iotests: Test qcow2 not leaking clusters on write error
block/qcow2.h | 1 +
block/qcow2-cluster.c | 11 +++
block/qcow2.c
If we managed to allocate the clusters, but then failed to write the
data, there's a good chance that we'll still be able to free the
clusters again in order to avoid cluster leaks (the refcounts are
cached, so even if we can't write them out right now, we may be able to
do so when the VM is
This adds a test for a temporary write failure, which simulates the
situation after werror=stop/enospc has stopped the VM. We shouldn't
leave leaked clusters behind in such cases.
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/026 | 17 +
tests/qemu-iotests/026.out
On 06/28/2018 09:42 AM, Eric Blake wrote:
On 06/28/2018 08:22 AM, Richard W.M. Jones wrote:
In the subject line: most commit summaries don't have a trailing '.'.
Pre-Shared Keys (PSK) is a simpler mechanism for enabling TLS
connections than using certificates. It requires only a simple
On 06/28/2018 08:22 AM, Richard W.M. Jones wrote:
In the subject line: most commit summaries don't have a trailing '.'.
Pre-Shared Keys (PSK) is a simpler mechanism for enabling TLS
connections than using certificates. It requires only a simple secret
key:
$ mkdir -m 0700 /tmp/keys
$
Pre-Shared Keys (PSK) is a simpler mechanism for enabling TLS
connections than using certificates. It requires only a simple secret
key:
$ mkdir -m 0700 /tmp/keys
$ psktool -u rjones -p /tmp/keys/keys.psk
$ cat /tmp/keys/keys.psk
v2 was here:
https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg07404.html
v2 -> v3:
- Offer ECDHE-PSK key exchange algorithm too.
- Added a regression test to tests/test-crypto-tlssession.c
Rich.
On Thu, Jun 21, 2018 at 02:12:46PM -0300, Philippe Mathieu-Daudé wrote:
> Hi,
>
> This series is a collection of various trivial patches from
> different stagnating branches. Time to share before loosing
> them.
>
> Only the first differs and is meant for Stefan, other will
> probably go via the
On 06/26/2018 08:50 AM, Vladimir Sementsov-Ogievskiy wrote:
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/qcow2.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index 945132f692..46194a33ca 100644
--- a/block/qcow2.c
+++
26.06.2018 21:22, John Snow wrote:
On 06/26/2018 09:50 AM, Vladimir Sementsov-Ogievskiy wrote:
Hi all.
To continue talk about correct loading of persistent bitmaps here is
a patch (04), with some surrounding.
Patch 04 contains new (and I hope, more clean) logic of bitmaps
* Laurent Vivier (laur...@vivier.eu) wrote:
> Co-developed-by: Mark Cave-Ayland
> Signed-off-by: Mark Cave-Ayland
> Signed-off-by: Laurent Vivier
> ---
> arch_init.c | 4 +
> hw/display/Makefile.objs| 1 +
> hw/display/macfb-template.h | 158 +++
* Laurent Vivier (laur...@vivier.eu) wrote:
> Co-developed-by: Mark Cave-Ayland
> Signed-off-by: Mark Cave-Ayland
> Signed-off-by: Laurent Vivier
> ---
> hw/input/adb-kbd.c| 4 ++
> hw/input/adb-mouse.c | 4 ++
> hw/input/adb.c| 115
>
* Laurent Vivier (laur...@vivier.eu) wrote:
> This is broken as the linux driver seems broken too...
>
> Co-developed-by: Mark Cave-Ayland
> Signed-off-by: Mark Cave-Ayland
> Signed-off-by: Laurent Vivier
> ---
> +static int asc_post_load(void *opaque, int version_id)
> +{
> +return 0;
>
Le 28/06/2018 à 10:44, Kevin Wolf a écrit :
> Am 28.06.2018 um 01:23 hat Laurent Vivier geschrieben:
>> Co-developed-by: Mark Cave-Ayland
>> Signed-off-by: Mark Cave-Ayland
>> Signed-off-by: Laurent Vivier
>
>> +static Property swim_properties[] = {
>> +DEFINE_PROP_DRIVE("driveA",
Am 28.06.2018 um 01:23 hat Laurent Vivier geschrieben:
> Co-developed-by: Mark Cave-Ayland
> Signed-off-by: Mark Cave-Ayland
> Signed-off-by: Laurent Vivier
> +static Property swim_properties[] = {
> +DEFINE_PROP_DRIVE("driveA", SWIMCtrl, drives[0].blk),
> +DEFINE_PROP_DRIVE("driveB",
Le 28/06/2018 à 10:13, Paolo Bonzini a écrit :
> On 28/06/2018 01:29, Laurent Vivier wrote:
>> int32_t ti_size;
>> @@ -46,6 +47,11 @@ struct ESPState {
>> ESPDMAMemoryReadWriteFunc dma_memory_write;
>> void *dma_opaque;
>> void (*dma_cb)(ESPState *s);
>> +uint8_t
On 28/06/2018 01:29, Laurent Vivier wrote:
> int32_t ti_size;
> @@ -46,6 +47,11 @@ struct ESPState {
> ESPDMAMemoryReadWriteFunc dma_memory_write;
> void *dma_opaque;
> void (*dma_cb)(ESPState *s);
> +uint8_t pdma_buf[32];
> +uint32_t pdma_len;
> +uint8_t
66 matches
Mail list logo
