Re: [PATCH v5 05/16] qemu: Build command line for virtio-mem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 9/14/21 3:05 PM, David Hildenbrand wrote:
> On 13.09.21 16:52, Michal Privoznik wrote:
>> Nothing special is happening here. All important changes were
>> done when for 'virtio-pmem' (adjusting the code to put virtio
>> memory on PCI bus, generating alias using
>> qemuDomainDeviceAliasIndex(). The only bit that might look
>> suspicious is no prealloc for virtio-mem. But if you think about
>> it, the whole purpose of this device is to change amount of
>> memory exposed to guest on the fly. There is no point in locking
>> the whole backend in memory.
> 
> Do I understand correctly that we'll always try setting "reserve=off",
> and "prealloc=off"? That would be awesome :)

prealloc=off would be set (almost) unconditionally for all
memory-backend-* objects that are associated with virtio-mem device. And
if QEMU is new enough to have .reserve attribute then reserve=off is set
too.

> 
> I do wonder if we want to warn or bail out if "priv->memPrealloc" is set
> but we are temporarily not able to support it -- as discussed, because
> virtio-mem in QEMU yet has to be taught about it.

priv->memPrealloc might not be what you think it is. The fact whether
immediate allocation was requested is stored in def->mem.allocation; and
priv->memPrealloc is just there to track whether -mem-prealloc what
already put onto (paritally) generated cmd line and thus the rest of
generators must refrain from setting prealloc=on.

Codewise speaking, if you'd look at qemuBuildCommandLine() (this is
where cmd line generation happens) then you'd see
qemuBuildMemCommandLine() being called first and only after that
qemuBuildMemoryDeviceCommandLine() being called second.

The former is responsible for generating generic memory for guest (e.g.
-m XX -mem-prealloc -mem-path ...  which is the old style, nowadays a
combination of -machine memory-backend= + -object memory-backend-*  is
generated).

Long story short, if priv->memPrealloc isn't true at this point, then
libvirt doesn't have to set prealloc=off explicitly, because off is the
default.


> 
> FYI: QEMU will bail out if "reserve=off,prealloc=on" is set in combination.

Yeah, this combination should never happen.

Michal




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux