search for: silent_defl

...4) if the balloon has to enter a "degraded" mode of operation when > guests do not "tell first", this has to happen only for old guests I don't agree with this either. I think if we make tell host optional, it's up to the guest whether to tell host. > > Once SILENT_DEFLATE is added, your patch prevents fulfilling > requirements (3) and (4) together, at least in a Linux driver. Let's keep adding new bits out of it, we'll discuss patch 2 when we are done with patch 1. > Basically, you're saying that the driver should set MUST_TELL_HOST to > !S...

On Tue, May 28, 2013 at 07:40:17PM +0200, Paolo Bonzini wrote: > The idea of the VIRTIO_BALLOON_F_MUST_TELL_HOST feature was to let drivers > skip usage of the deflate queue when leaking the balloon ("silent > deflation"). Guests may benefit from silent deflate by aggressively > inflating the balloon; they know that they will be able to use ballooned > pages without

...though it is okay if they do not use silent deflation 3) if both the balloon and the driver supports silent deflation, it should be used 4) if the balloon has to enter a "degraded" mode of operation when guests do not "tell first", this has to happen only for old guests Once SILENT_DEFLATE is added, your patch prevents fulfilling requirements (3) and (4) together, at least in a Linux driver. Basically, you're saying that the driver should set MUST_TELL_HOST to !SILENT_DEFLATE. However, in the Linux virtio implementation, features are independent, and the feature list is told...

...t; >>>>> 1. Handling of VIRTIO_F_GUEST_MUST_TELL_HOST >>>>> Is this functionally identical to what I proposed? >>>>> If yes, I am fine with either change being applied. >>>> >>>> Yes. >>>> >>>>> 2. New SILENT_DEFLATE feature >>>>> Since guest can get same functionality by not acking >>>>> TELL_HOST, I still don't see what good it does: >>>>> Historically a host with no features supports silent >>>>> deflate and guest with no features can do...

...n if the target does not support all the features that were negotiated. But then: - 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 at redhat.com> --- virtio-spec.lyx | 36 +++++++++++++++++++++++++++++++++--- 1 file modificato, 33 inserzioni(+), 3 rimozioni(-) diff --git a/virtio-spec.lyx b/virtio-...

...n if the target does not support all the features that were negotiated. But then: - 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 at redhat.com> --- virtio-spec.lyx | 36 +++++++++++++++++++++++++++++++++--- 1 file modificato, 33 inserzioni(+), 3 rimozioni(-) diff --git a/virtio-spec.lyx b/virtio-...

...Michael S. Tsirkin ha scritto: > At this point I am confused. I think there are two changes in your patch: > > 1. Handling of VIRTIO_F_GUEST_MUST_TELL_HOST > Is this functionally identical to what I proposed? > If yes, I am fine with either change being applied. Yes. > 2. New SILENT_DEFLATE feature > Since guest can get same functionality by not acking > TELL_HOST, I still don't see what good it does: > Historically a host with no features supports silent > deflate and guest with no features can do silent deflate. > I conclude silent deflate is the default b...

...I think there are two changes in your patch: >>> >>> 1. Handling of VIRTIO_F_GUEST_MUST_TELL_HOST >>> Is this functionally identical to what I proposed? >>> If yes, I am fine with either change being applied. >> >> Yes. >> >>> 2. New SILENT_DEFLATE feature >>> Since guest can get same functionality by not acking >>> TELL_HOST, I still don't see what good it does: >>> Historically a host with no features supports silent >>> deflate and guest with no features can do silent deflate. >>> I...

...dling of VIRTIO_F_GUEST_MUST_TELL_HOST > >>>>> Is this functionally identical to what I proposed? > >>>>> If yes, I am fine with either change being applied. > >>>> > >>>> Yes. > >>>> > >>>>> 2. New SILENT_DEFLATE feature > >>>>> Since guest can get same functionality by not acking > >>>>> TELL_HOST, I still don't see what good it does: > >>>>> Historically a host with no features supports silent > >>>>> deflate and guest with...

Il 28/05/2013 13:44, Michael S. Tsirkin ha scritto: > negotiated in spec means "present and acked by guest". > We can try and replace "negotiated" by "present and acked by guest" > everywhere - think it will be clearer? No, I understand what negotiated means. But in this case, "negotiated" is not the word that you want. >>>> Now

...his point I am confused. I think there are two changes in your patch: > > > > 1. Handling of VIRTIO_F_GUEST_MUST_TELL_HOST > > Is this functionally identical to what I proposed? > > If yes, I am fine with either change being applied. > > Yes. > > > 2. New SILENT_DEFLATE feature > > Since guest can get same functionality by not acking > > TELL_HOST, I still don't see what good it does: > > Historically a host with no features supports silent > > deflate and guest with no features can do silent deflate. > > I conclude silent...

...existing bit to > VIRTIO_F_GUEST_TELLS_HOST. > > Paolo At this point I am confused. I think there are two changes in your patch: 1. Handling of VIRTIO_F_GUEST_MUST_TELL_HOST Is this functionally identical to what I proposed? If yes, I am fine with either change being applied. 2. New SILENT_DEFLATE feature Since guest can get same functionality by not acking TELL_HOST, I still don't see what good it does: Historically a host with no features supports silent deflate and guest with no features can do silent deflate. I conclude silent deflate is the default behaviour for both host a...

...atch: > >>> > >>> 1. Handling of VIRTIO_F_GUEST_MUST_TELL_HOST > >>> Is this functionally identical to what I proposed? > >>> If yes, I am fine with either change being applied. > >> > >> Yes. > >> > >>> 2. New SILENT_DEFLATE feature > >>> Since guest can get same functionality by not acking > >>> TELL_HOST, I still don't see what good it does: > >>> Historically a host with no features supports silent > >>> deflate and guest with no features can do silent defla...