Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode

[Ian Jackson]

Anthony Liguori writes ("Re: [Qemu-devel] PATCH: v3 Allow control over drive 
file open mode"):
> Ian Jackson wrote:
> >  4. qemu will take steps to try to ensure that bugs and missing
> >     changes in the readonly implementation don't leave a security
> >     hole where the
> 
> I'm not at all worried about this FWIW.

Well, in the Xen world we have different priorities I think.  Many
people are depending very heavily on the security properties of Xen
including the hardware emulations.  So for us it is important that we
take all the measures we can to stop us from accidentally committing
bugs.

If this is something that qemu upstream doesn't want then we will have
to maintain it as a permanent delta in our `Xen' tree (along with the
mapcache, etc. etc.)

It would be fine if there were in fact only one place where writes
take place.  But actually there are multiple routes at pretty much all
levels: multiple entrypoints (aio and not, pwrite or not), multiple
block drivers, in cow devices multiple read/write paths depending on
whether the block is already present in the diffs and multiple writes
to the .img for each requested write, etc.

> qemu-system-x86_64 -drive file=foo.img -drive file=boo.img,read-only=on
> 
> Down the road, you do a savevm.  savevm has to create a checkpoint in 
> all disk images.  The checkpoint will be empty in boo.img but it still 
> needs to create one.

Perhaps I don't understand clearly enough how you imagine this
scenario.  Surely when the snapshot is resumed it is sufficient for
the file boo.img to be identical ?

What are these checkpoints ?  Are they currently written by anything ?

I've tried to look for the code you would be referring to but I can't
seem to find it.  qemu_savevm_state just calls all the things recorded
with register_savevm and I can't seem to find anything that would do
anything to block drivers.  Of course there are many things in hw/*.c
that call register_savevm.  I looked in hw/ide.c too and it just saves
the state of the driver, and seems content to assume that the contents
(as seen through qemu's block driver abstract interface) of the block
device will be identical because nothing will change it between save
and restore.

If the file is opened read-only then qemu won't change it.  Are you
imagining a scenario where the cow img file would be modified by some
external process between save and restore ?  Surely that would be a
broken thing to do.

Or do you mean that the intent is to cope with the backing file
changing between save and restore and that therefore the whole backing
file will be copied into the .img ?

I'm afraid as you can see I'm still confused.

Ian.