Re: [PATCH RFC 10/39] KVM: x86/xen: support upcall vector

[David Woodhouse]

On Wed, 2020-12-02 at 20:12 +0000, Joao Martins wrote:
> > I'll do some more experiments and
> > see what I can get working, and what it looks like.
> > 
> > I'm focusing on making the shinfo stuff all use kvm_map_gfn() first.
> > 
> 
> I was chatting with Ankur, and we can't fully 100% remember why we dropped using
> kvm_vcpu_map/kvm_map_gfn. We were using kvm_vcpu_map() but at the time the new guest
> mapping series was in discussion, so we dropped those until it settled in.
> 
> One "side effect" on mapping shared_info with kvm_vcpu_map, is that we have to loop all
> vcpus unless we move shared_info elsewhere IIRC. But switching vcpu_info, vcpu_time_info
> (and steal clock) to kvm_vcpu_map is trivial.. at least based on our old wip branches here.

I'm not mapping/unmapping every time. I've just changed the
page_to_virt() bit to use kvm_map_gfn() as a one-time setup for now,
because I need it to work for GFNs without a backing page.

I have that working for the shinfo in my tree so far; will do the other
pages next.

In the fullness of time I'd like to eliminate the duplication between
kvm_setup_pvclock_page() and kvm_xen_update_vcpu_time(), which are
doing precisely the same thing. I think that can wait until we fix up
the MMU notifier thing as discussed though, so they can all just do
direct dereferencing.

But I'm inclined not to get hung up on that for now. There are much
more fun things to be playing with.

Attachment: smime.p7s
Description: S/MIME cryptographic signature