On 30 October 2015 at 21:32, Peter Crosthwaite <crosthwaitepe...@gmail.com> wrote: > On Fri, Oct 30, 2015 at 2:10 PM, Peter Maydell <peter.mayd...@linaro.org> > wrote: >> This still confuses me. What I was expecting to see was something like: >> >> /* Monitor mode vector table; entry points which will only be reached >> * if the guest kernel is buggy are tight loops to avoid executing >> * random code by accident. The SMC vector entrypoint just returns, >> * making all SMC calls operate as NOPs. >> */ >> 0xwhatever, /* notused1: b notused1 */ >> 0xwhatever, /* notused2: b notused2 */ >> 0xwhatever, /* smc: movs pc, lr */ >> 0xwhatever, /* prefetch_abort: b prefetch_abort */ >> 0xwhatever, /* data_abort: b data_abort */ >> 0xwhatever, /* notused3: b notused3 */ >> 0xwhatever, /* irq: b irq */ >> 0xwhatever, /* fiq: b fiq */ > > I don't get the difference between notused and prefetch_abort etc. The > only one that is used is SMC. Which ones should tight loop and which > ones should nop? Do we actually have to branch somewhere or can we get > away with one-inst tight loop / nops as appropriate?
The only one which we need to have do something is the SMC entry point. None of the others will get called unless the guest manages to do something screwy. They're all just separate tight loops so if you look in the debugger and it says you're looping at 0x210 you know it was an unexpected prefetch abort rather than an unexpected irq or whatever. (The only way to get to the notused entries is literally to jump to them, incidentally, since the CPU itself won't use them as exception entrypoints.) We don't need to branch anywhere, since helpfully the ret insn for smc only takes one insn. The rest are all just branch-to-self. (If we did ever need more complicated smc handling then we could just have "smc: b smchandler" and put the smchandler after the vector table somewhere.) thanks -- PMM
