o run guest
for the first time. Is this right? Or am I missing something ?
Moreover the changelog in [patch 10/11] says that you cease the
scheduler. This pushes me to think that you do not expect the scheduler
to run on the secondary threads ever again after you have launched the
guest. This does not look right to me.
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARN(condition, format...);
> + return 0;
> + }
> + /* In fact, if we can migrate the primary, it will be more fine */
> + xics_migrate_irqs_away();
Isn't the aim of the patch to migrate irqs away from the secondary onto
the primary? But from above it
secondary threads
are busy, scheduling ticks will fire and try to schedule a new task on them.
Regards
Preeti U Murthy
>
> Introduce a kthread (anti_tickless) on primary, so when there is only
> one vcpu thread on primary, the secondary can resort to anti_tickless
> to keep the prim
lag to
true. So at compile time, we resolve the flag.
While booting, we look at the flag and decide whether to get the
secondaries online. So we get the current behavior if we have not
configured KVM_PPC_ENABLE_SECONDARY. Will this achieve the purpose of
this patch?
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
use the secondary thread is as alive and kicking
as the primary thread on the host. There can be hrtimers queued, there
may be an IPI from a thread in another core. We cannot ignore handling
them while we wait for the primary thread to switch context.
There is also a bug as far as I can see with ha
hem to exit to host. This cannot be
trivially solved unless we can isolate these threads in some way.
Regards
Preeti U Murthy
>
> Signed-off-by: Liu Ping Fan
> ---
> arch/powerpc/include/asm/kvm_host.h | 3 +++
> arch/powerpc/kernel/asm-offsets.c |
, which can be queued on
these secondary threads. These patches have not taken care to migrate
timers or tasks before entering guest as far as I observed. Hence we
cannot just turn off time base like this and expect to handle the above
mentioned events the next time the primary thread decides to exi
BOOK3S_64_HV
This patch is required ontop of all the rest :) The top patches won't
compile without this one. Every patch in the patchset should be able to
compile successfully without the aid of the patches that come after it.
Regards
Preeti U Murthy
--
To unsubscribe from this list: send th
