qemu-devel
[Top][All Lists]
Advanced

[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: Aravinda Prasad
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 0/4] target-ppc: Add FWNMI support in qemu for powerKVM guests
Date: Wed, 08 Jul 2015 13:58:13 +0530
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6


On Friday 03 July 2015 11:31 AM, David Gibson wrote:
> On Thu, Jul 02, 2015 at 07:11:52PM +1000, Alexey Kardashevskiy wrote:
>> On 04/02/2015 03:46 PM, David Gibson wrote:
>>> On Thu, Apr 02, 2015 at 03:28:11PM +1100, Alexey Kardashevskiy wrote:
>>>> On 11/19/2014 04:48 PM, Aravinda Prasad wrote:
>>>>>
>>>>>
>>>>> 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?
>>>>
>>>>
>>>> Any updates about FWNMI? Thanks
>>>
>>> Huh.. I'd completely forgotten about this.  Aravinda, can you repost
>>> your latest work on this?
>>
>>
>> Aravinda disappeared...
> 
> Ok, well someone who cares about FWNMI is going to have to start
> sending something, or it won't happen.

I am yet to work on the new approach proposed above. I will start
looking into that this week.

> 

-- 
Regards,
Aravinda




reply via email to

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