Il 27/05/2013 19:02, Michael S. Tsirkin ha scritto: >>> So if we don't want to require all guests to tell host >>> first, all we need to do is admit it's not a bug. >> >> I think we want the possibility for the host to require that. > > But why? TELL_HOST makes some optimizations possible, but if > guest won't cooperate, balloon is useless anyway. If the guest won't tell host and still propose the feature, then we can crash it. So we need to know what the guest is going to do, in order to enable/disable the optimization. > If guest cooperates we don't have to require anything, > just go with what guest tells us it will do. Yes. >>> Please see >>> [PATCH] virtio-spec: balloon: MUST_TELL_HOST is optional >>> that does exactly this. >> >> That patch mandates a change in guest behavior that is not compatible >> with the existing Windows driver. Mine doesn't. >> >> Paolo > > Hmm I don't see it. > In fact the goal was to document the Windows driver behaviour > as correct. > Can you explain the incompatibility please? Whenever "If the X feature is (not) negotiated" is used in the spec, it means "in general you should be ready to implement both behaviors", or perhaps the guest should fail to initialize if the feature is not available. Here it is the other way round. The existing guest is not checking the outcome of the negotiation, so the host must check whether negotiation happened and possibly fail the initialization of the device. It is sufficiently different from any other case that I don't think a one-word change is enough. The way I read it yesterday I didn't see any change from the current specification, so the problem of having a "negative feature" remains. Now rereading it, it may be correct, but it is not clear enough. Perhaps my patch is even too verbose, but it doesn't leave anything open for interpretation. 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
