| Message ID | 1462541784-22128-2-git-send-email-james.hogan@imgtec.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 06/05/2016 15:36, James Hogan wrote: > - It is actually redundant, since the host ASID will be restored > correctly by kvm_arch_vcpu_put(), which is called almost immediately > after kvm_arch_vcpu_ioctl_run() returns. What happens if the guest does a rogue access to the area where the host kernel resides? Would that cause a wrong entry in the TLB? Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, May 09, 2016 at 04:22:33PM +0200, Paolo Bonzini wrote: > On 06/05/2016 15:36, James Hogan wrote: > > - It is actually redundant, since the host ASID will be restored > > correctly by kvm_arch_vcpu_put(), which is called almost immediately > > after kvm_arch_vcpu_ioctl_run() returns. > > What happens if the guest does a rogue access to the area where the host > kernel resides? Would that cause a wrong entry in the TLB? The kernel and lowmem reside in KSEG0/XKPYS which are "unmapped segments". Unmapped means, the TLB isn't accessed at all nor does the ASID matter in the address translation process in one of these unmapped segments. Ralf -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, May 09, 2016 at 05:30:44PM +0200, Ralf Baechle wrote: > On Mon, May 09, 2016 at 04:22:33PM +0200, Paolo Bonzini wrote: > > > On 06/05/2016 15:36, James Hogan wrote: > > > - It is actually redundant, since the host ASID will be restored > > > correctly by kvm_arch_vcpu_put(), which is called almost immediately > > > after kvm_arch_vcpu_ioctl_run() returns. > > > > What happens if the guest does a rogue access to the area where the host > > kernel resides? Would that cause a wrong entry in the TLB? > > The kernel and lowmem reside in KSEG0/XKPYS which are "unmapped segments". > Unmapped means, the TLB isn't accessed at all nor does the ASID matter > in the address translation process in one of these unmapped segments. Yes, although kernel modules (KVM can be built as module) do run from tlb mapped memory, but trap & emulate KVM as found in mainline should work as accessing kernel segments from user mode (which is where guest runs) causes address error exception, triggering emulation of MMIO accesses rather than TLB fills. Hmm, perhaps locore.S should be restoring correct root ASID properly however before returning to the caller or calling the exit handler, either of which could be tlb mapped module code. Cheers James
diff --git a/arch/mips/kvm/locore.S b/arch/mips/kvm/locore.S index 81687ab1b523..c24facc85357 100644 --- a/arch/mips/kvm/locore.S +++ b/arch/mips/kvm/locore.S @@ -32,7 +32,6 @@ EXPORT(x); /* Overload, Danger Will Robinson!! */ -#define PT_HOST_ASID PT_BVADDR #define PT_HOST_USERLOCAL PT_EPC #define CP0_DDATA_LO $28,3 @@ -104,11 +103,6 @@ FEXPORT(__kvm_mips_vcpu_run) mfc0 v0, CP0_STATUS LONG_S v0, PT_STATUS(k1) - /* Save host ASID, shove it into the BVADDR location */ - mfc0 v1, CP0_ENTRYHI - andi v1, 0xff - LONG_S v1, PT_HOST_ASID(k1) - /* Save DDATA_LO, will be used to store pointer to vcpu */ mfc0 v1, CP0_DDATA_LO LONG_S v1, PT_HOST_USERLOCAL(k1) @@ -551,12 +545,6 @@ __kvm_mips_return_to_host: LONG_L k0, PT_HOST_USERLOCAL(k1) mtc0 k0, CP0_DDATA_LO - /* Restore host ASID */ - LONG_L k0, PT_HOST_ASID(sp) - andi k0, 0xff - mtc0 k0,CP0_ENTRYHI - ehb - /* Load context saved on the host stack */ LONG_L $0, PT_R0(k1) LONG_L $1, PT_R1(k1)
MIPS KVM uses different ASIDs for guest execution than for the host. The host ASID is saved on the stack when entering the guest with __kvm_mips_vcpu_run(), and restored again before returning back to the caller (exit to userland). - This does not take into account that pre-emption may have taken place during that time, which may have started a new ASID cycle and resulted in that process' ASID being invalidated and reused. - This does not take into account that the process may have migrated to a different CPU during that time, with a different ASID assignment since they are managed per-CPU. - It is actually redundant, since the host ASID will be restored correctly by kvm_arch_vcpu_put(), which is called almost immediately after kvm_arch_vcpu_ioctl_run() returns. Therefore drop this code from locore.S Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Kr?má? <rkrcmar@redhat.com> Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org --- arch/mips/kvm/locore.S | 12 ------------ 1 file changed, 12 deletions(-)