On Sun, Dec 2, 2012 at 6:44 PM, Julius Baxter <[email protected]> wrote: > 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
Clearly, you are going to do what you want to do. I just wanted to point-out that this change will make implementing a hypervisor more difficult and less efficient. ---Matthew Hicks _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
