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

On Wed, 2020-11-04 at 13:11 +0000, Daniel P. Berrangé 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." 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? That's why I happen to think there could be value in having limit... Or does this all just not make sense? :-) 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)