summaryrefslogtreecommitdiffstats
path: root/include/hw/hyperv
Commit message (Collapse)AuthorAgeFilesLines
* hyperv: process POST_MESSAGE hypercallRoman Kagan2018-10-191-0/+18
| | | | | | | | | | | Add handling of POST_MESSAGE hypercall. For that, add an interface to regsiter a handler for the messages arrived from the guest on a particular connection id (IOW set up a message connection in Hyper-V speak). Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> Message-Id: <20180921082217.29481-10-rkagan@virtuozzo.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* hyperv: process SIGNAL_EVENT hypercallRoman Kagan2018-10-192-0/+14
| | | | | | | | | | | | | | Add handling of SIGNAL_EVENT hypercall. For that, provide an interface to associate an EventNotifier with an event connection number, so that it's signaled when the SIGNAL_EVENT hypercall with the matching connection ID is called by the guest. Support for using KVM functionality for this will be added in a followup patch. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> Message-Id: <20180921082217.29481-8-rkagan@virtuozzo.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* hyperv: add synic event flag signalingRoman Kagan2018-10-191-0/+4
| | | | | | | | | | Add infrastructure to signal SynIC event flags by atomically setting the corresponding bit in the event flags page and firing a SINT if necessary. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> Message-Id: <20180921082217.29481-7-rkagan@virtuozzo.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* hyperv: add synic message deliveryRoman Kagan2018-10-191-3/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add infrastructure to deliver SynIC messages to the SynIC message page. Note that KVM may also want to deliver (SynIC timer) messages to the same message slot. The problem is that the access to a SynIC message slot is controlled by the value of its .msg_type field which indicates if the slot is being owned by the hypervisor (zero) or by the guest (non-zero). This leaves no room for synchronizing multiple concurrent producers. The simplest way to deal with this for both KVM and QEMU is to only deliver messages in the vcpu thread. KVM already does this; this patch makes it for QEMU, too. Specifically, - add a function for posting messages, which only copies the message into the staging buffer if its free, and schedules a work on the corresponding vcpu to actually deliver it to the guest slot; - instead of a sint ack callback, set up the sint route with a message status callback. This function is called in a bh whenever there are updates to the message slot status: either the vcpu made definitive progress delivering the message from the staging buffer (succeeded or failed) or the guest issued EOM; the status is passed as an argument to the callback. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> Message-Id: <20180921082217.29481-6-rkagan@virtuozzo.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* hyperv: qom-ify SynICRoman Kagan2018-10-191-0/+5
| | | | | | | | | | | Make Hyper-V SynIC a device which is attached as a child to a CPU. For now it only makes SynIC visibile in the qom hierarchy, and maintains its internal fields in sync with the respecitve msrs of the parent cpu (the fields will be used in followup patches). Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> Message-Id: <20180921082217.29481-3-rkagan@virtuozzo.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* hyperv: factor out arch-independent API into hw/hypervRoman Kagan2018-10-191-0/+31
| | | | | | | | | | | | | | | A significant part of hyperv.c is not actually tied to x86, and can be moved to hw/. This will allow to maintain most of Hyper-V and VMBus target-independent, and to avoid conflicts with inclusion of arch-specific headers down the road in VMBus implementation. Also this stuff can now be opt-out with CONFIG_HYPERV. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> Message-Id: <20180921082041.29380-4-rkagan@virtuozzo.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* hyperv: split hyperv-proto.h into x86 and arch-independent partsRoman Kagan2018-10-191-0/+129
Some parts of the Hyper-V hypervisor-guest interface appear to be target-independent, so move them into a proper header. Not that Hyper-V ARM64 emulation is around the corner but it seems more conveninent to have most of Hyper-V and VMBus target-independent, and allows to avoid conflicts with inclusion of arch-specific headers down the road in VMBus implementation. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> Message-Id: <20180921082041.29380-2-rkagan@virtuozzo.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>