On Fri, Aug 23, 2019 at 02:09:44PM +1000, Alexey Kardashevskiy wrote: > > > 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.
Eh, TBH I don't think an agreed upon magic marker has all that much advantage on an agreed upon offset. Let's keep it simple and retain the fixed offset for now. If that's ever a problem we'll need a synchronized qemu & SLOF update, but that's ok - that's an inconvenience, not a disaster. -- 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
signature.asc
Description: PGP signature