[Qemu-devel] Re: optional feature

[Gleb Natapov <gleb@redhat.com>]

On Wed, Sep 16, 2009 at 01:48:35PM +0200, Juan Quintela wrote:
> Gleb Natapov <gleb@redhat.com> wrote:
> > On Wed, Sep 16, 2009 at 01:04:19PM +0200, Juan Quintela wrote:
> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >> > On Wed, Sep 09, 2009 at 10:47:27AM +0200, Juan Quintela wrote:
> >> >> How do we deal with optional features?
> >> >
> >> > Here's an idea that Gleb suggested in a private
> >> > conversation: make optional features into
> >> > separate, non-user-visible devices.
> >> >
> >> > Thus we would have vmstate for virtio and additionally, if msix is
> >> > enabled, vmstate for msix. This solves the problem of the number of
> >> > devices becoming exponential with the number of features: we have device
> >> > per feature.
> >> >
> >> > I understand that RTC does something like this.
> >> 
> >> And it is wrong :)  I sent a patch to fix it properly, but we have the
> >> problem of backward compatibility with kvm.
> >> 
> >> Forget msix for virtio, virtio has the problem already with pci.
> > What is wrong about it?
> 
> See below, we are changing the state to one table, and tables don't have
> neither if's or whiles (we have a limited for that just walks arrays).
> 
I don't know virtio enough to understand all those things below. I am
asking what is wrong about how RTC did it? You don't need if's or
whiles. You have general RTC sate in one table and things that needed by
rtc-td-hack in another table. From vmstate point of view those are not
connected. Serialization/deserialization should support matching of
incomming binary blob to deserialize function. When entire incomming
stream is consumed check has to be made that there is no uninitialized
table (deserialize callback that was not called) and if there is -
abort.

--
			Gleb.