qemu-arm
[Top][All Lists]
Advanced

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

Re: [PATCH] pl031: Expose RTCICR as proper WC register


From: Alexander Graf
Subject: Re: [PATCH] pl031: Expose RTCICR as proper WC register
Date: Tue, 12 Nov 2019 09:28:40 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.1

Hey Peter,

On 08.11.19 17:58, Peter Maydell wrote:
On Mon, 4 Nov 2019 at 11:52, Alexander Graf <address@hidden> wrote:

The current pl031 RTCICR register implementation always clears the IRQ
pending status on a register write, regardless of the value it writes.

To justify that behavior, it references the arm926e documentation
(DDI0287B) and indicates that said document states that any write clears
the internal IRQ state. I could however not find any text in that document
backing the statement. In fact, it explicitly says:

   "Writing 1 to bit 0 of RTCICR clears the RTCINTR flag."

which describes it as much as a write-to-clear register as the PL031 spec
(DDI0224) does:

   "Writing 1 to bit position 0 clears the corresponding interrupt.
    Writing 0 has no effect."

DDI0287B page 11-2 section 11.1 says
"The interrupt is cleared by writing any data value to the
interrupt clear register RTCICR". As you note, this contradicts
what it says later on in section 11.2.2.

(Interestingly, the PL030 does have a "write any value to
clear the interrupt" register, RTCEOI.)

I'm fairly sure this patch is right and the DDI0287B document
has an error, since it isn't internally consistent and doesn't
match the proper PL031 TRM.

Did you find this because you had a guest that assumed the
other behaviour? This bug has been in QEMU for a very long time,
and it seems odd for a guest to deliberately perform an action
(writing 0) which is documented to have no effect on the device...

We found this bug by trying to find justification for the behavior in the spec and apparently my spec reading skills were lacking. I could not find the reference you cited above.

So no, I did not see any guest breakage.

I still think that being consistent with the actual PL031 spec is preferable though. If any real world guest breaks because of this, we can still revert this patch and document the exact breakage in the comment instead.


Alex



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



reply via email to

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