>>> On 20.09.17 at 14:58, <jgr...@suse.com> wrote: > On 20/09/17 14:18, Jan Beulich wrote: >>>>> On 20.09.17 at 08:34, <jgr...@suse.com> wrote: >>> On very large hosts a guest needs to know whether it will have to >> >> ... a PV guest ... > > What about a HVM guest with (potentially) more than 16TB?
Such a guest knows how much memory it has without querying Xen. >>> handle frame numbers larger than 32 bits in order to select the >>> appropriate grant interface version. >>> >>> Add a new Xen specific CPUID node to contain the maximum guest address >>> width >> >> "guest address width" is ambiguous here, the more when looking at >> what you actually return. We should no longer allow ourselves to >> mix up the different address spaces. > > I've chosen "guest address width" similar to the "guest frame number" > we already have: it is MFN based for PV and PFN based for HVM (and ARM). > I'm open for a better name. If the interface is needed for other than PV, then the term likely is fine. But for a PV only interface I'd prefer it to be "machine address". >> The limit you want to report >> here is that in MFN space, which ought to be of no relevance to >> HVM guests. Therefore I'm against uniformly exposing this (as much >> as almost no other host property should have any relevance for >> HVM guests), and would instead like to see a PV-only leaf just like >> we already have a HVM only one. > > As said above: a HVM guest needs to know whether it will have to deal > with frame numbers >32 bits, too. > > For HVM guests this would just be a hint that the host might be large > enough for this to happen, as even today a HVM guest could in theory > reorganize its memory map to have parts of the memory above the 16TB > border even with only rather small amounts of memory. But this would > be the problem of the guest then. A HVM guest booted with less than 16Tb and then being pushed up beyond that boundary would still know in advance that this could happen - the SRAT table would tell it what hotplug regions there are. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel