Hi Jeremy,
Jeremy Fitzhardinge wrote:
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.
So each call would need to disable preemption? I'm not sure that makes
a whole lot of sense for something like CR reads/writes. In fact,
without passing in a cpu parameter, I'm pretty sure that those
operations *have* to require preemption to be disabled.
For something like MMU operations, preemption really doesn't have to be
disabled.
Things like batching must be completed with preemption disabled over the
whole batch. I check that with BUG_ON in the Xen code.
Right now the KVM batching requires preemption to be disabled for
batching. I don't think that's a hard requirement though since we could
pass the current batch PA as part of the flush hypercalls.
Things are a lot easier though if we can just assume preemption is
disabled :-)
Are you aware of any paravirt_ops calls that are probably being called
in the kernel with preemption enabled?
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.
I don't see a compelling reason to paravirtualize earlier although I
also don't see a compelling reason not too. I noticed that VMI hooks
setup.c. It wasn't immediately obvious why it was hooking there but
perhaps it worthwhile to have a common hook? I suspect VMI and KVM will
have a similar model for startup.
Thanks for the feedback!
Regards,
Anthony Liguori
J
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
