search for: virtio_balloon_f_must_tell_host

[...] >> >> Issue 2: When called via the shrinker, (but also to fix Issue 1), it could be >> that we do have VIRTIO_BALLOON_F_MUST_TELL_HOST. I assume this means >> (-ENOCLUE) that we have to wait until the hypervisor notifies us via the STOP? Or >> for which event do we have to wait? Because there is no way to *tell host* here >> that we want to reuse a page. The hypervisor will *tell us* when we can reuse pages. >...

[...] >> >> Issue 2: When called via the shrinker, (but also to fix Issue 1), it could be >> that we do have VIRTIO_BALLOON_F_MUST_TELL_HOST. I assume this means >> (-ENOCLUE) that we have to wait until the hypervisor notifies us via the STOP? Or >> for which event do we have to wait? Because there is no way to *tell host* here >> that we want to reuse a page. The hypervisor will *tell us* when we can reuse pages. >...

...hinting feature >>>> (everything on free_page_list). >>>> >>>> So instead of only reverting, I think we should split it up and always >>>> register the shrinker for VIRTIO_BALLOON_F_FREE_PAGE_HINT and the OOM >>>> notifier (as before) for VIRTIO_BALLOON_F_MUST_TELL_HOST. >> >> s/VIRTIO_BALLOON_F_MUST_TELL_HOST/VIRTIO_BALLOON_F_DEFLATE_ON_OOM/ >> >> :) > > Well VIRTIO_BALLOON_F_MUST_TELL_HOST is also broken by shrinker > with VIRTIO_BALLOON_F_FREE_PAGE_HINT as that code adds buffers > but does not wait for them to be used even w...

...hinting feature >>>> (everything on free_page_list). >>>> >>>> So instead of only reverting, I think we should split it up and always >>>> register the shrinker for VIRTIO_BALLOON_F_FREE_PAGE_HINT and the OOM >>>> notifier (as before) for VIRTIO_BALLOON_F_MUST_TELL_HOST. >> >> s/VIRTIO_BALLOON_F_MUST_TELL_HOST/VIRTIO_BALLOON_F_DEFLATE_ON_OOM/ >> >> :) > > Well VIRTIO_BALLOON_F_MUST_TELL_HOST is also broken by shrinker > with VIRTIO_BALLOON_F_FREE_PAGE_HINT as that code adds buffers > but does not wait for them to be used even w...

...k the shrinker makes sense for free page hinting feature >> (everything on free_page_list). >> >> So instead of only reverting, I think we should split it up and always >> register the shrinker for VIRTIO_BALLOON_F_FREE_PAGE_HINT and the OOM >> notifier (as before) for VIRTIO_BALLOON_F_MUST_TELL_HOST. s/VIRTIO_BALLOON_F_MUST_TELL_HOST/VIRTIO_BALLOON_F_DEFLATE_ON_OOM/ :) >> >> (Of course, adapting what is being done in the shrinker and in the OOM >> notifier) > > David, > > Please keep me posted. I decided to adapt the same solution as the virtio > balloon f...

...k the shrinker makes sense for free page hinting feature >> (everything on free_page_list). >> >> So instead of only reverting, I think we should split it up and always >> register the shrinker for VIRTIO_BALLOON_F_FREE_PAGE_HINT and the OOM >> notifier (as before) for VIRTIO_BALLOON_F_MUST_TELL_HOST. s/VIRTIO_BALLOON_F_MUST_TELL_HOST/VIRTIO_BALLOON_F_DEFLATE_ON_OOM/ :) >> >> (Of course, adapting what is being done in the shrinker and in the OOM >> notifier) > > David, > > Please keep me posted. I decided to adapt the same solution as the virtio > balloon f...

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 issuing a (blocking) request to the devi...

...;>>> (everything on free_page_list). > >>>> > >>>> So instead of only reverting, I think we should split it up and always > >>>> register the shrinker for VIRTIO_BALLOON_F_FREE_PAGE_HINT and the OOM > >>>> notifier (as before) for VIRTIO_BALLOON_F_MUST_TELL_HOST. > >> > >> s/VIRTIO_BALLOON_F_MUST_TELL_HOST/VIRTIO_BALLOON_F_DEFLATE_ON_OOM/ > >> > >> :) > > > > Well VIRTIO_BALLOON_F_MUST_TELL_HOST is also broken by shrinker > > with VIRTIO_BALLOON_F_FREE_PAGE_HINT as that code adds buffers > > but...

...hat for correctness the existing feature is enough: if it is not negotiated by the guest, the host ensures correctness by only giving the guest a fake balloon. However, the new feature is about optimization, not correctness. In fact, VIRTIO_BALLOON_F_SILENT_DEFLATE is the optimization feature that VIRTIO_BALLOON_F_MUST_TELL_HOST was meant to be. What I'm interested in, is drivers that can _optionally_ use silent deflation (as an optimization). These should not get a fake balloon! With the new feature bit, these drivers should propose both VIRTIO_BALLOON_F_GUEST_TELLS_HOST and VIRTIO_BALLOON_F_SILENT_DEFLATE. The dr...

