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
_______________________________________________
OpenRISC mailing list
[email protected]
http://lists.openrisc.net/listinfo/openrisc

Reply via email to