On Fri, Jun 16, 2017 at 05:59:07PM +0200, David Hildenbrand wrote: > On 16.06.2017 17:04, Michael S. Tsirkin wrote: > > On Fri, Jun 16, 2017 at 04:20:02PM +0200, David Hildenbrand wrote: > >> Hi, > >> > >> this is an idea that is based on Andrea Arcangeli's original idea to > >> host enforce guest access to memory given up using virtio-balloon using > >> userfaultfd in the hypervisor. While looking into the details, I > >> realized that host-enforcing virtio-balloon would result in way too many > >> problems (mainly backwards compatibility) and would also have some > >> conceptual restrictions that I want to avoid. So I developed the idea of > >> virtio-mem - "paravirtualized memory". > > > > Thanks! I went over this quickly, will read some more in the > > coming days. I would like to ask for some clarifications > > on one part meanwhile: > > Thanks for looking into it that fast! :) > > In general, what this section is all about: Why to not simply host > enforce virtio-balloon. > > > >> Q: Why not reuse virtio-balloon? > >> > >> A: virtio-balloon is for cooperative memory management. It has a fixed > >> page size > > > > We are fixing that with VIRTIO_BALLOON_F_PAGE_CHUNKS btw. > > I would appreciate you looking into that patchset. > > Will do, thanks. Problem is that there is no "enforcement" on the page > size. VIRTIO_BALLOON_F_PAGE_CHUNKS simply allows to send bigger chunks. > Nobody hinders the guest (especially legacy virtio-balloon drivers) from > sending 4k pages. > > So this doesn't really fix the issue (we have here), it just allows to > speed up transfer. Which is a good thing, but does not help for > enforcement at all. So, yes support for page sizes > 4k, but no way to > enforce it. > > > > >> and will deflate in certain situations. > > > > What does this refer to? > > A Linux guest will deflate the balloon (all or some pages) in the > following scenarios: > a) page migration It inflates it first, doesn't it? > b) unload virtio-balloon kernel module > c) hibernate/suspension > d) (DEFLATE_ON_OOM) You need to set a flag in the balloon to allow this, right? > A Linux guest will touch memory without deflating: > a) During a kexec() dump > d) On reboots (regular, after kexec(), system_reset) > > > >> Any change we > >> introduce will break backwards compatibility. > > > > Why does this have to be the case > If we suddenly enforce the existing virtio-balloon, we will break legacy > guests. Can't we do it with a feature flag? > Simple example: > Guest with inflated virtio-balloon reboots. Touches inflated memory. > Gets killed at some random point. > > Of course, another discussion would be "can't we move virtio-mem > functionality into virtio-balloon instead of changing virtio-balloon". > With the current concept this is also not possible (one region per > device vs. one virtio-balloon device). And I think while similar, these > are two different concepts. > > > > >> virtio-balloon was not > >> designed to give guarantees. Nobody can hinder the guest from > >> deflating/reusing inflated memory. > > > > Reusing without deflate is forbidden with TELL_HOST, right? > > TELL_HOST just means "please inform me". There is no way to NACK a > request. It is not a permission to do so, just a "friendly > notification". And this is exactly not what we want when host enforcing > memory access. > > > > > >> In addition, it might make perfect > >> sense to have both, virtio-balloon and virtio-mem at the same time, > >> especially looking at the DEFLATE_ON_OOM or STATS features of > >> virtio-balloon. While virtio-mem is all about guarantees, virtio- > >> balloon is about cooperation. > > > > Thanks, and I intend to look more into this next week. > > > > I know that it is tempting to force this concept into virtio-balloon. I > spent quite some time thinking about this (and possible other techniques > like implicit memory deflation on reboots) and decided not to do it. We > just end up trying to hack around all possible things that could go > wrong, while still not being able to handle all requirements properly. I agree there's a large # of requirements here not addressed by the balloon. One other thing that would be helpful here is pointing out the similarities between virtio-mem and the balloon. I'll ponder it over the weekend. The biggest worry for me is inability to support DMA into this memory. Is this hard to fix? Thanks! > -- > > Thanks, > > David -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
