[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 0/4] target-ppc: Add FWNMI support
From: |
Alexander Graf |
Subject: |
Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 0/4] target-ppc: Add FWNMI support in qemu for powerKVM guests |
Date: |
Wed, 19 Nov 2014 13:42:56 +0100 |
> Am 19.11.2014 um 13:22 schrieb Alexander Graf <address@hidden>:
>
>
>
>
>>> 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?
Ah, that was your proposal ;). Sure, works for me.
Alex
- Re: [Qemu-devel] [PATCH v3 4/4] target-ppc: Handle ibm, nmi-register RTAS call, (continued)
Re: [Qemu-devel] [PATCH v3 0/4] target-ppc: Add FWNMI support in qemu for powerKVM guests, David Gibson, 2014/11/10
Re: [Qemu-devel] [PATCH v3 0/4] target-ppc: Add FWNMI support in qemu for powerKVM guests, Aravinda Prasad, 2014/11/19