[Qemu-devel] PowerPC64 and more

[Qemu-devel] PowerPC64 and more

[J. Mayer]

[-- Attachment #1: Type: text/plain, Size: 2247 bytes --]

Here's a long awaited patch (hum, Fabrice ? ;-) ).
It is really invasive in the target-ppc subdirectory.

It provides:
* PowerPC 64 target support
* better 64 bits hosts support (use native registers instead of 32 bit
aliases)
* Software driven TLB support for 6xx & 7xx(x) PowerPC with generic
background, then
  PowerPC 4xx software driven TLB will be easy to implement.
* Some preliminary support for 403 MMU.
* More SPR definitions.
* Optimizations and cleanups (sure, always more to do !)
* Serial driver IRQ fixes.

Those new features have some limitations:
* PowerPC 64 is tested only in 32 bits mode, because:
  - No 64 bits PowerPC model is fully implemented (we need at least
970FX).
  - We have no PowerPC 64 hardware based target. I guess PREP could be
used
    to launch Linux.
  - Open Hack'Ware need PPC64 support (work in progress)
 Then it acts exactly the same way as PowerPC 32 target, using 64 bits
registers.
 Note that one will be able to select any 32 bits or 64 bits CPU when
using
 PowerPC 64 target. PowerPC 32 target will remain only because it's much
more
 efficient when running on 32 bits hosts.
* There is no PowerPC 64 linux-user emulation because I did not find a
clean way
  to be able to launch all PowerPC executables (ie 64 bits _and_ 32 bits
ones)
  with this target.
* SoftTLB emulation is buggy: it works well until we get in user mode
  But while entering init process, it comes into an infinite loop
filling TLBs...
  This need to be fixed to get a complete 602 & 603 emulation.
* New CPU model (40x, 440, 601, 602, 603, 7x5, 74xx, ...)
  are incomplete and not fully fonctionnal.
  For now, only PowerPC 604, 740 & 750 models are usable.

To come (to do or to be tested):
* more support for PowerPC 40x & 440:
  - I got most of unimplemented instructions (mostly tested !)
  - MMU and exception models need to be implemented (partially done)
  - I already have some code for simple devices emulation using DCR (IRQ
controler, serial   
    ports, ...)
* Altivec for 74xx (yes, I got most of it...)
* PowerPC 601 support (will also give original POWER support, as a side
effet).
* and more....

Please enjoy and report any problem, success or suggestion.

-- 
J. Mayer <l_indien@magic.fr>
Never organized

[-- Attachment #2: ppc64_diff.tar.bz2 --]
[-- Type: application/x-bzip-compressed-tar, Size: 45876 bytes --]

Re: [Qemu-devel] PowerPC64 and more

[Filip Navara]

J. Mayer wrote:

>Here's a long awaited patch (hum, Fabrice ? ;-) ).
>It is really invasive in the target-ppc subdirectory.
>  
>
[snip]

wow, you repeated my and Fabrice's mistake once more ... think about the 
code below more :)
note: when you'll be done thinking or run out of ideas see my x86-64 
patches that i sent to ML this morning.

- Filip

Index: exec.c
===================================================================
RCS file: /cvsroot/qemu/qemu/exec.c,v
retrieving revision 1.60
diff -u -d -w -B -b -d -p -r1.60 exec.c
--- exec.c    24 Apr 2005 18:02:38 -0000    1.60
+++ exec.c    20 Jul 2005 23:00:26 -0000
@@ -257,6 +257,10 @@ static inline VirtPageDesc *virt_page_fi
 {
     VirtPageDesc *p;
 
+    /* XXX: should not truncate for 64 bit addresses */
+#if TARGET_LONG_BITS > 32
+    index &= (L1_SIZE - 1);
+#endif
     p = l1_virt_map[index >> L2_BITS];
     if (!p)
         return 0;

Re: [Qemu-devel] PowerPC64 and more

[J. Mayer]

On Fri, 2005-07-22 at 00:10 +0200, Filip Navara wrote:
> J. Mayer wrote:
> 
> >Here's a long awaited patch (hum, Fabrice ? ;-) ).
> >It is really invasive in the target-ppc subdirectory.
> >  
> >
> [snip]
> 
> wow, you repeated my and Fabrice's mistake once more ... think about the 
> code below more :)
> note: when you'll be done thinking or run out of ideas see my x86-64 
> patches that i sent to ML this morning.

Without this patch, it crashes at the first instruction trying to access
the BIOS.
And your patch does not solve the problem:
on a real PowerPC 64 machine, we can use the whole 64 bits virtual
space.
We agreed with Fabrice that there should be at least one more
indirection in page mapping, because it would cost too much memory to
try to map the whole needed memory space in one table, even if we can
"forget" some of the middle bits in most cases.
Then, you're right, this patch is ugly but allows not to crash until we
have a correct solution with indirect tables to get a very large virtual
space.

> Index: exec.c
> ===================================================================
> RCS file: /cvsroot/qemu/qemu/exec.c,v
> retrieving revision 1.60
> diff -u -d -w -B -b -d -p -r1.60 exec.c
> --- exec.c    24 Apr 2005 18:02:38 -0000    1.60
> +++ exec.c    20 Jul 2005 23:00:26 -0000
> @@ -257,6 +257,10 @@ static inline VirtPageDesc *virt_page_fi
>  {
>      VirtPageDesc *p;
>  
> +    /* XXX: should not truncate for 64 bit addresses */
> +#if TARGET_LONG_BITS > 32
> +    index &= (L1_SIZE - 1);
> +#endif
>      p = l1_virt_map[index >> L2_BITS];
>      if (!p)
>          return 0;

-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] PowerPC64 and more

[Filip Navara]

J. Mayer wrote:

>On Fri, 2005-07-22 at 00:10 +0200, Filip Navara wrote:
>  
>
>>J. Mayer wrote:
>>
>>    
>>
>>>Here's a long awaited patch (hum, Fabrice ? ;-) ).
>>>It is really invasive in the target-ppc subdirectory.
>>> 
>>>
>>>      
>>>
>>[snip]
>>
>>wow, you repeated my and Fabrice's mistake once more ... think about the 
>>code below more :)
>>note: when you'll be done thinking or run out of ideas see my x86-64 
>>patches that i sent to ML this morning.
>>    
>>
>
>Without this patch, it crashes at the first instruction trying to access
>the BIOS.
>And your patch does not solve the problem:
>on a real PowerPC 64 machine, we can use the whole 64 bits virtual
>space.
>We agreed with Fabrice that there should be at least one more
>indirection in page mapping, because it would cost too much memory to
>try to map the whole needed memory space in one table, even if we can
>"forget" some of the middle bits in most cases.
>  
>
Ok, so far so good and I agree with that (I even had the third level of 
indirection implemented)...

