On 10.02.21 23:17, Peter Maydell wrote:
On Wed, 10 Feb 2021 at 20:25, Peter Collingbourne <p...@google.com> wrote:
On Thu, Jan 28, 2021 at 8:25 AM Peter Maydell <peter.mayd...@linaro.org> wrote:
On Wed, 20 Jan 2021 at 22:44, Alexander Graf <ag...@csgraf.de> wrote:
+ if (!seconds && nanos < 2000000) {
+ break;
+ }
+
+ struct timespec ts = { seconds, nanos };
+ hvf_wait_for_ipi(cpu, &ts);
+ }
Why doesn't the timer timeout manifest as an IPI ? (Put another way,
why is the timer interrupt special?)
Timer timeouts result in an IPI (via HV_EXIT_REASON_VTIMER_ACTIVATED)
if they become due while in hv_vcpu_run(). But at this point we are
not in hv_vcpu_run() (due to the aforementioned difference in wait
behavior between x86 and ARM) so we need to "manually" wait for the
timer to become due, re-enter the guest, let it exit with
HV_EXIT_REASON_VTIMER_ACTIVATED and then trigger the IPI.
But WFI doesn't just wait for a timer interrupt, it waits for
any interrupt. So it doesn't seem right that the timer interrupt
in particular is being handled specially here.
The vtimer is handled by hvf itself and results in a #vmexit when
triggered. On wfi, we're switching from an hvf owned vtimer to a QEMU
owned one. The only events that can happen to wake us from wfi are kicks
(IRQs, maintenance events) or expiry of the vtimer. The select() logic
in this patch handles both, as it wakes up on an IPI (kick because of
IRQ/maint event) and exits gracefully after the timer deadline.
Alex
