qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 0/4] target-ppc: Add FWNMI support in qemu fo


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH v3 0/4] target-ppc: Add FWNMI support in qemu for powerKVM guests
Date: Wed, 19 Nov 2014 13:22:01 +0100



> Am 19.11.2014 um 12:44 schrieb David Gibson <address@hidden>:
> 
>> On Wed, Nov 19, 2014 at 11:32:56AM +0100, Alexander Graf wrote:
>> 
>> 
>> 
>>> Am 19.11.2014 um 06:48 schrieb Aravinda Prasad <address@hidden>:
>>> 
>>> 
>>> 
>>> On Tuesday 11 November 2014 08:54 AM, David Gibson wrote:
>>> 
>>> [..]
>>> 
>>>> 
>>>> So, this may not still be possible depending on whether the KVM side
>>>> of this is already merged, but it occurs to me that there's a simpler
>>>> way.
>>>> 
>>>> Rather than mucking about with having to update the hypervisor on the
>>>> RTAS location, they have qemu copy the code out of RTAS, patch it and
>>>> copy it back into the vector, you could instead do this:
>>>> 
>>>> 1. Make KVM instead of immediately delivering a 0x200 for a guest
>>>> machine check, cause a special exit to qemu.
>>>> 
>>>> 2. Have the register-nmi RTAS call store the guest side MC handler
>>>> address in the spapr structure, but perform no actual guest code
>>>> patching.
>>>> 
>>>> 3. Allocate the error log buffer independently from the RTAS blob,
>>>> so qemu always knows where it is.
>>>> 
>>>> 4. When qemu gets the MC exit condition, instead of going via a
>>>> patched 0x200 vector, just directly set the guest register state and
>>>> jump straight into the guest side MC handler.
>>> 
>>> Before I proceed further I would like to know what others think about
>>> the approach proposed above (except for step 3 - as per PAPR the error
>>> log buffer should be part of RTAS blob and hence we cannot have error
>>> log buffer independent of RTAS blob).
>>> 
>>> Alex, Alexey, Ben: Any thoughts?
>> 
>> If in doubt, stick to PAPR please.
> 
> Apart from (3), which was a misunderstanding on my part, this doesn't
> diverge from PAPR - it's just a question of how we're implementing the
> PAPR behaviour.

Do we need a guest handler at all? Couldn't we make MCs a new exit type and 
handle it all straight from QEMU?


Alex

> 
> -- 
> David Gibson            | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au    | minimalist, thank you.  NOT _the_ _other_
>                | _way_ _around_!
> http://www.ozlabs.org/~dgibson



reply via email to

[Prev in Thread] Current Thread [Next in Thread]