Re: [Qemu-devel] [PATCH -V3 1/4] target-ppc: Update slb array with correct index values.

[Aneesh Kumar K.V]

Alexander Graf <address@hidden> writes:

> On 23.08.2013, at 06:20, Aneesh Kumar K.V wrote:
>
>> From: "Aneesh Kumar K.V" <address@hidden>
>> 
>> Without this, a value of rb=0 and rs=0 results in replacing the 0th
>> index. This can be observed when using gdb remote debugging support.
>> 
>> (gdb) x/10i do_fork
>> 0xc000000000085330 <do_fork>:        Cannot access memory at address 
>> 0xc000000000085330
>> (gdb)
>> 
>> This is because when we do the slb sync via kvm_cpu_synchronize_state,
>> we overwrite the slb entry (0th entry) for 0xc000000000085330
>> 
>> Signed-off-by: Aneesh Kumar K.V <address@hidden>
>> ---
>> target-ppc/kvm.c | 20 ++++++++++++++++++--
>> 1 file changed, 18 insertions(+), 2 deletions(-)
>> 
>> diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
>> index 30a870e..6878af2 100644
>> --- a/target-ppc/kvm.c
>> +++ b/target-ppc/kvm.c
>> @@ -1033,9 +1033,25 @@ int kvm_arch_get_registers(CPUState *cs)
>> 
>>     /* Sync SLB */
>> #ifdef TARGET_PPC64
>> +        /*
>> +         * KVM_GET_SREGS doesn't return slb entry with slot information
>> +         * same as index. The ioctl zero fills the array and update only
>> +         * upto slb_max entries. We cannot depend on the slot value
>> +         * in the slbe field for update, because a zero slbe value would
>> +         * result in us wrongly updating the 0th index. Instead we zero fill
>> +         * the env->slb array first so that we mark all entries invalid and
>> +         * update with only valid SLB entries.
>
> Still too negative. How about something like this:
>
> /*
> * The packed SLB array we get from KVM only contains information
> *  about valid entries. So we flush our internal copy to get rid of stale
> *  ones, then put all valid SLB entries back in.
> */

updated

>
>> +         */
>> +        memset(env->slb, 0, 64 * sizeof(ppc_slb_t));
>
> Can't we use ARRAY_SIZE here and below?

I was thinking we want to be explicit there saying we are zeroing out all
the 64 entries. I could do sizeof(env->slb).

-anesh