From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mnt8i-0006V2-1D for qemu-devel@nongnu.org; Wed, 16 Sep 2009 07:57:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mnt8c-0006Rk-Ne for qemu-devel@nongnu.org; Wed, 16 Sep 2009 07:57:35 -0400 Received: from [199.232.76.173] (port=45633 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mnt8c-0006RT-3g for qemu-devel@nongnu.org; Wed, 16 Sep 2009 07:57:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4968) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mnt8b-0000QJ-Ec for qemu-devel@nongnu.org; Wed, 16 Sep 2009 07:57:29 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n8GBvS5D017054 for ; Wed, 16 Sep 2009 07:57:28 -0400 Date: Wed, 16 Sep 2009 14:57:26 +0300 From: Gleb Natapov Message-ID: <20090916115726.GL23157@redhat.com> References: <20090916104620.GA4456@redhat.com> <20090916111845.GJ23157@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: [Qemu-devel] Re: optional feature List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: qemu-devel@nongnu.org, "Michael S. Tsirkin" On Wed, Sep 16, 2009 at 01:48:35PM +0200, Juan Quintela wrote: > Gleb Natapov wrote: > > On Wed, Sep 16, 2009 at 01:04:19PM +0200, Juan Quintela wrote: > >> "Michael S. Tsirkin" 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.