>> We should document our result of page poisoning, free page hinting, and >> free page reporting there as well. I hope you'll have time for the latter. >> >> ------------------------------------------------------------------------- >> Semantics of VIRTIO_BALLOON_F_PAGE_POISON >> ------------------------------------------------------------------------- >> >> "The VIRTIO_BALLOON_F_PAGE_POISON feature bit is used to indicate if the >> guest is using page poisoning. Guest writes to the poison_val config >> field to tell host about the page poisoning value that is in use." >> -> Very little information, no signs about what has to be done. > > I think it's an informational field. Knowing that free pages > are full of a specific pattern can be handy for the hypervisor > for a variety of reasons. E.g. compression/deduplication?
I was referring to the documentation of the feature and what we (hypervisor) are expected to do (in regards to inflation/deflation). Yes, it might be valuable to know that the guest is using poisoning. I assume compression/deduplication (IOW KSM) will figure out themselves that such pages are equal. >> "Let the hypervisor know that we are expecting a specific value to be >> written back in balloon pages." > > > >> -> Okay, that talks about "balloon pages", which would include right now >> -- pages "inflated" and then "deflated" using free page hinting >> -- pages "inflated" and then "deflated" using oridnary inflate/deflate >> queue > > ATM, in this case driver calls "free" and that fills page with the > poison value. Yes, that's what I mentioned somehwere, it's currently done by Linux and ... > > It might be a valid optimization to allow driver to skip > poisoning of freed pages in this case. ... we should prepare for that :) > >> And I would add >> >> "However, if the inflated page was not filled with "poison_val" when >> inflating, it's not predictable if the original page or a page filled >> with "poison_val" is returned." >> >> Which would cover the "we did not discard the page in the hypervisor, so >> the original page is still there". >> >> >> We should also document what is expected to happen if "poison_val" is >> suddenly changed by the guest at one point in time again. (e.g., not >> supported, unexpected things can happen, etc.) > > Right. I think we should require that this can only be changed > before features have been negotiated. > That is the only point where hypervisor can still fail > gracefully (i.e. fail FEATURES_OK). Agreed. I can totally understand if Alex would want to stop working on VIRTIO_BALLOON_F_PAGE_POISON at this point and only fix the guest to not enable free page reporting in case we don't have VIRTIO_BALLOON_F_PAGE_POISON (unless that's already done), lol. :) -- Thanks, David / dhildenb
