3:18 p.m.
Hi Alex!
On Wed, Jul 20, 2016 at 11:47:35AM +0100, Alex Bradbury wrote:
On 10 July 2016 at 11:59, Reinoud Zandijk <reinoud(a)netbsd.org>
wrote:
> here my v5 proposal for review. Please do read and comment on it :)
Many thanks for sharing your design here. I wanted to summarise some things
that came to mind when reading it, and hopefully you can correct me if I
misunderstand
* In the second paragraph in detailed design, the requirement for a debug
bus is detailed. Presumably the argument is this is cheaper than context
switching previously described, and at least re-uses infrastructure that
would already be needed for debug?
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.
* Do I understand correctly that the hypervisor minion would use this
in
order to implement context switching between OSes on each CPU?
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.
* Having a boot minion seems very sensible
* Since this message, the revised privileged spec draft 1.9 was
released. Do
you have any thoughts on how this proposal might integrate with the RISC-V
PLIC design?
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.
In general, as we're seeing in the device-tree vs config-string
discussion I think there's a tension between doing things cleanly vs
doing them in a way that matches existing devices and allows maximal
code reuse. That said, the work Greg KH did with Greybus+Unipro
suggests to me it should be possible to 'tunnel' existing devices if
desired.
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.
I'll respond to your other thread with more thoughts about this,
but I
think a key challenge is working out how to move forwards with a
proposal like this. Would you, for instance, be interested in
prototyping something along these lines in Spike or qemu?
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