On 26/09/2016 14:38, Bastian Koppelmann wrote: > On 09/26/2016 02:21 PM, Paolo Bonzini wrote: >> >> >> On 26/09/2016 12:56, Sagar Karandikar wrote: >>> +#ifndef CONFIG_USER_ONLY >>> +DEF_HELPER_4(csrrw, tl, env, tl, tl, tl) >>> +DEF_HELPER_5(csrrs, tl, env, tl, tl, tl, tl) >>> +DEF_HELPER_5(csrrc, tl, env, tl, tl, tl, tl) >>> +DEF_HELPER_2(sret, tl, env, tl) >>> +DEF_HELPER_2(mret, tl, env, tl) >>> +DEF_HELPER_1(tlb_flush, void, env) >>> +DEF_HELPER_1(fence_i, void, env) >>> +#endif /* !CONFIG_USER_ONLY */ >> >> The system emulation spec is still in flux, I think we should only add >> user-mode emulation for now. >> > > Hi Paolo, > > by user-mode emulation you still mean softmmu and not linux-user, right? > So just drop the system instructions for now.
I don't think that's possible; all RISC-V machines include at least M-mode, whose precise definitions requires the privileged interface specification which hasn't been finalized yet. So only linux-user is stable enough. In fact, based on some recent discussions on the RISC-V isa-dev mailing list, it looks like some memory protection features _beyond_ the privileged interface specification are in practice required to secure M-mode from the supervisor. I'm not sure what's the point in defining a separate mandatory M-mode (supervisor mode cannot even enable paging without help from M-mode, on the other hand a processor that only has M- and U-modes cannot enable paging) but not providing the tools to actually enforce privilege separation for it. All in all, while I'm happy that the RISC-V project uses QEMU for development, I don't think that the privileged interface specification is mature enough for inclusion in QEMU. It's very different for linux-user user-mode emulation of course, it's great to have that upstream. Thanks, Paolo
