On Sun, Aug 10, 2014 at 06:18:16PM +0100, Richard W.M. Jones wrote: > On Sun, Aug 10, 2014 at 11:25:29PM +0900, Jungseok Lee wrote: > > On Aug 10, 2014, at 10:24 PM, Richard W.M. Jones wrote: > > > kvm_alloc_stage2_pgd has to do an order 9 allocation, ie. 512 > > > contiguous pages I think. > > > > > > This often leads to problems running qemu when memory is relatively > > > low -- eg. if you have one VM running, a healthy number of host > > > applications, and perhaps "just" 4GB free; then you decide to run the > > > libguestfs test suite. > > > > > > Any suggestions how to deal with this? > > Actually I realized shortly after posting that I'm still using 4K > pages in my kernel. With 64K pages it would only be an order 5 allocation. > > > As you know, 512 contiguous page allocation comes from KVM_PHYS_SHIFT, > > which is always 48 regardless of hardware capability. > > > > Currently, Cortex-A53 and Cortex-A57 supports up to 40-bit and 44-bit > > address space, respectively. If KVM_PHYS_SHIFT is bound to hardware, > > not theoretical number, 48, it is possible to allocate much less contiguous > > pages. However, if a new Cortex-A, which support 48-bit address space, comes > > up, the same problem would happen. > > I see that it's 40 on 32 bit ARM, and as you say 48 on 64 bit ARM. > > Doesn't this only affect the amount of memory that the guest can use? > ie. Is it unrelated to the host memory or host processor? For any > guest I'm likely to run on this machine I'd be happy with max RAM of 4GB. > It limits the physical address space the VM can address, not the actual amount of memory consumed. And without trapping all ID registers, the guest can see the ID_AA64MMFR0_EL1.PARange and be able to physically address the range specified by that field. You could place all resources within a lower bound and have a way for user space to specify what the maximum addressable physical address size for the guest should be, and handle translation faults that fall outside this range properly, but that's all part of the consideration of handling the various memory sizes properly. Additionally, we could play tricks with the SL0 bit to reduce the contiguous page count requirement at the cost of a slower Stage-2 translation process, but I doubt if anyone has a clue in real world numbers what the performance effect would be. -Christoffer _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
