Re: [Qemu-devel] [PATCH v7 0/5] virtio-balloon: free page hint reporting support

[Peter Xu]

On Fri, Jun 01, 2018 at 04:33:29PM +0100, Dr. David Alan Gilbert wrote:

[...]

> > > > Meanwhile, this reminds me about a more funny idea: whether we can
> > > > just avoid sending the zero pages directly from QEMU's perspective.
> > > > In other words, can we just do nothing if save_zero_page() detected
> > > > that the page is zero (I guess the is_zero_range() can be fast too,
> > > > but I don't know exactly how fast it is)?  And how that would be
> > > > differed from this page hinting way in either performance and other
> > > > aspects.
> > > 
> > > I guess you referred to the zero page optimization. I think the major
> > > overhead comes to the zero page checking - lots of memory accesses, which
> > > also waste memory bandwidth. Please see the results attached in the cover
> > > letter. The legacy case already includes the zero page optimization.
> > 
> > I replied in the other thread.  We can discuss there altogether.
> > 
> > Actually after a second thought I think maybe what I worried there is
> > exactly the reason why we must send the zero page flag - otherwise
> > there can be stale non-zero page on destination.  Here "zero page" and
> > "freed page" is totally different idea since even if a page is zeroed
> > it might still be in use (not freed)!  While instead for a "free page"
> > even if it's non-zero we might be able to not send it at all, though I
> > am not sure whether that mismatch of data might cause any side effect
> > too. I think the corresponding question would be: if a page is freed
> > in Linux kernel, would its data matter any more?
> 
> I think the answer is no - it doesn't matter; by telling the hypervisor
> the page is 'free' the kernel gives freedom to the hypervisor to
> discard the page contents.

Yeh it seems so.  I just read over the whole work so I think there is
a future work for the poisoned bits.  If that's the only usage that
might make the content of freed page meaningful then it seems fine to
me.  After all I don't know much about that...  However still this
seems to be a bit tricky, e.g., we need to be very careful on the
guest OS side (when writting up the balloon driver for one guest OS)
to make sure of that otherwise it'll be very easy to break a guest
when something similar is enabled without our notice just like the
poisoned feature.

> Now, that is trusting the kernel to get it's 'free' flags right,
> and we wouldn't want a malicious guest kernel to be able to read random
> data, so we have to be a little careful that what actually lands
> in there is something the guest has had at some point - or zero
> which is a very nice empty value.

Yeah I agree - basically this feature brings more trouble from the
security POV, but I don't know whether that can be a problem since
after all we can disable this when we care very much about security.

Regards,

-- 
Peter Xu