On Thu, Sep 06, 2012 at 11:24:02AM +0200, Paolo Bonzini wrote:

Il 06/09/2012 10:47, Michael S. Tsirkin ha scritto:

quoted

quoted

quoted

- a migration from non-MUST_TELL_HOST to MUST_TELL_HOST will succeed,
which is wrong;

- a migration from MUST_TELL_HOST to non-MUST_TELL_HOST will fail, which
is useless.

Add instead a new feature VIRTIO_BALLOON_F_SILENT_DEFLATE, and deprecate
VIRTIO_BALLOON_F_MUST_TELL_HOST since it is never actually used.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

Frankly I think it's a qemu migration bug. I don't see why
we need to tweak spec: just teach qemu to be smarter
during migration.

Of course you can just teach QEMU to be smarter, but that would be a
one-off hack for the only ill-defined feature that says something is
_not_ supported.  Since in practice all virtio_balloon-enbled
hypervisors supported silent deflate (so the bit was always zero), and
no client used it (so it was never checked), it's easier to just reverse
the direction.

In fact, it's not clear how the driver should use the feature.  My guess
is that, if it wants to use silent deflate, it tries to negotiate
VIRTIO_BALLOON_F_MUST_TELL_HOST, and can use silent deflate if
negotiation fails.  This is against the logic of all other features.

Let's take a step back from the implementation details.
You are trying to add a new feature bit, after all.
Why? Why is silent deflate useful? This is what is
missing in all this discussion. If it is not useful
we do not need a bit for it.

quoted

Can you show a scenario with old driver/new hypervisor or
new driver/old hypervisor that fails?

Suppose the driver tried to negotiate the feature as above.  We then
have the two scenarios above.

In the harmless but annoying scenario, the source hypervisor doesn't
support silent deflate, so VIRTIO_BALLOON_F_MUST_TELL_HOST has been
negotiated successfully.  The destination hypervisor supports silent
deflate, so it does _not_ include the feature.  It sees that the guest
requests VIRTIO_BALLOON_F_MUST_TELL_HOST, and fails migration.

In the incorrect scenario, you are migrating to an older hypervisor.
The source hypervisor is newer and supports silent deflate, so
VIRTIO_BALLOON_F_MUST_TELL_HOST was _not_ negotiated.  The destination
hypervisor does not supports silent deflate.  However, the guest is not
requesting VIRTIO_BALLOON_F_MUST_TELL_HOST, and migration succeeds.
Next time the guest tries to do use a page from the balloon, badness
happens, because the hypervisor does not expect it.

Paolo

Sorry this is not the example I asked for.  Please give and example
without migration.

Migration is qemu's problem: it is hypervisor's job to
make sure guest sees no change during migration.
It should be able to do this with any hardware it emulates,
there should be no need to change hardware to make it
"migrateable" somehow.

-- 
MST