mirror of
https://github.com/cloud-hypervisor/cloud-hypervisor.git
synced 2024-07-02 16:02:37 +00:00
a455917db5
Previously, we were assuming that every time an eventfd notified us, there was only a single event waiting for us. This meant that if, while one API request was being processed, two more arrived, the second one would not be processed (until the next one arrived, when it would be processed instead of that event, and so on). To fix this, make sure we're processing the number of API and debug requests we've been told have arrived, rather than just one. This is easy to demonstrate by sending lots of API events and adding some sleeps to make sure multiple events can arrive while each is being processed. For other uses of eventfd, like the exit event, this doesn't matter — even if we've received multiple exit events in quick succession, we only need to exit once. So I've only made this change where receiving an event is non-idempotent, i.e. where it matters that we process the event the right number of times. Technically, reset requests are also non-idempotent — there's an observable difference between a VM resetting once, and a VM resetting once and then immediately resetting again. But I've left that alone for now because two resets in immediate succession doesn't sound like something anyone would ever want to me. Signed-off-by: Alyssa Ross <hi@alyssa.is> |
||
|---|---|---|
| .. | ||
| api | ||
| acpi.rs | ||
| clone3.rs | ||
| config.rs | ||
| coredump.rs | ||
| cpu.rs | ||
| device_manager.rs | ||
| device_tree.rs | ||
| gdb.rs | ||
| interrupt.rs | ||
| lib.rs | ||
| memory_manager.rs | ||
| migration.rs | ||
| pci_segment.rs | ||
| seccomp_filters.rs | ||
| serial_buffer.rs | ||
| serial_manager.rs | ||
| sigwinch_listener.rs | ||
| vm.rs | ||