xen: bump used interface version

[royger]

Summary

This is required for a further change that will make use of a field
that was added in version 0x00040d00.

No functional change expected.

Sponsored by: Citrix Systems R&D

[ehem_freebsd_m5p.com]

Updating to newer variation of Xen's interface here. I'd noticed NR_EVENT_CHANNELS and EVTCHN_2L_NR_CHANNELS before, but hadn't known which one was the more recent/proper one.

There is substantial overlap with D30743. Notably D30743 adds a bunch of uses due to _Static_assert()s with the constant. Looking at the number of uses, I would suggest xen_intr.c should use a #define NR_EVENT_CHANNELS, which then moves to sys/dev/xen/bus/intr-internal.h with D30648. The reason being there are so many uses, both the architecture and independent portions would need simultaneous update if there was a move to the more recent types of event channel.

sys/dev/xen/grant_table/grant_table.c

42

Presently there are only 2 uses of grant_entry_t in grant_table.c. Unless you're planning to add more uses of grant_entry_t, I would be inclined to simply replace the 2 uses.

sys/x86/xen/xen_intr.c

313

Overlap with D30743 here. Easily resolved, but notable D30743 looks worthy of MFC and this doesn't seem likely for MFC.

1287

This gets taken out by one portion of D30743.

[ehem_freebsd_m5p.com]

Should also state, with tiny adjustment this built fine for ARM64. I doubt there will be issues.

[royger]

In D37682#857040, @ehem_freebsd_m5p.com wrote:

Updating to newer variation of Xen's interface here. I'd noticed NR_EVENT_CHANNELS and EVTCHN_2L_NR_CHANNELS before, but hadn't known which one was the more recent/proper one.

There is substantial overlap with D30743. Notably D30743 adds a bunch of uses due to _Static_assert()s with the constant. Looking at the number of uses, I would suggest xen_intr.c should use a #define NR_EVENT_CHANNELS, which then moves to sys/dev/xen/bus/intr-internal.h with D30648. The reason being there are so many uses, both the architecture and independent portions would need simultaneous update if there was a move to the more recent types of event channel.

My reasoning for using EVTCHN_2L_NR_CHANNELS was that the code in xen_intr.c is the implementation for 2L event channels, so it seemed better to make that explicit by using the proper define. FIFO event channels require a completely different implementation, and that should be placed in a different translation unit.

Anyway, I'm fine with adding a define to xen_intr.c, we can always switch to using EVTCHN_2L_NR_CHANNELS at a later point.

Thanks for the review.

[ehem_freebsd_m5p.com]

At this point under "Add Action..." choose "Close Revision" to indicate it was accomplished.