On Mon, 2021-11-01 at 19:03 +0000, David Woodhouse wrote:
> +int kvm_xen_set_evtchn_fast(struct kvm_kernel_irq_routing_entry *e,
> + struct kvm *kvm)
> +{
> + struct gfn_to_pfn_cache *gpc = &kvm->arch.xen.shinfo_cache;
> + struct kvm_memslots *slots;
> + struct kvm_vcpu *vcpu;
> + unsigned long *pending_bits, *mask_bits;
> + int port_word_bit;
> + bool kick_vcpu = false;
> + int idx;
> + int rc;
> +
> + vcpu = kvm_get_vcpu_by_id(kvm, e->xen_evtchn.vcpu);
> + if (!vcpu)
> + return -EINVAL;
Hm... am I allowed to do that kvm_get_vcpu_by_id() just once in
kvm_xen_setup_evtchn() and store the resulting vcpu pointer in
e->xen_evtchn.vcpu instead of its APIC ID? vCPUs can't go away until
the whole kvm is destroyed, can they?
> + if (!vcpu->arch.xen.vcpu_info_set)
> + return -EINVAL;
> +
> + if (e->xen_evtchn.port >= max_evtchn_port(kvm))
> + return -EINVAL;
> +
> + rc = -EWOULDBLOCK;
> + read_lock(&kvm->arch.xen.shinfo_lock);
Once I hooked that up to an actual VMM instead of just the self tests,
and this is being called from an actual IRQ handler (via
vfio_msihandler and eventfd_signal), lockdep reminded me that it needed
to be read_lock_irqsave() there, with similar changes in the previous
patch. Fixed in my tree and will be included in the next revision.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
