On Mon, Aug 23, 2010 at 06:22:02PM +0300, Avi Kivity wrote:
> On 07/19/2010 06:30 PM, Gleb Natapov wrote:
> >Guess enables async PF vcpu functionality using this MSR.
> >
> >
> >
> >+static int kvm_pv_enable_async_pf(struct kvm_vcpu *vcpu, u64 data)
> >+{
> >+ u64 gpa = data& ~0x3f;
> >+ int offset = offset_in_page(gpa);
> >+ unsigned long addr;
> >+
> >+ /* Bits 1:5 are resrved, Should be zero */
> >+ if (data& 0x3e)
> >+ return 1;
> >+
> >+ vcpu->arch.apf_msr_val = data;
> >+
> >+ if (!(data& KVM_ASYNC_PF_ENABLED)) {
> >+ vcpu->arch.apf_data = NULL;
> >+ return 0;
> >+ }
> >+
> >+ addr = gfn_to_hva(vcpu->kvm, gpa>> PAGE_SHIFT);
> >+ if (kvm_is_error_hva(addr))
> >+ return 1;
> >+
> >+ vcpu->arch.apf_data = (u32 __user*)(addr + offset);
>
> This can be invalidated by host userspace playing with memory
> regions. It needs to be recalculated on memory map changes, and it
> may disappear from under the guest's feet (in which case we're
> allowed to KVM_REQ_TRIPLE_FAULT it).
>
> (note: this is a much better approach than kvmclock's and vapic's,
> we should copy it there)
>
apf_put_user() tracks memory slot changes and revalidate the address if
needed.
> >+
> >+ /* check if address is mapped */
> >+ if (get_user(offset, vcpu->arch.apf_data)) {
> >+ vcpu->arch.apf_data = NULL;
> >+ return 1;
> >+ }
>
> So, this check can succeed today but fail tomorrow.
>
> >+ return 0;
> >+}
> >+
>
> --
> error compiling committee.c: too many arguments to function
--
Gleb.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>