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

On Wed, 2020-11-04 at 18:04 +0000, Daniel P. Berrangé wrote: 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)