Re: [PATCH v2] arm64: kvm: fix IDMAP overlap with HYP VA

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Jan 19, 2020 at 05:43:27PM +0000, Marc Zyngier wrote:
> On Sat, 28 Dec 2019 11:57:14 +0000
> Russell King <rmk+kernel@xxxxxxxxxxxxxxx> wrote:
> 
> > Booting 5.4 on LX2160A reveals that KVM is non-functional:
> > 
> > kvm: Limiting the IPA size due to kernel Virtual Address limit
> > kvm [1]: IPA Size Limit: 43bits
> > kvm [1]: IDMAP intersecting with HYP VA, unable to continue
> > kvm [1]: error initializing Hyp mode: -22
> > 
> > Debugging shows:
> > 
> > kvm [1]: IDMAP page: 81a26000
> > kvm [1]: HYP VA range: 0:22ffffffff
> > 
> > as RAM is located at:
> > 
> > 80000000-fbdfffff : System RAM
> > 2080000000-237fffffff : System RAM
> > 
> > Comparing this with the same kernel on Armada 8040 shows:
> > 
> > kvm: Limiting the IPA size due to kernel Virtual Address limit
> > kvm [1]: IPA Size Limit: 43bits
> > kvm [1]: IDMAP page: 2a26000
> > kvm [1]: HYP VA range: 4800000000:493fffffff
> > ...
> > kvm [1]: Hyp mode initialized successfully
> > 
> > which indicates that hyp_va_msb is set, and is always set to the
> > opposite value of the idmap page to avoid the overlap. This does not
> > happen with the LX2160A.
> > 
> > Further debugging shows vabits_actual = 39, kva_msb = 38 on LX2160A and
> > kva_msb = 33 on Armada 8040. Looking at the bit layout of the HYP VA,
> > there is still one bit available for hyp_va_msb. Set this bit
> > appropriately. This allows kvm to be functional on the LX2160A, but
> > without any HYP VA randomisation:
> > 
> > kvm: Limiting the IPA size due to kernel Virtual Address limit
> > kvm [1]: IPA Size Limit: 43bits
> > kvm [1]: IDMAP page: 81a24000
> > kvm [1]: HYP VA range: 4000000000:62ffffffff
> > ...
> > kvm [1]: Hyp mode initialized successfully
> > 
> > Signed-off-by: Russell King <rmk+kernel@xxxxxxxxxxxxxxx>
> 
> I've applied this to kvmarm-next with a couple of cleanups, and
> preserving the fallback when the tag is zero (only the mask gets
> applied, without any ROR or ADD).

If only the mask is applied, then it will overlap with the IDMAP
region, and KVM will fail - so I think it would be a good idea in
that case to print something a little more useful, rather than
attributing the KVM failure to an overlap of IDMAP and the KVM
range.

The real problem is there aren't enough VA bits to allow the KVM
range to be adequately placed, rather than the overlap itself.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm



[Index of Archives]     [Linux KVM]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux