conf: Introduce virtio-mem <memory/> model
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 'current' 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).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-01-18 15:13:12 +00:00
|
|
|
<domain type='kvm'>
|
|
|
|
|
<name>QEMUGuest1</name>
|
|
|
|
|
<uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
|
|
|
|
|
<maxMemory slots='16' unit='KiB'>1099511627776</maxMemory>
|
|
|
|
|
<memory unit='KiB'>8388608</memory>
|
|
|
|
|
<currentMemory unit='KiB'>8388608</currentMemory>
|
|
|
|
|
<vcpu placement='static' cpuset='0-1'>2</vcpu>
|
|
|
|
|
<os>
|
|
|
|
|
<type arch='x86_64' machine='pc'>hvm</type>
|
|
|
|
|
<boot dev='hd'/>
|
|
|
|
|
</os>
|
|
|
|
|
<cpu mode='custom' match='exact' check='none'>
|
|
|
|
|
<model fallback='forbid'>qemu64</model>
|
|
|
|
|
<topology sockets='2' dies='1' cores='1' threads='1'/>
|
|
|
|
|
<numa>
|
|
|
|
|
<cell id='0' cpus='0-1' memory='2095104' unit='KiB'/>
|
|
|
|
|
</numa>
|
|
|
|
|
</cpu>
|
|
|
|
|
<clock offset='utc'/>
|
|
|
|
|
<on_poweroff>destroy</on_poweroff>
|
|
|
|
|
<on_reboot>restart</on_reboot>
|
|
|
|
|
<on_crash>destroy</on_crash>
|
|
|
|
|
<devices>
|
2022-01-04 15:36:46 +00:00
|
|
|
<emulator>/usr/bin/qemu-system-x86_64</emulator>
|
conf: Introduce virtio-mem <memory/> model
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 'current' 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).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-01-18 15:13:12 +00:00
|
|
|
<disk type='block' device='disk'>
|
|
|
|
|
<driver name='qemu' type='raw'/>
|
|
|
|
|
<source dev='/dev/HostVG/QEMUGuest1'/>
|
|
|
|
|
<target dev='hda' bus='ide'/>
|
|
|
|
|
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
|
|
|
|
|
</disk>
|
|
|
|
|
<controller type='ide' index='0'>
|
|
|
|
|
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
|
|
|
|
|
</controller>
|
|
|
|
|
<controller type='usb' index='0' model='piix3-uhci'>
|
|
|
|
|
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
|
|
|
|
|
</controller>
|
|
|
|
|
<controller type='pci' index='0' model='pci-root'/>
|
2022-02-02 14:57:43 +00:00
|
|
|
<controller type='pci' index='1' model='pci-bridge'>
|
|
|
|
|
<model name='pci-bridge'/>
|
|
|
|
|
<target chassisNr='1'/>
|
|
|
|
|
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
|
|
|
|
|
</controller>
|
conf: Introduce virtio-mem <memory/> model
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 'current' 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).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-01-18 15:13:12 +00:00
|
|
|
<input type='mouse' bus='ps2'/>
|
|
|
|
|
<input type='keyboard' bus='ps2'/>
|
|
|
|
|
<audio id='1' type='none'/>
|
|
|
|
|
<memballoon model='virtio'>
|
|
|
|
|
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
|
|
|
|
|
</memballoon>
|
|
|
|
|
<memory model='virtio-mem'>
|
|
|
|
|
<target>
|
|
|
|
|
<size unit='KiB'>1048576</size>
|
|
|
|
|
<node>0</node>
|
|
|
|
|
<block unit='KiB'>2048</block>
|
|
|
|
|
<requested unit='KiB'>524288</requested>
|
|
|
|
|
</target>
|
|
|
|
|
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
|
|
|
|
|
</memory>
|
|
|
|
|
<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>
|
2022-02-02 14:57:43 +00:00
|
|
|
<address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/>
|
conf: Introduce virtio-mem <memory/> model
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 'current' 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).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-01-18 15:13:12 +00:00
|
|
|
</memory>
|
|
|
|
|
</devices>
|
|
|
|
|
</domain>
|
