qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH] s390x-linux-user


From: Paul Brook
Subject: Re: [Qemu-devel] [RFC PATCH] s390x-linux-user
Date: Fri, 26 Jun 2009 20:24:30 +0100
User-agent: KMail/1.11.4 (Linux/2.6.29-2-amd64; KDE/4.2.4; x86_64; ; )

> Stupid idea, I expect, but would it be possible to handle EXECUTE by
> 'branching' to the 'instruction stored somewhere in memory', using one
> bit to hold the state of R0, and another indicate that the TB is a
> special EXECUTE TB (i.e. only a single instruction should be decoded,
> the LSB of R0 should be ORed, and code must be generated to return to
> the 'caller'), and another bit for the state of the LSB of R0?

I guess s/bit/byte/.

> Presumably, SMC handling would safely deal with the memory holding that
> instruction being written to.  (If all variants of S/390 need precise
> SMC handling, I suppose that shouldn't be a problem?)

You don't need precise SMC here. That's only required if a TB can modify 
itself.

> My only real concern would be that it must not be possible to observe
> this behaviour.  (I.e. an interrupt arriving at the 'wrong' moment or
> the EXECUTEd instruction faulting must be properly handled.)

That's easy to fix. We already do this for other targets (e.g. ARMv7-M 
exception return). You already need an extra TB flag bit to indicate that this 
is part way through an EXECUTE instruction.

> Also, if S/390 has separate read/execute page bits, would access to the
> memory location in question still count as 'execution'?  I suppose this
> would also be possible to work around, though...

This is probably the trickiest bit to get right, especially if the you end up 
causing a fault.

Paul




reply via email to

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