VIRTIO_BALLOON_F_MUST_TELL_HOST cannot be used properly because it is a "negative" feature: it tells you that silent defalte is not supported. Right now, QEMU refuses migration 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 s...

VIRTIO_BALLOON_F_MUST_TELL_HOST cannot be used properly because it is a "negative" feature: it tells you that silent defalte is not supported. Right now, QEMU refuses migration 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 s...

...ng feature is enough: > if it is not negotiated by the guest, the host ensures correctness by > only giving the guest a fake balloon. > > However, the new feature is about optimization, not correctness. > In fact, VIRTIO_BALLOON_F_SILENT_DEFLATE is the optimization > feature that VIRTIO_BALLOON_F_MUST_TELL_HOST was meant to be. > > What I'm interested in, is drivers that can _optionally_ use silent > deflation (as an optimization). These should not get a fake balloon! > > With the new feature bit, these drivers should propose both > VIRTIO_BALLOON_F_GUEST_TELLS_HOST and VIRTIO_BA...

...tiated by the guest, the host ensures correctness by > >> only giving the guest a fake balloon. > >> > >> However, the new feature is about optimization, not correctness. > >> In fact, VIRTIO_BALLOON_F_SILENT_DEFLATE is the optimization > >> feature that VIRTIO_BALLOON_F_MUST_TELL_HOST was meant to be. > >> > >> What I'm interested in, is drivers that can _optionally_ use silent > >> deflation (as an optimization). These should not get a fake balloon! > >> > >> With the new feature bit, these drivers should propose both > >...

...gt;> if it is not negotiated by the guest, the host ensures correctness by >> only giving the guest a fake balloon. >> >> However, the new feature is about optimization, not correctness. >> In fact, VIRTIO_BALLOON_F_SILENT_DEFLATE is the optimization >> feature that VIRTIO_BALLOON_F_MUST_TELL_HOST was meant to be. >> >> What I'm interested in, is drivers that can _optionally_ use silent >> deflation (as an optimization). These should not get a fake balloon! >> >> With the new feature bit, these drivers should propose both >> VIRTIO_BALLOON_F_GUEST_TE...

On Wednesday, February 5, 2020 12:50 AM, Michael S. Tsirkin wrote: > > Michael, any clue on which event we have to wait with > > VIRTIO_BALLOON_F_MUST_TELL_HOST? IMHO, I don't think > > VIRTIO_BALLOON_F_MUST_TELL_HOST applies to > > VIRTIO_BALLOON_F_FREE_PAGE_HINT and we'd better document that. It > introduces complexity with no clear benefit. > > I meant that we must wait for host to see the hint. Why? Best, Wei

On Wednesday, February 5, 2020 12:50 AM, Michael S. Tsirkin wrote: > > Michael, any clue on which event we have to wait with > > VIRTIO_BALLOON_F_MUST_TELL_HOST? IMHO, I don't think > > VIRTIO_BALLOON_F_MUST_TELL_HOST applies to > > VIRTIO_BALLOON_F_FREE_PAGE_HINT and we'd better document that. It > introduces complexity with no clear benefit. > > I meant that we must wait for host to see the hint. Why? Best, Wei

On Tue, Feb 04, 2020 at 05:56:22PM +0100, David Hildenbrand wrote: > [...] > > >> > >> Issue 2: When called via the shrinker, (but also to fix Issue 1), it could be > >> that we do have VIRTIO_BALLOON_F_MUST_TELL_HOST. I assume this means > >> (-ENOCLUE) that we have to wait until the hypervisor notifies us via the STOP? Or > >> for which event do we have to wait? Because there is no way to *tell host* here > >> that we want to reuse a page. The hypervisor will *tell us* when we can re...

Unless the host requires that requested pages won't be used until he us notified (VIRTIO_BALLOON_F_MUST_TELL_HOST), only notify after deflating the balloon. This will avoid having to take an exit before actually using the pages. Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: "Michael S. Tsirkin" <mst at redhat.com> Cc: virtualization at lists.linux-foundation.org Cc: kvm at vger.kerne...

Unless the host requires that requested pages won't be used until he us notified (VIRTIO_BALLOON_F_MUST_TELL_HOST), only notify after deflating the balloon. This will avoid having to take an exit before actually using the pages. Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: "Michael S. Tsirkin" <mst at redhat.com> Cc: virtualization at lists.linux-foundation.org Cc: kvm at vger.kerne...

The idea of the VIRTIO_BALLOON_F_MUST_TELL_HOST feature is 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 issuing a (blocking) request to the devic...