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

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

 



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)

Attachment: signature.asc
Description: This is a digitally signed message part


[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