On 10/05/18 11:01, Roger Pau Monné wrote: > On Thu, May 10, 2018 at 10:43:26AM +0100, George Dunlap wrote: >> On Wed, May 9, 2018 at 5:07 PM, Roger Pau Monne <[email protected]> wrote: >>> This prevents page-shattering, by being able to populate the RAM >>> regions below 4GB using 1GB pages, provided the guest memory size is >>> set to a multiple of a GB. >>> >>> Note that there are some special and ACPI pages in the MMIO hole that >>> will be populated using smaller order pages, but those shouldn't be >>> accessed as often as RAM regions. >> Is it possible to run PVH in pure 32-bit mode (as opposed to 32-bit >> PAE)? If so, such guests would be limited to 3GiB of total memory >> (instead of 4GiB). > Yes, that's correct. PVH guests are not limited to any mode, you could > even run them in protected or real mode. > >> But I suppose there's no particular reason to run PVH in pure 32-bit >> mode instead of 32-bit PAE. (I don't *think* TLB misses are slower on >> 3-level paging than 2-level paging, because the L3 entries are >> essentially loaded on CR3 switch.) >> >> So at the moment this seems OK to me. If someone decides they want to >> run PVH 2-level paging with more than 3GiB of RAM, we can easily add >> an option to turn it on. > That's my opinion. HVM guests already have a mmio_hole option, it > would be almost trivial to make that option also available to PVH if > there's a need for it.
Lets optimise for the common case. These days, this is 64bit OSes. The purpose of making the MMIO hole like this is to allow us to use 1G host superpages for all of guest RAM, and avoid all cases which would cause them to be shattered. Avoiding shattering is going to require some care, like not turning on legacy MTRRs, and ensuring that we provide some empty gfn space for the guest to make mappings into. There probably needs to be nGB + a little extra on small mappings to cover things like the ACPI tables, vram etc. ~Andrew _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
