Ok, I've added the things already described to the wiki. I have a few other concerns:
The manual requires that the ESR register be initialized to zero on reset. Some of the bits in SR are immutable, or reserved, such as the FO bit, for example. Should it be possible to set the ESR bit in the FO position to zero? Or is it possible to remove the storage for this ESR bit, and fix it to one in ESR as well? It seems like only the relevant bits in SR should be storable in ESR, and any bits that are ignored or are fixed should be able to be ignored. Similarly, can the least significant 2 bits of the EPCR register be fixed to zero? Why is the PPC register writable according to table 4-2? What happens when it's written to? What happens when a misaligned address is written to the NPC register? Does this trigger an alignment exception? Sorry if this has been discussed before. If it has, I missed it :) -Pete On Tue, Sep 17, 2013 at 5:32 AM, Olof Kindgren <[email protected]>wrote: > 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
