Re: [PATCH v6 09/11] arm/hvf: Add a WFI handler

[Alexander Graf]

On 10.02.21 23:17, Peter Maydell wrote:
> On Wed, 10 Feb 2021 at 20:25, Peter Collingbourne <pcc@google.com> wrote:
> > On Thu, Jan 28, 2021 at 8:25 AM Peter Maydell <peter.maydell@linaro.org> wrote:
> > > On Wed, 20 Jan 2021 at 22:44, Alexander Graf <agraf@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