[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] target-s390x: fix LOAD MULTIPLE instruction on
Re: [Qemu-devel] [PATCH] target-s390x: fix LOAD MULTIPLE instruction on page boundary
Mon, 25 May 2015 23:05:16 +0200
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
> >>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
Worst case we can probe the first address and then the last address.
Aurelien Jarno GPG: 4096R/1DDD8C9B
Re: [Qemu-devel] [PATCH] target-s390x: fix LOAD MULTIPLE instruction on page boundary, Alexander Graf, 2015/05/21