qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] target-s390x: fix LOAD MULTIPLE instruction on


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH] target-s390x: fix LOAD MULTIPLE instruction on page boundary
Date: Mon, 25 May 2015 22:47:31 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0


On 23.05.15 21:33, Richard Henderson wrote:
> On 05/23/2015 12:59 AM, Aurelien Jarno wrote:
>> On 2015-05-21 14:42, Richard Henderson wrote:
>>> Hmm.  Seems to be un/under-specified in the PoO.  That said,
>>
>> There is a small sentence in the PoO, in chapter "Program Execution",
>> section "Sequence of Storage Reference":
>>
>>    It can normally be assumed that the execution of
>>    each instruction occurs as an indivisible event.
> 
> Ah, I didn't think to look in a different chapter.  ;-)
> 
>>> It would be nice to know if there ought to be similar up-front access
>>> checking
>>> for STM, to avoid errant partial stores.
>>
>> I have just checked, the same is also true for STM instructions, though
>> it's probably more difficult to fix that in QEMU. Maybe we need a way to
>> check if a load/store will succeed, preferably without using a helper.
> 
> I did just suggest a new helper in the "unaligned stores for mips r6"
> thread. Therein we provide a probe_write helper that does assert that
> the given page is writable, or raise the usual exception.  It leaves the
> TLB updated, so a subsequent write should take the fast path.
> 
> It should be easy enough to extend that with an opcode so that we can
> implement this for s390 as
> 
>     probe_write    addr + n * size - 1
>     qemu_st        r0, addr
>     qemu_st        r1, addr + 1*size
>     ...
> 
> Hopefully for the edge case where both pages are unmapped, producing an
> exception pointing to the last byte, rather than the first byte, is
> acceptable.

So that means we should hold off on this patch for now as well and
rather go for the probe approach?


Alex



reply via email to

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