On Thu, 2022-02-10 at 12:17 +0000, Joao Martins wrote: > On 2/8/22 12:36, David Woodhouse wrote: > > > + if (!wait_pending_event(vcpu, sched_poll.nr_ports, ports)) > > > + wait_event_interruptible_timeout( > > > + vcpu_xen->sched_waitq, > > > + wait_pending_event(vcpu, sched_poll.nr_ports, ports), > > > + sched_poll.timeout ?: KTIME_MAX); > > > > Hm, this doesn't wake on other interrupts, does it? > > Hmm, I don't think so? This was specifically polling on event channels, > not sleeping or blocking. > > > I think it should. > > Shouldn't it basically be like HLT, with an additional wakeup when the > > listed ports are triggered even when they're masked? > > > > I am actually not sure. > > Quickly glancing at the xen source, this hypercall doesn't appear to really > block the vcpu, but rather just looking if the evtchn ports are pending and > if a timeout is is specified it sets up a timer. And ofc, wake any evtchn > pollers. But it doesn't appear to actually block the VCPU. It should be > IIRC, the functional equivalent of KVM_HC_VAPIC_POLL_IRQ but for event > channels. > It does block. https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/common/sched/core.c;hb=RELEASE-4.14.4#l1385 It sets the _VPF_blocked bit in the vCPU's pause_flags, then the raise_softirq(SCHEDULE_SOFTIRQ) causes it to deschedule this vCPU when it gets back to the return-to-guest path. It's not Linux, so you don't see a schedule() call :) It'll remain blocked until either an (unmasked) event channel or HVM IRQ is asserted, or one of the masked event channels listed in the poll list is raised. Which is why I tried to tie it into the kvm_vcpu_halt() code path when I updated the patch.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
