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