>Then, you're right, this patch is ugly but allows not to crash until we
>have a correct solution with indirect tables to get a very large virtual
>space.
>
>  
>
... but read it once more. You're cutting up the "index", not "index >> 
L2_BITS".

- Filip

>>Index: exec.c
>>===================================================================
>>RCS file: /cvsroot/qemu/qemu/exec.c,v
>>retrieving revision 1.60
>>diff -u -d -w -B -b -d -p -r1.60 exec.c
>>--- exec.c    24 Apr 2005 18:02:38 -0000    1.60
>>+++ exec.c    20 Jul 2005 23:00:26 -0000
>>@@ -257,6 +257,10 @@ static inline VirtPageDesc *virt_page_fi
>> {
>>     VirtPageDesc *p;
>> 
>>+    /* XXX: should not truncate for 64 bit addresses */
>>+#if TARGET_LONG_BITS > 32
>>+    index &= (L1_SIZE - 1);
>>+#endif
>>     p = l1_virt_map[index >> L2_BITS];
>>     if (!p)
>>         return 0;
>>    
>>
>
>  
>

Re: [Qemu-devel] PowerPC64 and more

[Joe Batt]

On Fri, 2005-07-22 at 00:37 +0200, J. Mayer wrote:
> We agreed with Fabrice that there should be at least one more
> indirection in page mapping, because it would cost too much memory to
> try to map the whole needed memory space in one table, even if we can
> "forget" some of the middle bits in most cases.

I haven't had time to even look at the qemu code, but in my last
emulator, we found it was fastest to keep a sorted array of chunks of
memory instead of some sort of tree.

To fetch a chunk of memory, you would scan through the device list for a
chunk that covered that range and swap it with the previous chunk in the
list.  System RAM bubbled to the top and the control structures of a
particular timer that our real code used bubbled to the top.  Most
access is to system RAM, so there is only one indirection most of the
time.  We had a 15% speed improvement over using a hash table.
(disclaimer, we were implementing in Java, so array access is a bit slow
due to bounds checking.)

Knuth has a name for the data structure, but I don't remember what it
is.

-- 
Joe Batt <Joe@soliddesign.net>

Re: [Qemu-devel] PowerPC64 and more

[J. Mayer]

On Fri, 2005-07-22 at 00:58 +0200, Filip Navara wrote:
> J. Mayer wrote:
> 
> >On Fri, 2005-07-22 at 00:10 +0200, Filip Navara wrote:
> >  
> >
> >>J. Mayer wrote:

[...]
> >>wow, you repeated my and Fabrice's mistake once more ... think about the 
> >>code below more :)
> >>note: when you'll be done thinking or run out of ideas see my x86-64 
> >>patches that i sent to ML this morning.
> >
> >Without this patch, it crashes at the first instruction trying to access
> >the BIOS.
> >And your patch does not solve the problem:
> >on a real PowerPC 64 machine, we can use the whole 64 bits virtual
> >space.
> >We agreed with Fabrice that there should be at least one more
> >indirection in page mapping, because it would cost too much memory to
> >try to map the whole needed memory space in one table, even if we can
> >"forget" some of the middle bits in most cases.
> >  
> >
> Ok, so far so good and I agree with that (I even had the third level of 
> indirection implemented)...
> 
> >Then, you're right, this patch is ugly but allows not to crash until we
> >have a correct solution with indirect tables to get a very large virtual
> >space.
> >
> >  
> >
> ... but read it once more. You're cutting up the "index", not "index >> 
> L2_BITS".

In fact, I did not want to be too invasive outside of target-ppc
subdirectory.
Then I found that Fabrice did a patch in virt_page_find_alloc for x86_64
support
(a few lines above in the same file).
I have to admit I just duplicated this hack and it solved my crashes.
As the address that generated the crash was 0xFFFFFFFFFFFFFFFC (-4), I
just admitted
that it would prevent the crash for any address...
I even did not check if the mask was the right one, in fact...

[...]

-- 
J. Mayer <l_indien@magic.fr>
Never organized