On Wed, Nov 04, 2020 at 07:00:16PM +0100, Dario Faggioli wrote:
On Wed, 2020-11-04 at 13:11 +0000, Daniel P. Berrangé wrote:
> On Mon, Nov 02, 2020 at 09:14:22AM +0100, Christian Ehrhardt wrote:
> >
> > Looking at my todo notes I wondered if while touching it we should
> > right
> > away also
> > add host-phys-bits-limit in the same spot?
> > See
https://git.qemu.org/?p=qemu.git;a=commit;h=258fe08bd341d
>
> I'm not convinced we actally need it in libvirt. Assuming we report
> the
> host phys bits in the capabilities XML, apps can already achieve this
> functionality with the mode=emulate bits=NN settings by populating
> NN
> based on the capabilities XML.
>
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.
So, I was thinking that, in a world where QEMU will
have host-phys-bits=on by default, if using `-cpu host` you may want to
be able to do the same from libvirt, i.e., "same as host, but not more
than NN".
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)
Whether or not they're actually identical, e.g., if NN > MM, depends on
what QEMU does. In that case, with (1) we set MM. With (2), if QEMU
let us do that, we set NN. (And when I say what QEMU does, I don't
mean, right know, I mean in the particular version in use, assuming
that at least in theory it can change between different versions).
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.
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.
Thanks and 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)
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|