Hi Stefano,
On 23/02/2021 01:24, Stefano Stabellini wrote:
On Mon, 22 Feb 2021, Bertrand Marquis wrote:
On 20 Feb 2021, at 14:04, Julien Grall <jul...@xen.org> wrote:
The consequence of this patch is that a guest can cause vcpu_unblock(v),
hence vcpu_wake(v), to be called for its own vcpu, which basically
always changes v to RUNSTATE_runnable. However, that alone shouldn't
allow v to always come up ahead of any other vcpus in the queue, right?
It should be safe. I just wanted a second opinion on this :-)
vcpu_wake() only tells the scheduler that the vCPU can be run, it is
then up to the scheduler to decide what to do. AFAIU, for credit{1, 2},
each vCPU will have some credit. If you run out of credit, then you vCPU
will not be descheduled if there is work do it.
It was possible to trigger interrupts for your own vcpus even before, but
now the code path is going to be direct for virtual interrupts.
You can already trigger "directly" virtual interrupts using the event
channels.
Cheers,
--
Julien Grall
