[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH v3 2/4] qcow2: Document some maximum size constr

From: Eric Blake
Subject: Re: [Qemu-block] [PATCH v3 2/4] qcow2: Document some maximum size constraints
Date: Mon, 26 Feb 2018 10:41:54 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 02/26/2018 10:25 AM, Alberto Garcia wrote:
On Thu 22 Feb 2018 04:59:20 PM CET, Eric Blake wrote:
While at it, notice that since we cannot map any virtual cluster to
any address higher than 64 PB (56 bits) (due to the L1/L2 field
encoding), it makes little sense to require the refcount table to
access host offsets beyond that point.

But refcount blocks are not addressed by L2 tables, so in principle it
should be possible to have refcount blocks after the first 64PB.

But (if we don't make this change) that's about all you can usefully have (and it would be a self-referencing refcount block).

But I agree that it's a good idea to set that as a maximum possible
physical size of the qcow2 image.

@@ -341,7 +355,7 @@ Refcount table entry:

      Bit  0 -  8:    Reserved (set to 0)

-         9 - 63:    Bits 9-63 of the offset into the image file at which the
+         9 - 55:    Bits 9-55 of the offset into the image file at which the
                      refcount block starts. Must be aligned to a cluster

@@ -349,6 +363,8 @@ Refcount table entry:
                      been allocated. All refcounts managed by this refcount 
                      are 0.

+        56 - 63:    Reserved (set to 0)

Are we not updating REFT_OFFSET_MASK as well?

We could, but that should be a separate patch from the spec change. We could also add some validation that any offsets in the header point to less than the 64PB limit.

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]