On 11 February 2013 17:43, Richard Henderson <r...@twiddle.net> wrote: >> On 2013-02-11 09:28, Peter Maydell wrote: >>> - /* flush_cache_sigtramp((unsigned long) tramp); */ >> >> >> So, what does cause any stale TB we might have happened to >> have lying around for this address to be flushed from the >> TB cache?
> The same way we handle all other self-modifying code: with > the read-only bit on pages for which we have TBs. OK. > I'm deleting kernel code that's been cut-and-pasted into here > and then commented out. Yeah; I couldn't remember the mechanism we used (ie whether we allowed stale code to hang around on guest architectures that require explicit cache flush after self modifying code). Having looked through the code you're right that we don't need to do anything. >> Unconditionally copying the DSP state fields into the signal >> context struct is OK, but is it really safe to copy whatever >> the guest provides us back into the CPU state fields even if >> there's no DSP? I think I'd prefer to see a cpu_has_dsp guard >> here. > > > I can't think of a reason it's not safe. We're not modifying > the env->CP0_Status field, so if the dsp is disabled it can't > be enabled by user fiddling. Again the comment about the data > just being garbage... The difference is that the guest signal ABI allows the stack frame space to be garbage, so we know it's safe. Whereas allowing the guest to write garbage into our CPU state struct means we have to be sure that there's nothing in target-mips/ which ever assumes "dsp state fields are zero in a non-dsp config because nothing will have written to them" or similar. More pithily, it's fine to feed other people garbage but we should be more cautious about eating it ourselves :-) -- PMM
