qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 04/10] mips-linux-user: Save and restore fpu and dsp from sigcontext
Date: Mon, 11 Feb 2013 17:55:03 +0000

On 11 February 2013 17:43, Richard Henderson <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]