Re: [Qemu-devel] [PATCH v3 15/18] target/s390x: Implement SRSTU

[David Hildenbrand <david@redhat.com>]

> Apart from special wrapping conditions, looks good to me!
> 
> (will scan the PoP how wrapping is to be handled in general during an
> instruction. Some (like mvcos) mention it explicitly, others don't)
> 

Answering my own questions:

1. We always have to wrap addresses that we generate except in some
special cases:

(PoP page 3-7)

"
The CPU performs address generation when it forms
an operand or instruction address or when it gener-
ates the address of a table entry from the appropriate
table origin and index. It also performs address gen-
eration when it increments an address to access suc-
cessive bytes of a field.

When, during the generation of the address, an
address is obtained that exceeds the value allowed
[...] one of the following two actions is taken:

 1. The carry out of the high-order bit position of the
    address is ignored. This handling of an address
    of excessive size is called wraparound.
 2. An interruption condition is recognized.

[...]

Addresses generated by the CPU that may be virtual
addresses always wrap."

... reading the following table, interrupts seem to get generated only
for some iplicit DAT translations/AR-mode tables and authority tables,
and only when Real or Absolute addresses are to be used.

So wrapping all addresses is done in general when working with virtual
addresses, whenever we generate an address.


2. We must not overwrite bit 0-31 in 24/31 bit mode:

(PoP page 3-6)
Unless specifically stated to the contrary, the follow-
ing definition applies in this publication: whenever the
machine generates and provides to the program a
24-bit or 31-bit address, the address is made avail-
able (placed in storage or loaded into a general regis-
ter) by being imbedded in a 32-bit field, with the
leftmost eight bits or one bit in the field, respectively,
set to zeros. When the address is loaded into a gen-
eral register, bits 0-31 of the register remain
unchanged.


-- 

Thanks,

David