Re: [Qemu-devel] [Qemu-ppc] [PATCH] Allow bit 15 to be set to 1 on slbmfee and slbmfev

[Ivan Warren]

Le 7/19/2019 à 3:34 AM, David Gibson a écrit :
> On Thu, Jul 18, 2019 at 10:15:52PM +0200, Ivan Warren wrote:
> > Le 7/18/2019 à 7:19 PM, Greg Kurz a écrit :
> > > We usually mention the subsystem name in the subject, ie.
> > >
> > > target/ppc: Allow bit 15 to be set to 1 on slbmfee and slbmfev
> > Gotcha ! Still learning the process as I go. Next time I submit something,
> > I'll follow the guidelines more accurately.
> > > On Thu, 18 Jul 2019 14:44:49 +0200
> > > Ivan Warren <address@hidden> wrote:
> > >
> > > > Allow bit 15 to be 1 in the slbmfee and slbmfev in TCG
> > > > as per Power ISA 3.0B (Power 9) Book III pages 1029 and 1030.
> > > > Per this specification, bit 15 is implementation specific
> > > > so it may be 1, but can probably ne safely ignored.
> > Another typo from me !
> >
> > s/ne safely/be safely/
> >
> > > > Power ISA 2.07B (Power 7/Power 8) indicates the bit is
> > > > reserved but some none Linux operating systems do set
> > > s/none Linux/non-Linux
> > Thanks ! Sorry for the typo !
> > > > this bit to 1 when entering the debugger.
> > > > So it is likely it is implemented on those systems
> > > > but wasn't yet documented.
> > > ISA describes things that are common to several processor types,
> > > but each implementation may do some extra stuff... like giving
> > > a special meaning to an invalid instruction form for example (see
> > > commit fa200c95f7f99ce14b8af25ea0be478c722d3cec). This is supposed
> > > to be documented in the user manual.
> > >
> > > Maybe something similar was done with the reserved bit 15, even if I
> > > could fine no trace of that in the Power8 UM... of course. I'll try
> > > to find clues within IBM.
> > >
> > > https://openpowerfoundation.org/?resource_lib=power8-processor-users-manual
> > >
> > > but it is indeed mentioned in the Power9 UM:
> > >
> > > https://openpowerfoundation.org/?resource_lib=power-processor-users-manual
> > >
> > > 4.10.7.2 SLB Management Instructions
> > >
> > > The POWER9 core implements the SLB management instructions as defined in the
> > > Power ISA (Version 3.0B). Specifically, the following instruction details are
> > > noteworthy:
> > > • The slbmfee and slbmfev instructions can read any SLB entry when UPRT = ‘1’,
> > >     if the L-bit in the instruction image is set to a ‘1’. This is an
> > >     implementation-specific feature that will only be used in the future if and
> > >     when the POWER9 processor core supports UPRT = ‘1’ for HPT translation.
> > >
> > > Not sure if we support that in TCG, but it doesn't hurt to relax the check
> > > if that's enough to make AIX's debugger happy.
> > Yep !
> > > Reviewed-by: Greg Kurz <address@hidden>
> > >
> > > > Signed-off-by: Ivan Warren <address@hidden>
> > > > ---
> > > >
> > > > The original creator of the patch is "Zhuowei Zhang"
> > > > (https://twitter.com/zhuowei) but I couldn't find any e-mail address.
> > > This is the original patch, correct ?
> > >
> > > https://github.com/zhuowei/qemu/commit/c5f305c5d0cd336b2bb31cab8a70f90b72905a1e
> > Indeed !
> > > After speaking with some QEMU folks on irc, it is okay to ignore the lack
> > > of S-o-b because the patch is trivial. But the general rule is to always
> > > require an S-o-b when posting someone else's patch.
> > Is it good practice to add a S-o-b without the original author's consent
> > and/or without an e-mail address ?
> Absolutely not.

I thought as much (and why I didn't do it). However, I still wanted to 
give credit (but not a "Signed-off-by:" tag since this didn't actually 
occur) to the person who originally found the issue (and the fix). I 
guess it should simply have been included in the commit log as a 
comment, not as a comment in the patch submission message (between the 
--- and the actual diff).

Anyway, I think the patch is sane and carries no systemic risk (it only 
affects AIX KBD - and possibly other low level debuggers) - and there 
are probably no PPC system that actually rely on those instructions 
throwing an exception if this particular bit is not 0 !

> > Although I would very much doubt he would
> > have complained.
> >
> > Anyway, thanks for reviewing and for the tips ! (and sorry for all the
> > noise).
> >
> > > >     target/ppc/translate.c | 4 ++--
> > > >     1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/target/ppc/translate.c b/target/ppc/translate.c
> > > > index 4a5de28036..85f8b147ba 100644
> > > > --- a/target/ppc/translate.c
> > > > +++ b/target/ppc/translate.c
> > > > @@ -7064,8 +7064,8 @@ GEN_HANDLER2(mtsr_64b, "mtsr", 0x1F, 0x12, 0x06,
> > > > 0x0010F801, PPC_SEGMENT_64B),
> > > >     GEN_HANDLER2(mtsrin_64b, "mtsrin", 0x1F, 0x12, 0x07, 0x001F0001,
> > > >                  PPC_SEGMENT_64B),
> > > >     GEN_HANDLER2(slbmte, "slbmte", 0x1F, 0x12, 0x0C, 0x001F0001,
> > > > PPC_SEGMENT_64B),
> > > > -GEN_HANDLER2(slbmfee, "slbmfee", 0x1F, 0x13, 0x1C, 0x001F0001,
> > > > PPC_SEGMENT_64B),
> > > > -GEN_HANDLER2(slbmfev, "slbmfev", 0x1F, 0x13, 0x1A, 0x001F0001,
> > > > PPC_SEGMENT_64B),
> > > > +GEN_HANDLER2(slbmfee, "slbmfee", 0x1F, 0x13, 0x1C, 0x001E0001,
> > > > PPC_SEGMENT_64B),
> > > > +GEN_HANDLER2(slbmfev, "slbmfev", 0x1F, 0x13, 0x1A, 0x001E0001,
> > > > PPC_SEGMENT_64B),
> > > >     GEN_HANDLER2(slbfee_, "slbfee.", 0x1F, 0x13, 0x1E, 0x001F0000,
> > > > PPC_SEGMENT_64B),
> > > >     #endif
> > > >     GEN_HANDLER(tlbia, 0x1F, 0x12, 0x0B, 0x03FFFC01, PPC_MEM_TLBIA),

smime.p7s
Description: Signature cryptographique S/MIME