[PATCH 2/2] qemu: Do not Use canonical path for system memory

[Jiri Denemark]

On Wed, Jan 13, 2021 at 08:06:30 +0100, Peter Krempa wrote:
> On Tue, Jan 12, 2021 at 21:13:54 +0100, Jiri Denemark wrote:
> > On Tue, Jan 12, 2021 at 20:21:19 +0100, Igor Mammedov wrote:
> > > On Tue, 12 Jan 2021 09:29:50 +0100
> > > Michal Privoznik <mprivozn at redhat.com> wrote:
> 
> [...]
> 
> > 
> > We consume machine types as opaque strings, we don't parse them and thus
> > we don't have any ordering on them. Without this telling what <= 4.0
> > means is impossible. And I don't think we should start doing it, and
> > especially not for limiting this hack as it would be limiting a hack
> > with another one.
> > 
> > A reasonable solution would be if we could tell which machine types need
> > (or perhaps don't need) such treatment by probing QEMU for available
> > machine types.
> 
> Well this has two implications:
> 1) qemu telling us would be detectable, thus no need to check for x-something
> 2) if qemu can tell us when to use it, it's very probable that at that
>    point it can do the correct thing itself, not requiring anything from
>    us

I didn't really study the details, but I guess QEMU cannot do the right
thing for old machine types because of backward compatibility. While for
new machine types (>4.0) QEMU is automatically doing it right. With this
assumption, new QEMU could report some machine types are OK and thus we
could skip applying the hack for them. But we would still need it
(including the x-... detection) for old machine type and older QEMU
releases which didn't mark any machine type as OK.

Thus we would not get rid of the x-... hack, but we could properly limit
it for old QEMU and old machine types. That is, the additional probing
would be an optimization of the hack which we need anyway I'm afraid.

You can of course ignore all I said if my assumption is wrong :-)

Jirka