|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4] x86/hvm: Add per-vcpu evtchn upcalls
>>> On 07.01.15 at 19:06, <paul.durrant@xxxxxxxxxx> wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -5462,6 +5462,40 @@ static int hvmop_destroy_ioreq_server(
> return rc;
> }
>
> +static int hvmop_set_evtchn_upcall_vector(
> + XEN_GUEST_HANDLE_PARAM(xen_hvm_set_evtchn_upcall_vector_t) uop)
> +{
> + xen_hvm_set_evtchn_upcall_vector_t op;
> + struct domain *d;
> + struct vcpu *v;
> + int rc;
> +
> + if ( copy_from_guest(&op, uop, 1) )
> + return -EFAULT;
> +
> + d = rcu_lock_current_domain();
I don't think you need this, current->domain should be just fine here.
> +
> + rc = -EINVAL;
> + if ( !is_hvm_domain(d) )
> + goto out;
> +
> + if ( op.vector < 0x10 )
> + goto out;
> +
> + rc = -ENOENT;
> + if ( op.vcpu >= d->max_vcpus || (v = d->vcpu[op.vcpu]) == NULL )
> + goto out;
> +
> + printk(XENLOG_G_INFO "%pv: %s %u\n", v, __func__, op.vector);
Rather than printing the function name here, can't you make the
message text more meaningful? Or otherwise this ought to be a
gdprintk().
> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -152,6 +152,13 @@ void hvm_isa_irq_deassert(
> spin_unlock(&d->arch.hvm_domain.irq_lock);
> }
>
> +static void hvm_set_upcall_irq(struct vcpu *v)
> +{
> + uint8_t vector = v->arch.hvm_vcpu.evtchn_upcall_vector;
> +
> + vlapic_set_irq(vcpu_vlapic(v), vector, 0);
> +}
Is this small a single-use helper function really warranted?
> @@ -220,6 +227,8 @@ void hvm_assert_evtchn_irq(struct vcpu *v)
>
> if ( is_hvm_pv_evtchn_vcpu(v) )
> vcpu_kick(v);
> + else if ( v->arch.hvm_vcpu.evtchn_upcall_vector != 0 )
> + hvm_set_upcall_irq(v);
In the public header comment you say that this new mechanism takes
precedence over callback-via, yet here you place it in an "else" to the
is_hvm_pv_evtchn_vcpu() check. Which one is correct/intended?
> --- a/xen/include/public/hvm/hvm_op.h
> +++ b/xen/include/public/hvm/hvm_op.h
> @@ -369,6 +369,26 @@
> DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_ioreq_server_state_t);
>
> #endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
>
> +#if defined(__i386__) || defined(__x86_64__)
> +
> +/*
> + * HVMOP_set_evtchn_upcall_vector: Set a <vector> that should be used for
> event
> + * channel upcalls on the specified <vcpu>.
> If set,
> + * this vector will be used in preference to
> the
> + * domain callback via (see
> HVM_PARAM_CALLBACK_IRQ)
> + * and hence allows HVM guests to bind event
> + * event channels to a vcpu other than 0.
> + */
The wording suggests that the callback-via mechanism is tied to vCPU0,
which iiuc it isn't (and I think I said so in response to an earlier version).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |