On 04/30/2011 05:50 PM, Takuya Yoshikawa wrote:
From: Takuya Yoshikawa<[email protected]>
The address of the gpte was already calculated and stored in ptep_user
before entering cmpxchg_gpte().
This patch makes cmpxchg_gpte() to use that to make it clear that we
are using the same address during walk_addr_generic().
Signed-off-by: Takuya Yoshikawa<[email protected]>
---
Note: I tested this but could not see cmpxchg_gpte() being called.
Is there any good test case?
Run with npt or ept disabled. With a normal OS you'll see A and D bits
being set when the guest is under memory pressure, or when the guest
uses a shared writeable mapping. You can also try kvm-unit-tests.git's
x86/access.flat test (also with npt/ept disabled).
static int FNAME(cmpxchg_gpte)(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu,
- gfn_t table_gfn, unsigned index,
- pt_element_t orig_pte, pt_element_t new_pte)
+ pt_element_t __user *ptep_user, unsigned index,
+ pt_element_t orig_pte, pt_element_t new_pte)
{
+ int npages;
pt_element_t ret;
pt_element_t *table;
struct page *page;
- gpa_t gpa;
- gpa = mmu->translate_gpa(vcpu, table_gfn<< PAGE_SHIFT,
- PFERR_USER_MASK|PFERR_WRITE_MASK);
- if (gpa == UNMAPPED_GVA)
- return -EFAULT;
-
- page = gfn_to_page(vcpu->kvm, gpa_to_gfn(gpa));
+ npages = get_user_pages_fast((unsigned long)ptep_user, 1, 1,&page);
+ BUG_ON(npages != 1);
This BUG_ON() is user triggerable - have one thread munmap() guest
memory while another thread runs guest code which triggers this path.
You need to return an error here. Or maybe you can just return - the
user is doing something meaningless and there's no correct action here.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
