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

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.

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