Bug 203979
Summary: | kvm_spurious_fault in L1 when running a nested kvm instance on AMD i686-pae | ||
---|---|---|---|
Product: | Virtualization | Reporter: | Jiri Palecek (jpalecek) |
Component: | kvm | Assignee: | virtualization_kvm |
Status: | RESOLVED CODE_FIX | ||
Severity: | normal | CC: | karahmed |
Priority: | P1 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 5.2-rc6 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Attachments: | Patch that allows me to run nested kvm instances again |
Description
Jiri Palecek
2019-06-24 19:09:44 UTC
So, I have bisected this and found the culprit to be: commit 8c5fbf1a723107814c20c3f4d6343ab9d694a705 (refs/bisect/bad) Author: KarimAllah Ahmed <karahmed@amazon.de> Date: Thu Jan 31 21:24:40 2019 +0100 KVM/nSVM: Use the new mapping API for mapping guest memory Use the new mapping API for mapping guest memory to avoid depending on "struct page". Signed-off-by: KarimAllah Ahmed <karahmed@amazon.de> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Created attachment 283501 [details]
Patch that allows me to run nested kvm instances again
After much looking on the offending commit, which doesn't seem to change any functionality, but just changes the API, I found out the gfns used inside __kvm_map_gfn were in fact far off. Further looking into it I found that these gfns were the result of gfn_to_gpa in some (but not all) places that used the new api. However, what was clearly meant was gpa_to_gfn. So I prepared this patch and tested that it allows to run nested linux instances in kvm successfully on my AMD system.
Already fixed by 8f38302c0be2d |