[Top][All Lists]

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

Re: [PATCH v3] machine: add missing doc for memory-backend option

From: Michal Privoznik
Subject: Re: [PATCH v3] machine: add missing doc for memory-backend option
Date: Wed, 27 Jan 2021 15:24:26 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1

On 1/27/21 11:54 AM, Daniel P. Berrangé wrote:
On Wed, Jan 27, 2021 at 10:45:11AM +0000, Daniel P. Berrangé wrote:
On Thu, Jan 21, 2021 at 11:15:04AM -0500, Igor Mammedov wrote:

How does a mgmt app know which machine types need to use this
option ? The machine type names are opaque strings, and apps
must not attempt to parse or interpret the version number
inside the machine type name, as they can be changed by
distros.  IOW, saying to use it for machine types 4.0 and
older isn't a valid usage strategy IMHO.

Looking at the libvirt patch, we do indeed use his property
unconditionally for all machine types, precisely because parsing
version numbers from the machine type is not allowed.


So this doc is telling apps to do something that isn't viable

The other approach that I was suggesting was, that QEMU stops reporting 'default-ram-id' for affected machine types. The way the switch from '-m XMB' to memory-backend-* was implemented in libvirt is that if libvirt sees 'default-ram-id' attribute for given machine type it uses memory-backend-* otherwise it falls back to -m.

Since we know which machine types are "broken", we can stop reporting the attribute and thus stop tickling this bug. I agree that it puts more burden on distro maintainers to backport the change, but I think it's acceptable risk.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]