When a guest OS performs an RTC change action, we wish this event be
captured by developers, and then they can decide what to do with it.
(e.g., whether to change physical RTC)
There are some facts that makes RTC change event a bit complicated:
- There are 7 RTC date/time regs (year, month…). They can only be
updated one by one.
- RTC time is not reliable before date/time update is finished.
- Guests can update RTC date/time regs in any order.
- Guests may update RTC date/time regs during either RTC halted or not
halted.
A single date/time update event is not reliable. We have to wait for
the guest to finish the update process. So the DM's event handler
sets up a timer, and wait for some time (1 second). If no more change
happens befor the timer expires, we can conclude that the RTC
change has been done. Then the rtc change event is emitted.
This logic of event handler can be used to process HV vrtc time change
event too.
Tracked-On: #8547
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
The idea of event throttle is to allow only curtain mounts of vm_events
to be emitted per second. This feature is implemented with an event
counter and a timer_fd periodic timer. Event counter increases until it
reaches the throttle rate limit, then the periodic timer resets the
counter in each time window.
Events exceed the throttle rate are dropped.
Tracked-On: #8547
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
The default event handler generates the vm_event message in json format,
then emit it through command monitor.
The event data json txt is currently leaved as blank. When a specific
event type is implemented, its event data generate handler can be added
correspondingly.
Tracked-On: #8547
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
This patch creates a thread for vm_event delivery. The thread uses epoll
to poll event notifications, then read out the msg data queued in sbuf.
An event handler is called upon success receiving. Both HV and DM event
sources share the same process.
Also vm_event tx API for DM event source is added in this patch.
Tracked-On: #8547
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
This patch adds vm_event sbuf and notification initialization.
We have 2 types of event source: DM and HV, and they are slightly
different:
- Sbuf for DM event source is a memery page shared between threads.
Event notifications are delivered by userspace eventfd.
- While for hv event source, sbuf is a memery page shared with HV. Its
address(GPA) is shared to HV through hypercall. Its notifications
are generated by HV upcall, then delivered by kernel/userspace eventfd.
A sbuf message path acts like a one way ‘tunnel’, so a data structure
‘vm_event_tunnel’ is created to organize those sbufs.
Tracked-On: #8547
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
Wu Zhou