Path: ...!news.mixmin.net!news.neodome.net!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Microarchitectural support for counting
Date: Wed, 25 Dec 2024 20:26:05 +0000
Organization: Rocksolid Light
Message-ID: <c8c44d01b51e8b13ff5dc0548316bc80@www.novabbs.org>
References: <2024Oct3.160055@mips.complang.tuwien.ac.at> <vdmrk6$3rksr$1@dont-email.me> <LyELO.69485$2nv5.62232@fx39.iad> <TdWLO.282116$FzW1.158190@fx14.iad> <963a276fd8d43e4212477cefae7f6e46@www.novabbs.org> <8IcMO.249144$v8v2.147178@fx18.iad> <vkhgkn$2g9gm$1@dont-email.me> <7bffca4c284d329c60d8e93c7382c30f@www.novabbs.org> <lMYaP.58929$EYNf.21294@fx11.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="440433"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$I69ivAdRf9M7aAM1qU83E.5Gsm6jPmmh4tjBIK1VU1jBzcsXZCY8y
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
Bytes: 6509
Lines: 126

On Wed, 25 Dec 2024 19:10:09 +0000, Scott Lurndal wrote:

> mitchalsup@aol.com (MitchAlsup1) writes:
>>On Wed, 25 Dec 2024 17:50:12 +0000, Paul A. Clayton wrote:
>>
>>> On 10/5/24 11:11 AM, EricP wrote:
>>>> MitchAlsup1 wrote:
>>> [snip]
>>--------------------------
>>>
>>>> But voiding doesn't look like it works for exceptions or conflicting
>>>> interrupt priority adjustments. In those cases purging the interrupt
>>>> handler and rejecting the hand-off looks like the only option.
>>>
>>> Should exceptions always have priority? It seems to me that if a
>>> thread is low enough priority to be interrupted, it is low enough
>>> priority to have its exception processing interrupted/delayed.
>>
>>It depends on what you mean::
>>
>>a) if you mean that exceptions are prioritized and the highest
>>priority exception is the one taken, then OK you are working
>>in an ISA that has multiple exceptions per instruction. Most
>>RISC ISAs do not have this property.
>
> AArch64 has 44 different synchronous exception priorities, and within
> each priority that describes more than one exception, there
> is a sub-prioritization therein.  (Section D 1.3.5.5 pp 6080 in
> DDI0487K_a).

Thanks for the link::

However, I would claim that the vast majority of those 44 things
are interrupts and not exceptions (in colloquial nomenclature).

An exception is raised if an instruction cannot execute to completion
and is raised synchronously with the instruction stream (and at a
precise point in the instruction stream.

An interrupt is raised asynchronous to the instruction stream.

Reset is an interrupt and not an exceptions.

Debug that hits an address range is closer to an interrupt than an
exception. <but I digress>

But it appears that ARM has many interrupts classified as exceptions.
Anything not generated from instructions within the architectural
instruction stream is an interrupt, and anything generated from
within an architectural instructions stream is an exception.

It also appears ARM uses priority to sort exceptions into an order,
while most architectures define priority as a mechanism to to choose
when to take hard-control-flow-events rather than what.

Be that as it may...

>
> While it is not common for a particular instruction to generate
> multiple execeptions, it is certainly possible (e.g. when
> instructions are trapped to a more privileged execution mode).
>
>>
>>b) if you mean that exceptions take priority over non-exception
>>instruction streaming, well that is what exceptions ARE. In these
>>cases, the exception handler inherits the priority of the instruction
>>stream that raised it--but that is NOT assigning a priority to the
>>exception.
>>
>>c) and then there are the cases where a PageFault from GuestOS
>>page tables is serviced by GuestOS, while a PageFault from
>>HyperVisor page tables is serviced by HyperVisor. You could
>>assert that HV has higher priority than GuestOS, but it is
>>more like HV has privilege over GuestOS while running at the
>>same priority level.
>
> It seems unlikely that a translation fault in user mode would need
> handling in both the guest OS and the hypervisor during the
> execution of an instruction;

Neither stated nor inferred. A PageFault is handled singularly by
the level in the system that controls (writes) those PTEs.

There is a significant period of time in may architectures after
control arrives at ISR where the ISR is not allowed to raise a
page fault {Storing registers to a stack}, and since this ISR
might be the PageFault handler, it is not in a position to
handle its own faults. However, HyperVisor can handle GuestOS
PageFaults--GuestOS thinks the pages are present with reasonable
access rights, HyperVisor tables are used to swap them in/out.
Other than latency GuestOS ISR does not see the PageFault.

My 66000, on the other hand, when ISR receives control, state
has been saved on a stack, the instruction stream is already
re-entrant, and the register file as it was the last time
this ISR ran.

>                              the
> exception to the hypervisor would generally occur when the
> instruction trapped by the guest (who updated the guest translation
> tables) is restarted.
>
> Other exception causes (such as asynchronous exceptions
> like interrupts)

Asynchronous exceptions A R E interrupts, not like interrupts;
they ARE interrupts. If it is not synchronous with instruction
stream it is an interrupt. Only if it is synchronous with the
instruction stream is it an exception.

>                  would remain pending and be taken (subject
> to priority and control enables) when the instruction is
> restarted (or the next instruction is dispached for asynchronous
> exceptions).
>
>>
>  <snip>
>
>>> Being able to overlap latency of a memory-mapped I/O access (or
>>> other slow access) with execution of another thread seems
>
> That depends on whether the access is posted or non-posted.

Writes can be posted, Reads cannot. Reads must complete for the
ISR to be able to setup the control block softIRQ/DPC will
process shortly. Only after the data structure for softIRQ/DPC
is written can ISR allow control flow to leave.