Page MenuHomeFreeBSD

xen: introduce xen_support_evtchn_bind()
ClosedPublic

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

Details

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

I would name this xen_percpu_evtchn{_enabled} or some such. Given the current usage I think xen_support_evtchn_rebind is confusing, as it's not about rebinding an event channel, but being able to assign event channels to vCPUs.

It is about whether the event channel can be rebound to a different vCPU. I would tend towards xen_has_percpu_evtchn(). This strikes me as fix on commit though. (my main branch on GitLab now has it as xen_has_percpu_evtchn())

This revision was automatically updated to reflect the committed changes.