Re: [PATCH 0/8] KVM updates for 2.6.20-rc2

* Avi Kivity <avi@xxxxxxxxxxxx> wrote:

> >NOTE: this is not a worry for upstream kernel, it is caused by 
> >PREEMPT_RT scheduling in previously atomic APIs like kunmap(). But 
> >KVM used to work pretty nicely in -rt and this problem got introduced 
> >fairly recently, related to some big-page changes IIRC.
> 
> This is not a recent change.  The x86 emulator is fetching an 
> instruction or a memory operand.

well, the fact that it's somehow ending up in highmem and thus the kmap 
becomes nontrivial could be a recent change maybe?

> > Any suggestions of how to best fix this in -rt? Basically, it would 
> > be nice to decouple KVM from get_cpu/preempt_disable type of 
> > interfaces as much as possible, to make it fully preemptible.
> 
> kvm on intel uses hidden cpu registers, so it can't be migrated as a 
> normal process. [...]

oh, granted. My suggestion would be to make it more atomic - not to 
break the physical attachment of a KVM context to a physical CPU (which 
is unbreakable, obviously).

> [...] We'd need a hook on context switch to check if we migrated to 
> another cpu, issue an ipi to unload the registers on the previous cpu, 
> and reload the registers on the current cpu.  The hook would need to 
> be protected from context switches.  See vmx.c:vmx_vcpu_load() for the 
> gory details.  The actual launch would require a small non-preemptible 
> section as well, on both intel and AMD.

actually, another, possibly better approach would be to attach a KVM 
context to tasks, automatically loaded/unloaded upon switch_to(). No 
need to do IPIs. Would this be fast enough?

        Ingo

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV