On Mon, Dec 3, 2012 at 12:26 AM, Matthew Hicks <[email protected]> wrote: > On Sun, Dec 2, 2012 at 6:12 PM, Julius Baxter <[email protected]> wrote: >> On Sun, Dec 2, 2012 at 9:38 PM, Matthew Hicks <[email protected]> wrote: >>> On Sun, Dec 2, 2012 at 12:11 PM, Julius Baxter <[email protected]> >>> wrote: >>>> Hi all >>>> >>>> I'm preparing what will hopefully be a pretty final draft for the 1.0 >>>> spec release. I have come up with a few more points I wouldn't mind >>>> getting comment on. >>>> >>>> 1. Accessing SPRs with insufficient privileges >>>> >>>> I reckon accessing SPRs which are only accessible in supervisor mode, >>>> while in user mode, should basically do nothing - writing should >>>> behave like a l.nop and reading should return zero, as if the SPR is >>>> unimplemented. >>> >>> This is a bad idea. You want to make the processor fully >>> virtualizable. This requires the ability for a hypervisor to >>> interpose on an unmodified operating system. For this to work, the >>> hypervisor changes the operating system privilege to 0 (user mode) and >>> when the operating system accesses or modifies privileged state, an >>> exception triggers and the hypervisor takes over. With your proposal, >>> the hypervisor would never know and the system would collapse. >>> >>> I suggest using a illegal instruction exception. In general, I am not >>> of fan of hardware imposed failure oblivious computing. That is a >>> choice software should make. >> >> Hi Matthew, >> >> I am a fan of getting this architecture spec update done, and it looks >> like this particular suggestion has resulted in more questions than >> answers. It seems that we could have a useful feature such as trapping >> all unprivileged accesses to SPRs, but I'd rather not delay this set >> of updates for us to flesh it out, because it's not critical. A lot of >> the other fixes, however, are. So here's what I propose - we leave it >> out of this draft, but perhaps mention that it is undefined and >> implementation-dependent. At a later point, we can easily define the >> sort of behaviour you suggest once it's been fully thought through and >> we're convinced there's a need for this. >> >> Cheers >> >> Julius > > What is the rush? I think it is better to take the time to do it in a > well thought out manner the first time, then to do it quickly and > later have to add a special SPR bit somewhere that requires both > hardware and software support to accommodate systems written to the > first, hastily done spec.
We have had a bunch of work go into suggestions for fixes and updates to the spec, and it's a process which started in April, see the page on the wiki: http://opencores.org/or1k/Architecture_Specification#Proposed_changes Half the point of this is to future proof the architecture and implementations with version and feature-present registers. There's already a few other issues which we won't support in this round of the spec (atomic instructions, for instance, we haven't fully decided on) but those amendments which are no-brainers or have already been thought through and discussed on the mailing list are going in. One of the main reasons I want to get the spec update out as soon as possible (and remember, it's all set up so we can future versions of the spec and easily track whether implementations support newly added features!) is so that we can get to work on the implementations and give them the basic version tracking registers so we can do a release of them all. Once they have the new version and feature-tracking system, it'll be easy to tell what is supported and what isn't. This is probably the thing we need to do the most, and I'm not delaying that for anything else. I was initially intending to do only that, but there were, as I said, some things which have already been discussed over the last 6 months and I think everyone is happy with. So, please, go to that wiki page, submit a proposal, we can discuss it, but it's not going into this round of the architecture spec. There will be another opportunity, certainly. Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
