|
From: | Alexey Kardashevskiy |
Subject: | Re: [Qemu-devel] [Qemu-ppc] [GIT PULL for qemu-pseries REPOST] pseries: Update SLOF firmware image |
Date: | Fri, 23 Aug 2019 14:09:44 +1000 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 |
On 14/08/2019 14:33, Aravinda Prasad wrote:
On Tuesday 13 August 2019 07:47 PM, David Gibson wrote:On Tue, Aug 13, 2019 at 01:00:24PM +0530, Aravinda Prasad wrote:On Monday 12 August 2019 03:38 PM, David Gibson wrote:On Mon, Aug 05, 2019 at 02:14:39PM +0530, Aravinda Prasad wrote:Alexey/David, With the SLOF changes, QEMU cannot resize the RTAS blob. Resizing is required for FWNMI support which extends the RTAS blob to include an error log upon a machine check. The check to valid RTAS buffer fails in the guest because the rtas-size updated in QEMU is not reflecting in the guest. Any workaround for this?Well, we should still be able to do it, it just means fwnmi would need a SLOF change. It's an inconvenience, but not really a big deal.Yes. Alexey and I were discussing about the following changes to SLOf: diff --git a/lib/libhvcall/hvcall.S b/lib/libhvcall/hvcall.S index b19f6dbeff2c..880d29a29122 100644 --- a/lib/libhvcall/hvcall.S +++ b/lib/libhvcall/hvcall.S @@ -134,6 +134,7 @@ ENTRY(hv_rtas) ori r3,r3,KVMPPC_H_RTAS@l HVCALL blr + .space 2048 .globl hv_rtas_size hv_rtas_size: .long . - hv_rtas; But this will statically reserve space for RTAS even when SPAPR_CAP_FWNMI_MCE is OFF.Sure. We could flag that in the DT somehow, and have SLOF reserve the space conditionally. Or we could just ignore it. 2 kiB is miniscule compared to our minimum guest size, and our current RTAS is microscopic compared to PowerVM.I also think so, 2kiB is miniscule so we can allocate it statically. Alexey, Can you please include the above one line fix to SLOF?
I am thinking of: === @@ -132,20 +132,22 @@ ENTRY(hv_rtas) mr r4,r3 lis r3,KVMPPC_H_RTAS@h ori r3,r3,KVMPPC_H_RTAS@l HVCALL blr + .space 2048 - (. - hv_rtas) .globl hv_rtas_size hv_rtas_size: .long . - hv_rtas; ENTRY(hv_rtas_broken_sc1) mr r4,r3 lis r3,KVMPPC_H_RTAS@h ori r3,r3,KVMPPC_H_RTAS@l .long 0x7c000268 blr + .space 2048 - (. - hv_rtas_broken_sc1) .globl hv_rtas_broken_sc1_size hv_rtas_broken_sc1_size: .long . - hv_rtas_broken_sc1; ===to align the rtas blob to 2k precisely. But QEMU hardcoded RTAS_ERROR_LOG_OFFSET bothers me a bit, I should probably put some sort of a magic marker at which RTAS log can start.
David, any thoughts? The marker could be as simple as a zero, for example. -- Alexey
[Prev in Thread] | Current Thread | [Next in Thread] |