From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MnwhY-0004iG-If for qemu-devel@nongnu.org; Wed, 16 Sep 2009 11:45:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MnwhU-0004i2-1A for qemu-devel@nongnu.org; Wed, 16 Sep 2009 11:45:48 -0400 Received: from [199.232.76.173] (port=45492 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MnwhT-0004hz-RP for qemu-devel@nongnu.org; Wed, 16 Sep 2009 11:45:43 -0400 Received: from mail-yx0-f201.google.com ([209.85.210.201]:39927) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MnwhT-0003wN-6b for qemu-devel@nongnu.org; Wed, 16 Sep 2009 11:45:43 -0400 Received: by yxe39 with SMTP id 39so6388829yxe.18 for ; Wed, 16 Sep 2009 08:45:42 -0700 (PDT) Message-ID: <4AB10824.1030904@codemonkey.ws> Date: Wed, 16 Sep 2009 10:45:40 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: optional feature References: <20090916111845.GJ23157@redhat.com> <20090916115726.GL23157@redhat.com> <20090916123535.GM23157@redhat.com> <4AB0F17B.7000107@codemonkey.ws> <20090916141245.GC5287@redhat.com> <4AB0F45A.7000100@codemonkey.ws> <20090916143459.GD5287@redhat.com> In-Reply-To: <20090916143459.GD5287@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org, Gleb Natapov , Juan Quintela Michael S. Tsirkin wrote: >>> If instead we would only save/load the part of state if >>> the knob is set, we won't have a problem. >>> >>> >> The rtc device happens to support an optional feature by splitting the >> optional bits into a separate section. Not every device does this >> though so if you want to convert other devices to this style, you'll >> break their backwards compatibility. >> >> The mechanisms are functionally the same. One is no more expressive >> than the other. >> > > Yes, separate devices variant is more expressive. > Not when you consider my proposed syntax: .fields = (VMStateField []) { VMSTATE_BOOL(td_hack, RTCState, (VMStateField[]){ VMSTATE_INT32(irq_coalesced, RTCState), VMSTATE_INT32(period, RTCState), VMSTATE_END_OF_LIST()}), } You could clearly encode this on the wire as a separate section. You could autogenerate the name as "rtc-td_hack". It won't be backwards compatible for save but that's okay. We can hack things together to make it backwards compatible on load. I don't like this as a wire format though. The point though is that if we get the VMState syntax right, then we can make whatever changes down the road we need. > It is more modular. With optional features A B C, versioning can not > support saving only A and C but not B. This is bad for example for > backporting features between versions: if C happened to be introduced > after B, backporting C will force backporting B. > The real argument is against linear versioning. The whole "optional feature" thing is almost orthogonal. If we want to support downstream versioning, then I think we should attack that problem properly instead of shoe horning it via "optional features". This would involve introducing a v4 of the savevm protocol that allowed for a minor versions of device state. QEMU would always set the minor version to 0. If downstream decides to introduce changes, they can bump the minor version for a device. We can also add a minor version to the savevm protocol itself along with a vendor id. This lets a vendor identify itself and allows the vendor to change the savevm protocol. We can use reverse fqdn for vendor id to avoid id distribution issues. This solves a number of problems. If qemu-kvm decides to change a device's state, they can increment a minor version of that device and set the vendor id to one allocated for qemu-kvm. Since qemu-kvm has other downstreams, it should also bump the savevm protocol minor version to introduce an additional vendor id/device minor number. This way if Fedora/RHEL decides to backport a feature into qemu-kvm, they can set their own vendor id and also bump the secondary minor version. This gives downstreams nice, non-linear versioning that they can use and extend indefinitely. It also provides a way to detect whether it's possible to migrate a VM from one vendor's qemu to another. For instance, even though RHEL may have backported a feature, if that feature isn't used for a particular VM, it's still migratable to an upstream version. We determine this is an entirely programmatic way. It cannot migrate when that feature is enabled (even to a newer qemu that has the feature) but to me, that's a not a negative thing. > if you are not saving irq state, it's better > to skip the array that create a 0 size array. > The former works for non-array fields, the later does not, > and you have to invent a separate valid bit. > I think that's a minor wire detail that has nothing to do with the table format. Regards, Anthony Liguori