On Mon, 2021-11-01 at 19:03 +0000, David Woodhouse wrote:
> @@ -1588,6 +1589,28 @@ bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range)
> {
> bool flush = false;
>
> + if (static_branch_unlikely(&kvm_xen_enabled.key)) {
> + write_lock(&kvm->arch.xen.shinfo_lock);
> +
> + if (kvm->arch.xen.shared_info &&
> + kvm->arch.xen.shinfo_gfn >= range->start &&
> + kvm->arch.xen.shinfo_cache.gfn < range->end) {
> + /*
> + * If kvm_xen_shared_info_init() had *finished* mapping the
> + * page and assigned the pointer for real, then mark the page
> + * dirty now instead of via the eventual cache teardown.
> + */
> + if (kvm->arch.xen.shared_info != KVM_UNMAPPED_PAGE) {
> + kvm_set_pfn_dirty(kvm->arch.xen.shinfo_cache.pfn);
> + kvm->arch.xen.shinfo_cache.dirty = false;
> + }
> +
> + kvm->arch.xen.shared_info = NULL;
> + }
> +
> + write_unlock(&kvm->arch.xen.shinfo_lock);
> + }
> +
> if (kvm_memslots_have_rmaps(kvm))
> flush = kvm_handle_gfn_range(kvm, range, kvm_unmap_rmapp);
If I could find a way to ditch that rwlock and use RCU for this, then
I'd be fairly much OK with making it a generic facility and using it
for other things like nesting and maybe even the steal time.
But I don't think we *can* always sleep in the MMU notifier, so we
can't call synchronize_srcu(), and I can't see how to ditch that
rwlock.
Which means I'm slightly less happy about offering it as a generic
facility, and I think it needs to be a special case for Xen which
really *does* need to deliver interrupts to the guest shinfo page from
IRQ context without current->mm == kvm->mm.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
