[RFC PATCH 2/2] qemu: Add support for max physical address size

[Dario Faggioli]

On Wed, 2020-11-04 at 18:04 +0000, Daniel P. Berrangé wrote:
> On Wed, Nov 04, 2020 at 07:00:16PM +0100, Dario Faggioli wrote:
> > > 
> > Right. So, host-phys-bits-limit seems to exist because:
> > "Some downstream distributions of QEMU set host-phys-bits=on by
> > default. [...] Now choosing a large phys-bits value for a VM has
> > bigger
> > impact: it will make KVM use 5-level EPT even when it's not really
> > necessary."
> > 
> > And we want to be able to, from QEMU: "keep using the host phys-
> > bits
> > value, but only if it's smaller than 48."
> 
> Right so it is basically a hack to workaround problem with historical
> defaults in QEMU. In the libvirt case we're not dealing with
> defaults,
> we have explicit XML element to express what we want. So we can
> express
> it straight away and not need this hack.
> 
Ok.
> 

> > In my head (and drafts), that would happen with:
> > 
> > <maxphysaddr mode="passthrough" limit="NN"/>   (1)
> > 
> > Which is very similar and may be identical to:
> > 
> > <maxphysaddr mode="emulate" bits="NN"/>        (2)
> > 
> > [...]
> >
> > So, maybe having (1) may be the only way of making sure that I get
> > min(NN,MM), irrespective of QEMU version/behavior. Or am I missing
> > something?
> 
> I don't see any functional difference between 1 & 2 from libvirt's
> side. In fact (2) is probably better because it can work on any
> version
> of QEMU, even before host-phys-bits-limit was introduced.
> 
That is indeed true.

> The "downside" is that an app has to read the capabilities to see the
> current host limit and choose the "NN" value.
> 
> > That's why I happen to think there could be value in having
> > limit... Or
> > does this all just not make sense? :-)
> 
> I think we can ignore  host-phys-bits-limit. If it later turns out we
> really do need it, we can add it to libvirt, but until then pretend
> it doesn't exist.
> 
Right. I think I've understood your line of reasoning and I agree.
Especially on the fact that we can ignore it for now, and always add it
later, if we see the need for it.

And I certainly can look into adding the phys bits to the host
capabilities.

Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20201105/0b0e0d5a/attachment-0001.sig>