Re: [Qemu-devel] [PATCH 04/10] mips-linux-user: Save and restore fpu and dsp from sigcontext

[Richard Henderson]

On 2013-02-11 09:28, Peter Maydell wrote:
> Since this code is writing to a region of memory which it
> has obtained via lock_user_struct(), __put_user() is
> guaranteed not to fail. So you might as well not worry
> about its return code. MIPS setup_rt_frame() is already
> written in this style, for instance.
>
> If you're trying to write to a region of memory which isn't
> in the frame struct (which I don't think you are here)
> then defining DEBUG_REMAP will probably break things :-)

I suppose such a cleanup should be in a separate patch,
probably right before this one...

> > -    /* 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.

I'm deleting kernel code that's been cut-and-pasted into here
and then commented out.

> 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...


r~