On Thu, 17 Apr 2025 20:10:11 +0000, Scott Lurndal wrote:
mitchalsup@aol.com (MitchAlsup1) writes:
On Thu, 17 Apr 2025 1:04:10 +0000, John Levine wrote:
According to Scott Lurndal <slp53@pacbell.net>:
I think you could gain a tiny amount of efficiency if the OS (super) >>>>>allowed the user to set up handle certain classes of exceptions, e.g. >>>>>divide faults) itself rather than having to go through the super.
Think carefully about the security implications of user-mode interrupt >>>>delivery. Particuarly with respect to potential impacts on other >>>>processes running on the system, and to overall system functionality.
Handling interrupts requires direct access to the hardware from >>>>user-mode.
I think he was talking about exceptions, not interrupts. I don't see
much danger in reflecting divide faults and supervisor calls directly
back
to the virtual machine. I gather that IBM's virtualization microcode
has done that for decades.
I used (I think) the word interrupted as in "the thread currently in >>control
has its instruction stream interrupted" which could stand in for
interrupts
or exceptions or faults; to see how the conversation develops.
In ARM64, an interrupt is just a maskable asynchronous exception.
My 66000 defines:
a) exception: something wrong in the attempt to execute an instruction
b) interrupt: asynchronous events not related to instruction execution
c) trap ... : request for service to next higher privilege layer
d) check .. : something that should (almost) never happen
Unlike many RISC architectures, My 66000 has arithmetic exceptions
{Operand Domain, Result Range, privilege, 5-IEEE exceptions} along
with typical {GuestOS page fault, Hypervisor page fault} everybody
has. Much more IBM 360-like than MIPS-like.
Exceptions are then categorized as repairable-faults or terminations.
SW determines if arithmetic faults are recognized and what to do
with the exception if one is raised and recognized {terminate, repair, complete}. Page faults operate under "repair" state is repaired such
that re-execution of the instruction should now succeed. Complete is
for situations where a HW cannot deliver "an acceptable" result, but
SW can. Here, SW "completes" the work and returns following the causing instruction.
Checks are things like
1) unrepairable ECC failure
2) special privilege violations
3) hardware failures
4) power or reset events
Which either log the event, attempt repair, or panic the VMM.
Checks are simply exceptions that deliver control to {secure}
instead of {next higher privilege} and checks are not maskable.
{I may come to regret this non-maskable part ...}
It seems to me that to "take" and interrupt at user layer in SW-stack,
that the 3-upper layers have to be in the same state as when that User >>thread is in control of a core. But, It also seems to me that to "take"
an interrupt into Super, the 2 higher layers of SW-stack also have to
be as they were when that Super thread has control. You don't want >>HV[j].GuestOS[k] to take an interrupt when Hyper != HV[j] && Super != >>GuestOS[k] -- because the various translation tables are not properly >>available to perform the nested MMU VAS->UAS translation.
Note that while any one layer is executing _on a core/hardware thread_,
the other layers aren't running on that core,
Not "running" but those layer's CRs are still supporting lower privilege
layers that ARE running on that core. Mostly in the nested Root pointer
and ASID categories, sometimes in the interrupt-table category.
by definition. However,
there is
no synchronization with other cores, so other cores in the same system
may be executing in any one or all of the privilege levels/security
layers
while a given core is taking an exception (synchronous or asynchronous).
Yes, obviously. Any core can be operating at any priority any privilege
any layer unbeknownst to any other core; until and unless SW tries to synchronize with said other core to find out.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)