Anthony Liguori wrote:
> 1) Not really sure what is needed for CONFIG_PREEMPT support. I'm not
> sure which paravirt_ops calls are actually re-entrant.
I'm not sure that has specifically come up. The main issue is whether a
particular call can be preempted and whether that matters. I guess the
calls which affect a particular CPU's state will generally be called in
a non-preemptable context, but I guess we can't assume that; the best
approach is to assume that each call be atomic with respect to preemption.
Things like batching must be completed with preemption disabled over the
whole batch. I check that with BUG_ON in the Xen code.
> 2) The paravirt_ops implementation is registered with
> core_initcall(). However, the paravirt_ops banner is also printed
> with core_initcall() so that fact that this works now is just the luck
> of build order. Need a better way to initialize the KVM paravirt_ops
> backend.
Hm. We could make the banner printing later; obviously its purely
cosmetic. I put it as a core_initcall on the assumption that pv-ops
would be set up very early as it is with Xen and lguest, and so the
banner should print relatively early. But if your model is that you
boot fully virtualized for a while, and then become paravirtualized
later, then it would make sense to defer banner printing until then.
J
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
