[Top][All Lists]

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

Re: [PATCH v7 2/2] target/s390x: support PRNO_TRNG instruction

From: Thomas Huth
Subject: Re: [PATCH v7 2/2] target/s390x: support PRNO_TRNG instruction
Date: Wed, 21 Sep 2022 12:59:16 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0

On 29/08/2022 18.29, Jason A. Donenfeld wrote:
On Fri, Aug 26, 2022 at 01:28:11PM +0200, Thomas Huth wrote:
+        qemu_guest_getrandom_nofail(tmp, block);
+        for (size_t i = 0; i < block; ++i) {
+            cpu_stb_data_ra(env, wrap_address(env, *buf_reg), tmp[i], ra);
+            *buf_reg = deposit64(*buf_reg, 0, message_reg_len, *buf_reg + 1);
+            --*len_reg;

I know it's annoying, but technically, you must not touch the upper bits of
the len_reg if running in 31- or 24-bit addressing mode. The Principles of
Operations say:

"In either the 24- or 31-bit addressing mode, bits 32-63 of the odd-numbered
register are decremented by the number
of bytes processed for the respective operand, and
bits 0-31 of the register remain unchanged."

This is what I was trying to do with the use of deposit64, following
David's guidance. Did I mess something up?

Sorry for not following up earlier - I've been away from keyboard for a couple of weeks...

Anyway, that was likely a wrong comment from my side anyway - I thought that "--*len_reg" might alter the upper bits, too, when there is no masking here. But since "len" has been constrained earlier in the function already, I think this cannot happen, so please never mind.

I just saw that you also sent a v8 now, so I'll follow up on that version.


reply via email to

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