qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: optional feature


From: Juan Quintela
Subject: [Qemu-devel] Re: optional feature
Date: Wed, 16 Sep 2009 14:13:06 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

"Michael S. Tsirkin" <address@hidden> wrote:
> On Wed, Sep 16, 2009 at 01:04:19PM +0200, Juan Quintela wrote:

>> And no, I don't have either a clean design that will be backward
>> compatible and clean.
>
> The reason seems to be that you already decided what is clean

Somebody has to do the difficult things :)

> (below) and it is not backwards compatible :)
>
>> Clean design is easy:
>> 
>> virtio
>> virtio-pci (it does the equivalent of save_config() and then call
>>             virtio_save)
>> virtio-pci-msix (it calls virtio-pci and then send a partial array of
>> queues. (the save queue thing)
>> 
>> Before you ask, partial arrays are sent: <num_elems> + array
>> where num_elems == 0 is valid.
>
> So writing num_elems == 0 in the image is wrong imo, we should have a
> way to skip the array altogether.  This will let as add any number of
> arrays down the road, and have them treated as zero size if an old image
> is loaded.

No, this means that elements can appear form nowhere.  That is wrong.
I have no problem adding new elements, you just up the version field,
and here you go.  The problem here is _implicit_ information that is
_nowhere_ to be seen.

What you are asking for is (basically):

- I am more clever that VMState, and I will always do the right thing,
  please let me alone.

What I am not doubting that is true, just that VMState is here to help
the rest of us that normally get the things wrong.

VMState rules are simple:
- Everything is explicit
- You can add a field -> you inc the version number
- Everything is explicit
- You never remove a field (you can send a dummy value, and ignore its
- Everything is explicit
  value on reception), you just never remove it.
- Everything is explicit
- You can load old versions of the state (that is your option)
- Everything is explicit
- The type of the field that you send and the type of what you send
  have to be the same.
- Everything is explicit
- You can send simple types (int32_t, and similars)
- Everything is explicit
- You can send structs (basically another description)
- Everything is explicit
- You can send arrays
- Everything is explicit
- You can send partial arrays
- Everything is explicit
- You can send pointers, but it is better if you don't use them
  (not for VMState, just to get things right)
- Everything is explicit

And that is it.  There are still no helpers for sending num_elems +
array elems.

What does VMState gives you:
- It will make the load/save function for you
- It will make sure that the types that you are saving/loading and the
  types of the variables are right
- If you send full arrays, it will make sure that the length that you sent
  is the same that the one defined
- If you use pointers, you still have typechecking, but you lost size
  checking.

What VMState would give you:
being able to manipulate save images, this is the principal reason why
everything has to be explicit.  You can't save/load anything that is
not described in the VMState.  Obviously, anything that depends on the
device state that is _not_ saved, can't be manipulated.

This is the reason why 0 length arrays that you don't know where they
came from, can't be used.  And no, seeing that you can look in the pci
config space, command line options, etc will not work.  If you want a
new field, you told vmstate how to calculate/use it.

VMState was not created to have something more powerful that we had (we
already had a stream of bytes), it was created to have something easier
to use, and something that you could do things with it (like changing
how things are saved/loaded without having to change all the devices
code).

Obviously that is at odds with:  my device knows how to magically know
that here, it is going to came a new field.  And magically here means in
a way that you are not telling vmstate how to handle it.  And telling
VMState how to handle it is:  here is this new field that I want you to
save, and now that we have another field, it is a new version.

The design plan is that you have a device on version 5, you receive an
image for that device in version 5, and you are _not_ able to load it.
You here means VMState, not the device.

Later, Juan.




reply via email to

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