Re: [Qemu-devel] [PATCH 00/24] Alpha system emulation, v2
On Apr 20, 2011, at 5:54 PM, Richard Henderson wrote: On 04/20/2011 08:46 AM, Tristan Gingold wrote: Right, but you could create an ev67 machine with a single PCI controller (or put all the devices on the same PCI controller). Even the lowly ds10 has two hoses. I'll admit I hadn't considered engineering the second hose to be present but always appear empty. It's something to consider. Ah, ok I understand. I fear that if you implement your own ISR, you will only be able to boot linux... which I suppose is your primary target. OTOH, it will be much faster than a native ISR. Yes, Linux is the primary goal. But I suspect that if I implemented enough of CALL_PAL CSERVE, you could boot Tru64, or at least one of the BSDs. BSD should be doable, but I doubt for Tru64. Do you have technical doc about the SRM ? IIRC, the SRM uses its own palcode and SRM specific pal calls. Tristan.
Re: [Qemu-devel] [PATCH 00/24] Alpha system emulation, v2
On Thu, 2011-04-21 at 14:31 +0200, Tristan Gingold wrote: On Apr 20, 2011, at 5:54 PM, Richard Henderson wrote: On 04/20/2011 08:46 AM, Tristan Gingold wrote: Right, but you could create an ev67 machine with a single PCI controller (or put all the devices on the same PCI controller). Even the lowly ds10 has two hoses. I'll admit I hadn't considered engineering the second hose to be present but always appear empty. It's something to consider. Ah, ok I understand. I fear that if you implement your own ISR, you will only be able to boot linux... which I suppose is your primary target. OTOH, it will be much faster than a native ISR. Yes, Linux is the primary goal. But I suspect that if I implemented enough of CALL_PAL CSERVE, you could boot Tru64, or at least one of the BSDs. BSD should be doable, but I doubt for Tru64. Do you have technical doc about the SRM ? IIRC, the SRM uses its own palcode and SRM specific pal calls. The palcode with milo was a subset of the tru64 palcode, I think. Looking at the arch reference manual and assuming that the calls take the same parameters, the only difference is that tru64 has urti - return from user mode trap and linux doesn't.
Re: [Qemu-devel] [PATCH 00/24] Alpha system emulation, v2
On Apr 21, 2011, at 3:37 PM, Brian Wheeler wrote: On Thu, 2011-04-21 at 14:31 +0200, Tristan Gingold wrote: On Apr 20, 2011, at 5:54 PM, Richard Henderson wrote: On 04/20/2011 08:46 AM, Tristan Gingold wrote: Right, but you could create an ev67 machine with a single PCI controller (or put all the devices on the same PCI controller). Even the lowly ds10 has two hoses. I'll admit I hadn't considered engineering the second hose to be present but always appear empty. It's something to consider. Ah, ok I understand. I fear that if you implement your own ISR, you will only be able to boot linux... which I suppose is your primary target. OTOH, it will be much faster than a native ISR. Yes, Linux is the primary goal. But I suspect that if I implemented enough of CALL_PAL CSERVE, you could boot Tru64, or at least one of the BSDs. BSD should be doable, but I doubt for Tru64. Do you have technical doc about the SRM ? IIRC, the SRM uses its own palcode and SRM specific pal calls. The palcode with milo was a subset of the tru64 palcode, I think. Looking at the arch reference manual and assuming that the calls take the same parameters, the only difference is that tru64 has urti - return from user mode trap and linux doesn't. Yes, Linux runs on Tru64 palcode. But the issue is booting the Tru64 kernel. Tristan.
Re: [Qemu-devel] [PATCH 00/24] Alpha system emulation, v2
On Thu, 2011-04-21 at 15:43 +0200, Tristan Gingold wrote: On Apr 21, 2011, at 3:37 PM, Brian Wheeler wrote: On Thu, 2011-04-21 at 14:31 +0200, Tristan Gingold wrote: On Apr 20, 2011, at 5:54 PM, Richard Henderson wrote: On 04/20/2011 08:46 AM, Tristan Gingold wrote: Right, but you could create an ev67 machine with a single PCI controller (or put all the devices on the same PCI controller). Even the lowly ds10 has two hoses. I'll admit I hadn't considered engineering the second hose to be present but always appear empty. It's something to consider. Ah, ok I understand. I fear that if you implement your own ISR, you will only be able to boot linux... which I suppose is your primary target. OTOH, it will be much faster than a native ISR. Yes, Linux is the primary goal. But I suspect that if I implemented enough of CALL_PAL CSERVE, you could boot Tru64, or at least one of the BSDs. BSD should be doable, but I doubt for Tru64. Do you have technical doc about the SRM ? IIRC, the SRM uses its own palcode and SRM specific pal calls. The palcode with milo was a subset of the tru64 palcode, I think. Looking at the arch reference manual and assuming that the calls take the same parameters, the only difference is that tru64 has urti - return from user mode trap and linux doesn't. Yes, Linux runs on Tru64 palcode. But the issue is booting the Tru64 kernel. Tristan. Ah, gotcha. It almost seems like the console could actually be implemented in qemu itself, rather than a guest side thing, as long as it looks like part III of the ARM :) It might simplify things quite a bit: the console callbacks look like they can be translated into qemu calls and the bootstrapping looks like its a read block zero of selected device + other blocks specified, setup hwrpb and start emulation. It looks like its standard across all OSes, with the possible exception of NT. *shrug* I'm just an innocent bystander, though.
Re: [Qemu-devel] [PATCH 00/24] Alpha system emulation, v2
On 04/21/2011 07:48 AM, Brian Wheeler wrote: On Thu, 2011-04-21 at 15:43 +0200, Tristan Gingold wrote: On Apr 21, 2011, at 3:37 PM, Brian Wheeler wrote: On Thu, 2011-04-21 at 14:31 +0200, Tristan Gingold wrote: On Apr 20, 2011, at 5:54 PM, Richard Henderson wrote: On 04/20/2011 08:46 AM, Tristan Gingold wrote: BSD should be doable, but I doubt for Tru64. Do you have technical doc about the SRM ? IIRC, the SRM uses its own palcode and SRM specific pal calls. IIRC the main thing that was lacking between SRM and the Evaluation Board PALcode that was used in MILO is the Console Callback (CCB) structure and routines. Ah, gotcha. It almost seems like the console could actually be implemented in qemu itself, rather than a guest side thing, as long as it looks like part III of the ARM :) My first try last year was going down this path. It turned out to be irritatingly difficult to manage the data setup inside QEMU itself. Thus I came to be writing a custom PALcode image that makes a number of simplifying assumptions based on the ability to off-load some work to QEMU. r~
Re: [Qemu-devel] [PATCH 00/24] Alpha system emulation, v2
On Apr 19, 2011, at 5:04 PM, Richard Henderson wrote: Changes from v1 to v2: - Split patch 5 up into little pieces. These pieces were compile tested by applying patch 23 (Enable alpha-softmmu) out of sequence so that both softmmu and linux-user targets were built. But in the end I chickened out and re-ordered the enable patch to last. - The TB-FLAGS patch is more comprehensive. In doing the split I noticed that we were doing funny things with AMASK that really ought to have belonged in the TB in the first place. - The patch for unassigned addresses is more comprehensive. I had previously failed to do the if-deffing dance in the generic part of QEMU. - The PALcode source is added as a submodule. Richard, it looks like I miss the v1. Anyway, some random comments: * thank you for working on that! * sx164 is ev56 based, isn't it ? It would be nice if cpu version specific code is clearly marked. In particular (and IIRC), pal mode for ev6 is much closer to ev4 than to ev5. Don't know about ev7. It would be nice if we could easily support both ev5 and ev6. * Yes, executive and supervisor are used only by VMS (well AFAIK). I'd like to support it. Did you try to also support the windows mmu mode ? * Again, thank you for working on that. Tristan.
Re: [Qemu-devel] [PATCH 00/24] Alpha system emulation, v2
I'd like to second Tristan in saying that I'm glad someone is working on alpha system emulation -- its long overdue! Brian On Wed, 2011-04-20 at 11:06 +0200, Tristan Gingold wrote: On Apr 19, 2011, at 5:04 PM, Richard Henderson wrote: Changes from v1 to v2: - Split patch 5 up into little pieces. These pieces were compile tested by applying patch 23 (Enable alpha-softmmu) out of sequence so that both softmmu and linux-user targets were built. But in the end I chickened out and re-ordered the enable patch to last. - The TB-FLAGS patch is more comprehensive. In doing the split I noticed that we were doing funny things with AMASK that really ought to have belonged in the TB in the first place. - The patch for unassigned addresses is more comprehensive. I had previously failed to do the if-deffing dance in the generic part of QEMU. - The PALcode source is added as a submodule. Richard, it looks like I miss the v1. Anyway, some random comments: * thank you for working on that! * sx164 is ev56 based, isn't it ? It would be nice if cpu version specific code is clearly marked. In particular (and IIRC), pal mode for ev6 is much closer to ev4 than to ev5. Don't know about ev7. It would be nice if we could easily support both ev5 and ev6. * Yes, executive and supervisor are used only by VMS (well AFAIK). I'd like to support it. Did you try to also support the windows mmu mode ? * Again, thank you for working on that. Tristan.
Re: [Qemu-devel] [PATCH 00/24] Alpha system emulation, v2
On 04/20/2011 02:06 AM, Tristan Gingold wrote: * sx164 is ev56 based, isn't it ? It would be nice if cpu version specific code is clearly marked. Yes, but most importantly it is the most evolved of the single hose systems. QEMU is nowhere near ready to deal with multiple PCI host controllers, and multiple ISA buses. I actually planned on emulating an EV67 but using the SX164 HW. I think the Linux kernel will be that forgiving... In particular (and IIRC), pal mode for ev6 is much closer to ev4 than to ev5. Don't know about ev7. It would be nice if we could easily support both ev5 and ev6. Ah, see, here's where there may be some confusion... I'm not implementing any of the real cpu ISRs. I'm not using any of the real PALcode. I'm implementing my own QEMU-specific ISRs and and writing my own PALcode, starting with MILO's PALcode but I've diverged significantly since. I'm also cheating a bit and implementing a number of the simple CALL_PALs inline in QEMU. But that really started when I discovered how confused gdb could get attempting to step across a transition to/from PALmode. * Yes, executive and supervisor are used only by VMS (well AFAIK). I'd like to support it. Well, if you'd like to help write the PALcode for VMS, sure. It certainly looks like a larger job than the Unix PALcode. Did you try to also support the windows mmu mode ? Nope. I can't really imagine that being of interest to anyone. r~
Re: [Qemu-devel] [PATCH 00/24] Alpha system emulation, v2
On Apr 20, 2011, at 4:46 PM, Richard Henderson wrote: On 04/20/2011 02:06 AM, Tristan Gingold wrote: * sx164 is ev56 based, isn't it ? It would be nice if cpu version specific code is clearly marked. Yes, but most importantly it is the most evolved of the single hose systems. QEMU is nowhere near ready to deal with multiple PCI host controllers, and multiple ISA buses. Right, but you could create an ev67 machine with a single PCI controller (or put all the devices on the same PCI controller). I actually planned on emulating an EV67 but using the SX164 HW. I think the Linux kernel will be that forgiving... In particular (and IIRC), pal mode for ev6 is much closer to ev4 than to ev5. Don't know about ev7. It would be nice if we could easily support both ev5 and ev6. Ah, see, here's where there may be some confusion... I'm not implementing any of the real cpu ISRs. I'm not using any of the real PALcode. I'm implementing my own QEMU-specific ISRs and and writing my own PALcode, starting with MILO's PALcode but I've diverged significantly since. Ah, ok I understand. I fear that if you implement your own ISR, you will only be able to boot linux... which I suppose is your primary target. OTOH, it will be much faster than a native ISR. Tristan.
Re: [Qemu-devel] [PATCH 00/24] Alpha system emulation, v2
On 04/20/2011 08:46 AM, Tristan Gingold wrote: Right, but you could create an ev67 machine with a single PCI controller (or put all the devices on the same PCI controller). Even the lowly ds10 has two hoses. I'll admit I hadn't considered engineering the second hose to be present but always appear empty. It's something to consider. Ah, ok I understand. I fear that if you implement your own ISR, you will only be able to boot linux... which I suppose is your primary target. OTOH, it will be much faster than a native ISR. Yes, Linux is the primary goal. But I suspect that if I implemented enough of CALL_PAL CSERVE, you could boot Tru64, or at least one of the BSDs. r~
[Qemu-devel] [PATCH 00/24] Alpha system emulation, v2
Changes from v1 to v2: - Split patch 5 up into little pieces. These pieces were compile tested by applying patch 23 (Enable alpha-softmmu) out of sequence so that both softmmu and linux-user targets were built. But in the end I chickened out and re-ordered the enable patch to last. - The TB-FLAGS patch is more comprehensive. In doing the split I noticed that we were doing funny things with AMASK that really ought to have belonged in the TB in the first place. - The patch for unassigned addresses is more comprehensive. I had previously failed to do the if-deffing dance in the generic part of QEMU. - The PALcode source is added as a submodule. r~ Richard Henderson (24): Export the unassigned_mem read/write functions. target-alpha: Disassemble EV6 PALcode instructions. pci: Export pci_to_cpu_addr. target-alpha: Remove partial support for palcode emulation. target-alpha: Tidy exception constants. target-alpha: Rationalize internal processor registers. target-alpha: Cleanup MMU modes. target-alpha: Fixup translation of PALmode instructions. target-alpha: Add IPRs to be used by the emulation PALcode. target-alpha: Tidy up arithmetic exceptions. target-alpha: Merge HW_REI and HW_RET implementations. target-alpha: Implement do_interrupt for system mode. target-alpha: Swap shadow registers moving to/from PALmode. target-alpha: Add various symbolic constants. target-alpha: All ISA checks to use TB-FLAGS. target-alpha: Disable interrupts properly. target-alpha: Implement more CALL_PAL values inline. target-alpha: Add custom PALcode image for SX164 emulation. target-alpha: Implement cpu_alpha_handle_mmu_fault for system mode. target-alpha: Trap for unassigned and unaligned addresses. target-alpha: Include the PCC_OFS in the RPCC return value. target-alpha: Implement TLB flush primitives. target-alpha: Enable the alpha-softmmu target. target-alpha: Add SX164 emulation. .gitmodules |3 + Makefile |3 +- Makefile.target |4 +- alpha-dis.c |4 - configure |3 +- cpu-common.h |7 + cpu-exec.c| 16 +- default-configs/alpha-softmmu.mak |9 + dis-asm.h |3 + disas.c |2 +- exec-all.h|2 +- exec.c| 24 +- hw/alpha_palcode.c| 1048 hw/alpha_pci.c| 327 hw/alpha_pyxis.c | 1057 + hw/alpha_sx164.c | 195 +++ hw/alpha_sys.h| 41 ++ hw/pci.c |3 +- hw/pci.h |1 + linux-user/main.c | 49 +-- pc-bios/palcode-sx164 | Bin 0 - 107621 bytes roms/qemu-palcode |1 + target-alpha/cpu.h| 363 ++ target-alpha/exec.h |7 +- target-alpha/helper.c | 581 + target-alpha/helper.h | 32 +- target-alpha/machine.c| 87 +++ target-alpha/op_helper.c | 236 - target-alpha/translate.c | 771 29 files changed, 2734 insertions(+), 2145 deletions(-) create mode 100644 default-configs/alpha-softmmu.mak delete mode 100644 hw/alpha_palcode.c create mode 100644 hw/alpha_pci.c create mode 100644 hw/alpha_pyxis.c create mode 100644 hw/alpha_sx164.c create mode 100644 hw/alpha_sys.h create mode 100644 pc-bios/palcode-sx164 create mode 16 roms/qemu-palcode create mode 100644 target-alpha/machine.c -- 1.7.3.4
