On 13.12.2010, at 20:03, Scott Wood wrote:

> On Mon, 13 Dec 2010 10:45:30 +0200
> Avi Kivity <[email protected]> wrote:
> 
>> On 12/13/2010 10:42 AM, Alexander Graf wrote:
>>> Yeah, let me rephrase my exact memory on this:
>>> 
>>> If the HV just rewrites instructions in the guest, it behaves different 
>>> from real hw which is bad. It could potentially break checksumming inside 
>>> the guest.
>>> 
>>> If, however, the guest sends a hypercall to the HV saying "please patch me" 
>>> or there's a flag on creation time to enable patching, I have a hard time 
>>> finding a reason to do it inside the guest context.
>>> 
>>> Back when I implemented this, we did however have discussions on exactly 
>>> that distinction between patching in host or guest space and for some 
>>> reason I remember that you and Hollis figured that guest patching is 
>>> superior. I just really can't remember why and couldn't find traces of this 
>>> in my inbox either :).
>> 
>> The interface is a lot simpler.  The guest decides what to patch and 
>> where to jump.  A "please patch me" flag needs a ton of documentation on 
>> what patch means and what the constraints on the guest environment are.
>> 
> 
> The constraints need to be documented, but I think "a ton" is a bit of
> an exaggeration -- and having the guest do the patching itself means
> that the structure of the shared page must become stable ABI.  Having
> the hypervisor do the bulk of the work also makes it easier to add
> paravirt to new OSes (in the embedded world, often the reason someone
> wants to do virtualization is to run some custom OS alongside Linux).
> 
> OTOH, having the guest do it makes it easier to do more complex
> rewriting such as mtmsr[1].  And the fact that we've already got an
> implementation makes for a compelling tie-breaker.
> 
> -Scott
> 
> [1] Speaking of which, what happens when an interrupt is raised in the
> middle of a paravirt critical section?  KVM will hold off the
> interrupt delivery if it sees the critical flag set, but when will it
> deliver the postponed interrupt?  Seems like it will wait until the next
> time an exit happens for some other reason.

mtmsr with IF=1 checks for pending interrupts and enables them with a real 
mtmsr then which again checks interrupts in vm entry, so it immediately gets 
injected :).


Alex

--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to