On Tue, May 12, 2015 at 03:14:53PM +0200, Cornelia Huck wrote:

On Wed, 06 May 2015 14:07:37 +0200
Greg Kurz [off-list ref] wrote:

quoted

Unlike with add and clear, there is no valid reason to abort when checking
for a feature. It makes more sense to return false (i.e. the feature bit
isn't set). This is exactly what __virtio_has_feature() does if fbit >= 32.

This allows to introduce code that is aware about new 64-bit features like
VIRTIO_F_VERSION_1, even if they are still not implemented.

Signed-off-by: Greg Kurz <redacted>
---
 include/hw/virtio/virtio.h |    1 -
 1 file changed, 1 deletion(-)

diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index d95f8b6..6ef70f1 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h

@@ -233,7 +233,6 @@ static inline void virtio_clear_feature(uint32_t *features, unsigned int fbit)

 static inline bool __virtio_has_feature(uint32_t features, unsigned int fbit)
 {
-    assert(fbit < 32);
     return !!(features & (1 << fbit));
 }

I must say I'm not very comfortable with knowingly passing out-of-rage
values to this function.

Can we perhaps apply at least the feature-bit-size extending patches
prior to your patchset, if the remainder of the virtio-1 patchset still
takes some time?

So the feature-bit-size extending patches currently don't support
migration correctly, that's why they are not merged.

What I think we need to do for this is move host_features out
from transports into core virtio device.

Then we can simply check host features >31 and skip
migrating low guest features is none set.

Thoughts? Any takers?

-- 
MST