On Thu, Oct 07, 2010 at 02:42:06PM +0200, Avi Kivity wrote:
> On 10/04/2010 05:56 PM, Gleb Natapov wrote:
> >Guest enables async PF vcpu functionality using this MSR.
> >
> > return NON_PRESENT;
> >+
> >+MSR_KVM_ASYNC_PF_EN: 0x4b564d02
> >+ data: Bits 63-6 hold 64-byte aligned physical address of a 32bit memory
>
> Given that it must be aligned anyway, we can require it to be a
> 64-byte region and also require that the guest zero it before
> writing the MSR. That will give us a little more flexibility in the
> future.
>
No code change needed, so OK.
>
> >+ return 0;
> >+ }
> >+
> >+ if (kvm_gfn_to_hva_cache_init(vcpu->kvm,&vcpu->arch.apf.data, gpa))
> >+ return 1;
>
> Note: we need to handle the memory being removed from underneath
> kvm_gfn_to_hve_cache(). Given that, we can just make
> kvm_gfn_to_hva_cache_init() return void. "success" means nothing
> when future changes can invalidate it.
>
I want to catch guest doing stupid things. If guest give us non-existent
address I want wrmsr to #GP.
> >+
> >+ kvm_async_pf_wakeup_all(vcpu);
>
> Why is this needed? If all apfs are flushed at disable time, what
> do we need to wake up?
For migration. Destination will rewrite msr and all processes will be
waked up.
>
> Need to list the MSR for save/restore/reset.
>
>
This patch adds it to msrs_to_save, no?