On 10.07.2016 12:59, Reinoud Zandijk wrote: Hi Reinoud, I read the proposal and try to associate it with what is going on for RISC-V run-control debugging. Did you consider Tim's debug ROM proposal as part of your proposal? Unfortuantely, I have a few problems putting stuff together in my head. Do you by chance have some figures that can be used as reference? Cheers, Stefan

On 28.07.2016 22:43, Reinoud Zandijk wrote: Thanks! Yes, thanks. Cheers, Stefan

Hi Alex! On Wed, Jul 20, 2016 at 11:47:35AM +0100, Alex Bradbury wrote: Traditional hypervisor context switching or Tims debug ROM needs code to run on the actual CPU itself; that I try to avoid all together since this will always hinge on assumptions of behaviour and does have security issue too. The actual speed of switching depends of course on how much help the hypervisor Minion gets with bits that indicate what registers are dirty or if there is even a lazy load possible. In the worst case scenario it shouldn't matter much in speed. Well between domains that are normally OSes yes but could also be an encryption device or some other `soft' hardware like an emulated or multiplexed display or whatever that runs outside the OS. I haven't dug into the PLIC design yet enough to answer this in detail. From memory, the PLIC would then be hypervisor Minion only since each OS/domain would otherwise need to have its own emulated PLIC since they are not aware of other users. My current proposal allows up to (at least) 64 interrupt levels. Each OS/domain can place a device at the level it wants them and ignore lower ones by using the masking. Some hardware support might be handy though to ensure that the CPUs with the lowest interrupt level takes the hit but otherwise the masks will allow for each CPU to have a interrupt level. Interrupt routing and handling is of course not trivial and is still kind of a work in progress. It would be good if it would be possible to tweak the mechanism on a finished SoC. If some mechanism indeed turns out to be preferable and some hardware support is handy, the interface won't change; only the code of the hypervisor Minion needs tweaking to cater for the extra hardware support. I agree that code reuse is a good thing but at what cost? We're trying to design something that will last for a long time with multiple generations right? Things change a lot in say 10 or 20 years. Entire devices families come and go, CPUs architectures and busses even come and go. Nothing is as volatile as code, configuration methods, boot methods like LILO, grub, grub2, uBoot, multiboot, PXE etc. Most of the current code base for devices of say Linux or one of the BSDs hasn't been around for that long. Its extended every day and at times rototilled even. A quick bring up is more dependent on ease of programming by a good design and good specs than on using `standard' chips inside. Lots of ARM SoCs for example have a kind of `standard' USB controller; but there are dozens of variations of it that are JUST that bit different, just that connected different, with just that few power and codec setup differences that makes it doesn't work. Thats bringing up a port so difficult and time consuming. Sure, I'd love to. It shouldn't be that hard in Spike; provided that I can create subclasses for say Application CPUs and Minion CPUs. I could also just emulate everything outside the Application CPUs, with some timed delays even ;) Talking about gcc, Spike and Chissel, are they now OK to build and run on a 32 bit platform? How is the state of LLVM? Can it finally compile stuff on its own now i.e. be used without dependencies on gcc tools or libraries? All the best, Reinoud