diff options
author | Vitaly Kuznetsov <vkuznets@redhat.com> | 2018-11-26 16:47:31 +0100 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2018-12-14 17:59:57 +0100 |
commit | 8644f771e07c52617627dffa4c67ba0ea120fd13 (patch) | |
tree | 4e585bf4d9ddf05eac34adc6cf4c01f3ac2fe9cb /drivers/crypto/padlock-aes.c | |
parent | 6a058a1eadc3882eff6efaa757f2c71a31fe9906 (diff) | |
download | talos-op-linux-8644f771e07c52617627dffa4c67ba0ea120fd13.tar.gz talos-op-linux-8644f771e07c52617627dffa4c67ba0ea120fd13.zip |
x86/kvm/hyper-v: direct mode for synthetic timers
Turns out Hyper-V on KVM (as of 2016) will only use synthetic timers
if direct mode is available. With direct mode we notify the guest by
asserting APIC irq instead of sending a SynIC message.
The implementation uses existing vec_bitmap for letting lapic code
know that we're interested in the particular IRQ's EOI request. We assume
that the same APIC irq won't be used by the guest for both direct mode
stimer and as sint source (especially with AutoEOI semantics). It is
unclear how things should be handled if that's not true.
Direct mode is also somewhat less expensive; in my testing
stimer_send_msg() takes not less than 1500 cpu cycles and
stimer_notify_direct() can usually be done in 300-400. WS2016 without
Hyper-V, however, always sticks to non-direct version.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Roman Kagan <rkagan@virtuozzo.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'drivers/crypto/padlock-aes.c')
0 files changed, 0 insertions, 0 deletions