Eventtimer for Hyper-V

[decui_microsoft.com]

Bascially the patch seems good to me.

Here are some small suggestions:

1. In hv_et_intr(), we can easily avoid the rdmsr() by just doing a "full" init of 'timer_cfg' as we do in hv_et_start().

rdmsr() here is trapped into the hypervisor and at least several hundred or even thousand cycles are needed.

2. we'd better replace "(1LL << 32)" with SBT_1S (I personally think this is more readable):

+ et.et_min_period = (1LL << 32) / HV_TIMER_FREQUENCY;
+ et.et_max_period = HV_MAX_DELTA_TICKS * ((1LL << 32) / HV_TIMER_FREQUENCY);

e.g., for min_period, we'd better use
et.et_min_period = HV_MIN_DELTA_TICKS * (SBT_1S / HV_TIMER_FREQUENCY);

3. In hv_vmbus_isr(), we'd better invoke hv_et_intr() before msg->header.message_type = HV_MESSAGE_TYPE_NON.

Because it seems usually the users of event timer driver use one-shot mode rather than periodic mode, so we want the callback to be run ASAP.

4. In hv_et_intr(), in the case "periodticks[curcpu] != 0" and "et.et_active) is false", it looks we needn't to do the wrmsr, so it may be a good idea to add a "if (!et.et_active) return;" at the beginning of the function.

[decui_microsoft.com]

And we need use something like EARLY_DRIVER_MODULE to make sure hyper-v timer is used as the default event timer, when the VM is running on Hyper-V.

[delphij]

Looks good to me.

[royger]

LGTM. FWIW, I'm not sure there's much value in implementing both the one-shot and the periodic mode, one-shot is the preferred one AFAIK.

sys/dev/hyperv/vmbus/hv_hv.c

253 ↗

(On Diff #11570)

IMHO, and that's more a suggestion: I would recommend making the event timer a device itself, that attaches to the vmbus. This will allow for more flexibility going forward, and you take advantage of newbus.