[PATCH v5 00/16] Introduce virtio-mem <memory/> model

[David Hildenbrand]

On 14.09.21 14:34, David Hildenbrand wrote:
> On 13.09.21 16:52, Michal Privoznik wrote:
>> v4 of:
>>
>> https://listman.redhat.com/archives/libvir-list/2021-June/msg00679.html
>>
>> diff to v4:
>> - Rebased onto current master
>> - Worked in David's suggestions, e.g. rename from <actual/> to
>>     <current/>, implemented offline memory update, implemented --node
>>     argument to virsh update-memory-device, prealloc is OFF and reserve is
>>     ON for virtio-mem
>>
>> Some suggestions are left as future work. For instance:
>> - Don't require memory slots because virtio-mem lives on PCI bus anyway
>> - Allow path backed backend for virtio-mem
> 
> Just a note that
> 
>     <memoryBacking>
>       <source type='file'/>
>       <access mode='shared'/>
>     </memoryBacking>
> 
> is doing what it's supposed to do. So only explicit file paths are not
> supported yet.
> 
>> - support .prealloc for virtio-mem object (not memory-backend-* !)
>>
>>
>> I keep occasionally rebased version on my gitlab:
>>
>> https://gitlab.com/MichalPrivoznik/libvirt/-/commits/virtio_mem_v5/
> 
> I just played with it and "virsh update-memory-device" is working like a
> charm now:
> 
> a) with "--node"
> b) with "--alias", including manually specified alias like "<alias
> name='ua-virtiomem1'/>"
> c) with --config, --live, --current
> 
> I see that "aliases" prefixed with "ua-" are an existing concept. Maybe
> we want to cross-reference that in the virtio-mem documentation?
> 
> Nothing unusual found during my testing. I did not play with huge pages,
> as it's initially not supported.

... and I just played with huge pages, and due to the added 
"reserve=off" it works just as expected, nice. (prealloc support to be 
added to make it actually safe to use)


-- 
Thanks,

David / dhildenb