Page MenuHomeFreeBSD

xen: introduce xen_support_evtchn_bind()
AcceptedPublic

Authored by ehem_freebsd_m5p.com on Mar 23 2021, 10:01 PM.

Details

Reviewers
royger
mhorne
Summary

xen_vector_callback_enabled is x86 specific and supporting evtchn rebind
on others architectures may be different.

Introduce a new helper to check if we can rebind the event channel.

Note that xen_intr_assign_cpu was only checking if
xen_vector_callback_enabled. Although it looks like to me that rebind
should be supported for PVH.

Submitted by: Elliott Mitchell <ehem+freebsd@m5p.com>
Original implementation: Julien Grall <julien@xen.org>, 2015-10-10 12:40:06

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 38031
Build 34920: arc lint + arc unit

Event Timeline

I think the commit message needs some kind of adjustments, as it seems to mix event channel rebind with having setup a vector callback for event channel notification delivery?

On x86 you can have a 'global' event channel notification delivery through an IO-APIC pin, which is not per-vcpu. This used to be the old way of signaling event channels to HVM guests until a per-vcpu specific method was introduced using an IDT vector. When using a global IRQ there are event channel operations that make no sense, like binding event channels to specific vCPUs (ie: xen_intr_assign_cpu).

Also you seem to have missed an instance of xen_vector_callback_enabled used in dev/xen/timer/timer.c?

Yeah looks like that commit message became garbled. The last paragraph looks like it was a note to self due to being concerned about the conditional in xen_intr_assign_cpu() being distinct from the other spots where xen_support_evtchn_rebind() was used.

For the purpose of this commit, the use of xen_vector_callback_enabled in dev/xen/timer/timer.c is irrelevant as the target (Xen/aarch64) doesn't support the timer device anyway.

This revision is now accepted and ready to land.May 14 2021, 1:32 PM