Hi Peter, Good to hear from you. We have been ignoring the user/supervisor mode privileges for quite some time now, so I think it's time to put some pressure on this. What you propose sounds sensible to me, so it would be great to have this outlined on the wiki, especially as orconf2013 is coming up in a few weeks, and we might have some time to discuss it in detail there.
Regards, Olof Kindgren On Tue, Sep 17, 2013 at 3:09 AM, Peter Gavin <[email protected]> wrote: > Hello, > > I know it's been a while since I've been on the list, but I have a few > thoughts about exceptions and SPRs that I wanted to discuss. There are some > inconsistencies in the manual, and some other things that are unclear. And > as has been raised before, there are some problems that may get in the way > of virtualization, and I have a few things I'd like to suggest that could > be changed in the manual. > > In short, I think we should actually *use* the definition of "privileged" > as given on page 15 of the manual (section 1.6). It is defined, but never > used in the manual, from what I've found. Additionally, I think we should > raise an exception whenever a privileged instruction has been executed > while in user mode. For example, the l.rfe instruction should always raise > this exception when executed in user mode. Additionally, in user mode, an > attempt to read or write an SPR that is not permitted as indicated on Table > 4-2 of the manual should raise this exception. > > Our list of privileged instructions would be very short. l.rfe would > always be privileged. It seems to me that allowing this instruction from > user mode makes little sense, and could, in fact, be dangerous. l.mtspr > would be privileged whenever the address does not have a W in the "user > mode" column of table 4-2, and l.mfspr would be privileged whenever the > address does not have an R in that column. The descriptions for these > instructions would need to be changed to indicate that they may cause > exceptions; it currently says that they do not. > > The idea with virtualization is to run the virtualized operating system's > kernel in user mode. Any non-privileged instructions executed by the guest > operating system run normally, and so must behave identically no matter the > current privilege mode. Privileged instructions need to be emulated by the > host operating system. In order to do this with without translating the > binary, it is necessary that these instructions notify the host by raising > an exception. I would like to facilitate this by creating a new > "privileged instruction" exception that is raised in this case, but the > illegal instruction exception is sufficient, as in any case, the host OS > must interpret the instruction in order to determine how to proceed. > > Incidentally, some bits in the SR register (F, CY, OV) are not accessible > from user mode, and so these bits should be mirrored in a separate SPR that > is R/W from user mode. > > Also incidentally, I also think l.mtspr/l.mfspr on an unimplemented > register should raise an illegal instruction exception. The presence of > SPRs that are optional should be indicated by a bit in the UPR, and so this > should be checked prior to accessing them. However, the behavior currently > defined by the standard is not a problem for virtualization, as far as I > can tell, provided that l.mtspr/l.mfspr behave identically on unimplemented > registers whether in user or supervisor mode. > > Any thoughts? Unless there are objections, I'd like to place these > suggestions on the wiki. > > Thanks, > -Pete > > > _______________________________________________ > OpenRISC mailing list > [email protected] > http://lists.openrisc.net/listinfo/openrisc > >
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
