From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id D9AFB986303 for ; Tue, 20 Jul 2021 10:48:54 +0000 (UTC) From: Cornelia Huck In-Reply-To: References: <8a2037df-e527-dcb4-c4c8-a568885180e4@redhat.com> <094e15d4-169a-87e9-5ebb-93439ea72831@redhat.com> <1ab19438-cc13-bbe5-7fec-53a113d85463@redhat.com> <0213e6c2-59aa-f140-7231-36231b42051d@redhat.com> Date: Tue, 20 Jul 2021 12:48:43 +0200 Message-ID: <87o8ax8dmc.fsf@redhat.com> MIME-Version: 1.0 Subject: Re: [virtio-comment] [PATCH V2 2/2] virtio: introduce STOP status bit Content-Type: text/plain To: Stefan Hajnoczi , Jason Wang Cc: "Michael S. Tsirkin" , Eugenio Perez Martin , "Dr. David Alan Gilbert" , virtio-comment@lists.oasis-open.org, Virtio-Dev , Max Gurtovoy , Oren Duer , Shahaf Shuler , Parav Pandit , Bodong Wang , Alexander Mikheev , Halil Pasic List-ID: On Tue, Jul 20 2021, Stefan Hajnoczi wrote: > On Tue, Jul 20, 2021 at 11:04:55AM +0800, Jason Wang wrote: >> Let me clarify, I agree we can't have a standard device state for all kinds >> of device. >> >> That's way I tend to leave them to be device specific. (but not >> implementation specific) > > Unfortunately device state is sometimes implementation-specific. Not > because the device is proprietary, but because the actual state is > meaningless to other implementations. > > I mentioned virtiofs as an example where file system backends can be > implemented in completely different ways so the device state cannot be > migrated between implementations. > >> But we can generalize the virtqueue state for sure. > > I agree and also that some device types can standardize their device > state representations. But I think it's a technical requirement to > support implementation-specific state for device types where > cross-implementation migration is not possible. > > I'm not saying the implementation-specific state representation has to > be a binary blob. There could be an identifier registry to ensure live > migration compatibility checks can be performed. There could also be a > standard binary encoding for migration data. But the contents will be > implementation-specific for some devices. Can we at least put those implementation-specific states into some kind of structured, standardized form? E.g. something like so that we can at least do compat checks for "I know how to handle foo"? This publicly archived list offers a means to provide input to the OASIS Virtual I/O Device (VIRTIO) TC. In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting. Subscribe: virtio-comment-subscribe@lists.oasis-open.org Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org List help: virtio-comment-help@lists.oasis-open.org List archive: https://lists.oasis-open.org/archives/virtio-comment/ Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists Committee: https://www.oasis-open.org/committees/virtio/ Join OASIS: https://www.oasis-open.org/join/