On Tue, 07 Sep 2021 19:25:23 +0100, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: > > On Tue, 7 Sept 2021 at 18:10, Marc Zyngier <maz@xxxxxxxxxx> wrote: > > > > Hi Peter, > > > > On Tue, 07 Sep 2021 13:51:13 +0100, > > Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: > > > > > > On Sun, 22 Aug 2021 at 15:45, Marc Zyngier <maz@xxxxxxxxxx> wrote: > > > > > > > > The documentation for the 'highmem' option indicates that it controls > > > > the placement of both devices and RAM. The actual behaviour of QEMU > > > > seems to be that RAM is allowed to go beyond the 4GiB limit, and > > > > that only devices are constraint by this option. > > > > > > > > Align the documentation with the actual behaviour. > > > > > > I think it would be better to align the behaviour with the documentation. > > > > > > The intent of 'highmem' is to allow a configuration for use with guests > > > that can't address more than 32 bits (originally, 32-bit guests without > > > LPAE support compiled in). It seems like a bug that we allow the user > > > to specify more RAM than will fit into that 32-bit range. We should > > > instead make QEMU exit with an error if the user tries to specify > > > both highmem=off and a memory size that's too big to fit. > > > > I'm happy to address this if you are OK with the change in user > > visible behaviour. > > > > However, I am still struggling with my original goal, which is to > > allow QEMU to create a usable KVM_based VM on systems with a small IPA > > space (36 bits on the system I have). What would an acceptable way to > > convey this to the code that deals with the virt memory map so that it > > falls back to something that actually works? > > Hmm, so at the moment we can either do "fits in 32 bits" or > "assumes at least 40 bits" but not 36 ? Exactly. I have the gut feeling that we need a 'gpa_bits' option that would limit the guest physical range and generalise highmem. High IO ranges would simply not be available if the GPA range isn't big enough. M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
