On Thu, Sep 06, 2012 at 11:24:02AM +0200, Paolo Bonzini wrote: > Il 06/09/2012 10:47, Michael S. Tsirkin ha scritto: > >> > - 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@xxxxxxxxxx> > > 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. > > 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
