Marcelo Tosatti wrote:
> In preparation for multi-threaded guest pte walking, use cmpxchg()
> when updating guest pte's. This guarantees that the assignment of the
> dirty bit can't be lost if two CPU's are faulting the same address
> simultaneously.
>
> In case of pte update via write emulation, no synchronization is
> necessary since its the guest responsability.
>
> Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
>
>
> diff --git a/drivers/kvm/paging_tmpl.h b/drivers/kvm/paging_tmpl.h
> index b24bc7c..593073a 100644
> --- a/drivers/kvm/paging_tmpl.h
> +++ b/drivers/kvm/paging_tmpl.h
> @@ -78,6 +78,23 @@ static gfn_t gpte_to_gfn_pde(pt_element_t gpte)
> return (gpte & PT_DIR_BASE_ADDR_MASK) >> PAGE_SHIFT;
> }
>
> +static inline void FNAME(kvm_cmpxchg_guest_pte)(struct kvm *kvm,
> + gfn_t table_gfn, unsigned index, pt_element_t new_bits)
>
You can drop the kvm_ prefix since this is static.
> +{
> + pt_element_t pte;
> + pt_element_t *table;
> + struct page *page;
> +
> + page = gfn_to_page(kvm, table_gfn);
> + table = kmap_atomic(page, KM_USER0);
> +
> + do {
> + pte = table[index];
> + } while (cmpxchg(&table[index], pte, pte | new_bits) != pte);
> +
> + kunmap_atomic(page, KM_USER0);
> +}
>
I don't think cmpxchg() handles 64-bits on i386; you need cmpxchg64().
What happens if the guest changed the pte under our feet (say, one vcpu
accesses the page, the other vcpu swaps it out, setting the pte to
zero)? We end up modifying the new pte. So we need to compare against
the original pte, and abort the walk if we fail to set the bit.
> diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c
> index c70ac33..edba8ce 100644
> --- a/drivers/kvm/x86.c
> +++ b/drivers/kvm/x86.c
> @@ -1510,6 +1510,9 @@ static int emulator_write_phys(struct kvm_vcpu *vcpu,
> gpa_t gpa,
> {
> int ret;
>
> + /* No need for kvm_cmpxchg_guest_pte here, its the guest
> + * responsability to synchronize pte updates and page faults.
> + */
> ret = kvm_write_guest(vcpu->kvm, gpa, val, bytes);
> if (ret < 0)
> return 0;
Hmm. What if an i386 pae guest carefully uses cmpxchg8b to atomically
set a pte? kvm_write_guest() doesn't guarantee atomicity, so an
intended atomic write can be seen splitted by the guest walker doing a
concurrent walk.
--
error compiling committee.c: too many arguments to function
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
