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: References: <2024Oct3.160055@mips.complang.tuwien.ac.at> <963a276fd8d43e4212477cefae7f6e46@www.novabbs.org> <8IcMO.249144$v8v2.147178@fx18.iad> <7bffca4c284d329c60d8e93c7382c30f@www.novabbs.org> 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 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). > >> > > >>> 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.