qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Qemu-ppc] [PATCH 3/5] target-ppc: Build error log


From: Alexander Graf
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 3/5] target-ppc: Build error log
Date: Thu, 28 Aug 2014 10:36:26 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0


On 28.08.14 08:12, Aravinda Prasad wrote:
> 
> 
> On Wednesday 27 August 2014 03:20 PM, Alexander Graf wrote:
>>
>>
>> On 25.08.14 15:45, Aravinda Prasad wrote:
>>> Whenever there is a physical memory error due to bit
>>> flips, which cannot be corrected by hardware, the error
>>> is passed on to the kernel. If the memory address in
>>> error belongs to guest address space then guest kernel
>>> is responsible to take action. Hence the error is passed
>>> on to guest via KVM by invoking 0x200 NMI vector.
>>>
>>> However, guest OS, as per PAPR, expects an error log
>>> upon such error. This patch registers a new hcall
>>> which is issued from 0x200 interrupt vector and builds
>>> the error log, copies the error log to rtas space and
>>> passes the address of the error log to guest
>>>
>>> Enhancement to KVM to perform above functionality is
>>> already in upstream kernel.
>>>
>>> Signed-off-by: Aravinda Prasad <address@hidden>
>>
>> Why do we have to maintain the error log inside the rtas blob? Can't we
>> just create a fixed MMIO region that is backed by an error log device in
>> QEMU?
>>
>> Then this call would just always return that specific address and we'd
>> also have a single file that deals with all of the error reporting.
> 
> PAPR requires error log to be inside rtas space. Hence guest OS
> explicitly checks if error log is inside rtas space.
> 
> VALID_FWNMI_BUFFER does this check inside fwnmi_get_errinfo() in the kernel.

So why not put it at 0x7000 then?


Alex



reply via email to

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