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: Aurelien Jarno
Subject: Re: [Qemu-devel] [PATCH] target-s390x: fix LOAD MULTIPLE instruction on page boundary
Date: Mon, 25 May 2015 23:05:16 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

On 2015-05-23 12: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.

I guess it would work for softmmu, but not in linux-user mode, though
that's even more a corner case.

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

Worst case we can probe the first address and then the last address.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
address@hidden                 http://www.aurel32.net



reply via email to

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