Il 07/09/2012 12:53, Michael S. Tsirkin ha scritto: > Let us start with what is broken currently. Looking at > it very closely, I think the answer is nothing. > Even migration in qemu is not broken as you claimed initially. Correct, migration would be broken as soon as QEMU starts using MUST_TELL_HOST. I'm trying to think ahead, since we have many ideas floating around on the implementation of ballooning. If you implement the mlock/munlock trick, you must start using MUST_TELL_HOST in QEMU to advertise it to guests, and migration breaks. > Next, consider the interface proposed here. You defacto declare > all existing drivers buggy. No, only Windows (and it is buggy, it calls tell_host last). Linux and BSD drivers do negotiate MUST_TELL_HOST, and are not buggy. > This is a wrong thing to do. > You also use two feature bits for a single simple thing, > this is inelegant. True, but the choice is: 1) add a once-only hack to QEMU that fixes migration of VIRTIO_BALLOON_F_MUST_TELL_HOST; 2) always advertise VIRTIO_BALLOON_F_MUST_TELL_HOST. If you do this, guests cannot use anymore silent deflate, which is a regression. 3) use two bits. One tells the device that the driver supports chatty deflate; one tells the driver that the device supports silent deflate. So in the end you do use two feature bits for two different things. Plus, both feature bits are "positive" and I'm happy. > Last, let us consider how existing feature can be used > in the hypervisor. If driver did not ack > MUST_TELL_HOST, it is *not* buggy but it means we can not > do munlock. This applies to current windows drivers. > If driver *did* ack MUST_TELL_HOST, we can munlock > and mlock back on leak. > Seems useful, driver support is already there, > so removing the MUST_TELL_HOST bit seems like a bad idea. Indeed, repurposing MUST_TELL_HOST to WILL_TELL_HOST is better than killing it. Paolo -- 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
