On 11/23/2010 06:26 AM, Stefan Hajnoczi wrote:
More worrying, I don't see anything in QED that requires the filename to occur within the first 10K bytes. Do we need to add another enum value to libvirt's backing store callback routine, to be used when the header requests data that lies beyond buf_size but is still feasibly valid, for the case where QED designates a backing store location that is beyond 10k but still before the start of the first cluster, rather than the current approach of just treating it as BACKING_STORE_INVALID?
QED doesn't explicitly restrict backing_filename_offset/backing_filename_size to just the header cluster(s). I think it makes sense to say backing_filename_offset + backing_filename_size <= header_size * cluster_size and will add it to the QED spec.
Thanks. Do you also want to require that backing_filename_offset > sizeof(backing_filename_size)+offsetof(header,backing_filename_size)? That is, it doesn't make sense for the backing filename to overlap with existing header elements.
But that doesn't guarantee backing_filename_offset < 10 KB. The space after struct QEDHeader is explicitly unstructured so extensions can put arbitrary data there in a backwards compatible way.
I agree that QED should not have to arbitrarily restrict things because of libvirt. Rather, libvirt should be patched to be able to find a backing filename that lies beyond 10K but still within the header clusters. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org