[PATCH v2 05/13] conf: Introduce virtio-mem <memory/> model

[Daniel P. Berrangé]

On Thu, Feb 18, 2021 at 04:00:05PM +0100, David Hildenbrand wrote:
> On 18.02.21 14:31, Michal Privoznik wrote:
> > The virtio-mem is paravirtualized mechanism of adding/removing
> > memory to/from a VM. A virtio-mem-pci device is split into blocks
> > of equal size which are then exposed (all or only a requested
> > portion of them) to the guest kernel to use as regular memory.
> > Therefore, the device has two important attributes:
> > 
> >    1) block-size, which defines the size of a block
> >    2) requested-size, which defines how much memory (in bytes)
> >       is the device requested to expose to the guest.
> > 
> > The 'block-size' is configured on command line and immutable
> > throughout device's lifetime. The 'requested-size' can be set on
> > the command line too, but also is adjustable via monitor. In
> > fact, that is how management software places its requests to
> > change the memory allocation. If it wants to give more memory to
> > the guest it changes 'requested-size' to a bigger value, and if it
> > wants to shrink guest memory it changes the 'requested-size' to a
> > smaller value. Note, value of zero means that guest should
> > release all memory offered by the device. Of course, guest has to
> > cooperate. Therefore, there is a third attribute 'size' which is
> > read only and reflects how much memory the guest still has. This
> > can be different to 'requested-size', obviously. Because of name
> > clash, I've named it 'actualsize' and it is dealt with in future
> > commits (it is a runtime information anyway).
> > 
> > In the backend, memory for virtio-mem is backed by usual objects:
> > memory-backend-{ram,file,memfd} and their size puts the cap on
> > the amount of memory that a virtio-mem device can offer to a
> > guest. But we are already able to express this info using <size/>
> > under <target/>.
> > 
> > Therefore, we need only two more elements to cover 'block-size'
> > and 'requested-size' attributes. This is the XML I've came up
> > with:
> > 
> >    <memory model='virtio-mem'>
> >      <source>
> >        <nodemask>1-3</nodemask>
> >        <pagesize unit='KiB'>2048</pagesize>
> >      </source>
> >      <target>
> >        <size unit='KiB'>2097152</size>
> >        <node>0</node>
> >        <block unit='KiB'>2048</block>
> >        <requested unit='KiB'>1048576</requested>
> >      </target>
> >      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
> >    </memory>
> > 
> > I hope by now it is obvious that:
> > 
> >    1) 'requested-size' must be an integer multiple of
> >       'block-size', and
> >    2) virtio-mem-pci device goes onto PCI bus and thus needs PCI
> >       address.
> > 
> > Then there is a limitation that the minimal 'block-size' is
> > transparent huge page size (I'll leave this without explanation).
> > 
> > Since now we have (possibly) two or more devices that allow
> > memory inflation/deflation and accounting for all of them (and
> > thus keeping <currentMemory/> updated) might be hard. Therefore,
> > I'm deliberately forbidding memballoon. It's okay - virtio-mem is
> > superior to memballoon anyway. We can always reevaluate later.
> 
> That's a bad idea. It'll still be used for getting memory stats, free page
> hinting and free page reporting.

Yep, and this feature is broadly used in mgmt apps, so if we enforce this
mutual exclusion it is putting apps into a no-win scenario.

> Very weird use cases might even want to mix balloon inflation/deflation with
> virtio-mem ...

I'd feel less bad about blocking inflation/deflation, but that does go
against the general libvirt POV that we should leave usage policies upto
the mgmt app to decide upon.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|