Re: [PATCH 0/5] KVM paravirt_ops implementation

[Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>]

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
>
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/