On Mon, Dec 3, 2012 at 1:13 AM, Matthew Hicks <[email protected]> wrote: > 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.
Sure, your input is welcome, thanks for pointing this out. All I want to do is fix up the deficiencies we have known about for years, and make the architecture capable of being evolved as people have good ideas. My intention in this case is to just say _something_ about the unprivileged SPR access, rather than nothing. There's holes like this all through the spec, and it's better to acknowledge that it's not defined yet than say nothing at all. This is also something that isn't exactly top of the list of features to support, so I'm not going to delay the spec release for an 11th hour suggestion of this kind. So, as I said, someone put together a suggestion on the wiki and we'll go from there. Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
