Re: [Qemu-devel] [Qemu-ppc] [PATCH 8/9] ppc: Add missing slbfee. instruction on ppc64 BookS processors

From: "Cédric Le Goater" <clg@kaod.org>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>, qemu-ppc@nongnu.org
Cc: qemu-devel@nongnu.org, David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 8/9] ppc: Add missing slbfee. instruction on ppc64 BookS processors
Date: Wed, 6 Jul 2016 08:57:47 +0200	[thread overview]
Message-ID: <3625f797-2c3b-16b7-e6ee-e6f8baeeb178@kaod.org> (raw)
In-Reply-To: <1467756609.13965.78.camel@kernel.crashing.org>

On 07/06/2016 12:10 AM, Benjamin Herrenschmidt wrote:
> On Tue, 2016-07-05 at 19:23 +0200, Cédric Le Goater wrote:
>>
>>
>> So, I was trying today to reconciliate the powernv patchset with 
>> the current HEAD of qemu when I bumped into the old version of this 
>> patch. I checked the specs and when no slb are found, rt should 
>> just be 0. The machine check is only generated when multiple
>> matching 
>> entries are found. So the above probably needs a fix, at least for 
>> the NULL case ? 
> 
> Yes the old patch was broken but I wrote (and already merged) a better
> one since then. Check upstream qemu :-)

Yes much better :) I saw that when trying to apply the original powernv 
patchset on top of current qemu.

> The -1 result is now handled in the JITed code to do the right thing
> (well, afaik).

well, no. It should be a 0 when the slb is not found, and thus no 
machine check. That is how I understand : 

	The SLB is searched for an entry that matches the
	effective address specified by register RB. The search
	is performed as if it were being performed for purposes
	of address translation. That is, in order for a given entry
	to satisfy the search, the entry must be valid (V=1),
	(RB)0:63-s must equal SLBE[ESID0:63-s] (where 2s is
	the segment size selected by the B field in the entry),
	and RB39 must be equal to SLBTA. If exactly one
	matching entry is found, the contents of the B, VSID,
	Ks, Kp, N, L, C, TA, and LP fields of the entry are placed
	into register RT. If no matching entry is found, register
	RT is set to 0. If more than one matching entry is found,
	either one of the matching entries is used, as if it were
	the only matching entry, or a Machine Check occurs. If
	a Machine Check occurs, register RT, CR Field 0, and,
	in tags active mode, the FXCC are set to undefined values,
	and the description below of how this register and
	these fields are set does not apply.

but do we care that much in qemu ? May be the machine check is 
better to have.

Cheers,

C.