Re: Making Lemonade (Floating-point format changes)

On 5/14/2024 8:49 AM, Scott Lurndal wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

BGB wrote:

 

Also I may need to rework how page-in/page-out is handled (and or how
IO is handled in general) since if a page swap needs to happen while
IO is already in progress (such as a page-miss in the system-call
process), at present, the OS is dead in the water (one can't access
the SDcard in the middle of a different access to the SDcard).

>
Having a HyperVisor helps a lot here, with HV taking the page faults
of the OS page fault handler.

>

Seems like adding another layer couldn't help with this, unless it also
abstracts away the SDcard interface.

>
With a HV, GuestOS does not "do" IO is paravirtualizes it via HV.

 Actually, that's not completely accurate.  With PCI Express SR-IOV,
an I/O MMU and hardware I/O virtualization, the guest accesses the I/O device
hardware directly and initiates DMA transactions to-or-from the
guest OS directly.   With the PCIe PRI (Page Request Interface), the
guest DMA target pages don't need to be pinned by the hypervisor; the
I/O MMU will interrupt the hypervisor to make the page present
and pin it and the hardware will then do the DMA.
 

Though, I am not dealing with anything here with IOMMU's, DMA's, or PCI configuration spaces, ...
For the most part, not even much in terms of interrupts (ATM, about the only real interrupt source is a 1kHz timer).
Generally all polling IO via MMIO, mostly because AFAIK this was the cheapest way I could do it.
Granted, using polling IO to drive an SPI link to access an SDcard isn't the "best" way to do this; and does have the drawback that the CPU's time is basically fully occupied during the transfer.
But, effectively, this process can't be interruptible/multiplexable, since then one is left with a half transferred block, and no way to resume a previously disrupted transfer.
In this case, transfers are generally in terms of 512 byte sectors.
Not sure if something like an ARM SoC provides a higher level abstraction to an SDcard, not really looked into it.

 

So, having a GuestOS in a position it cannot deal with another page
fault is no longer a hindrance:: GuestOS does not see that page fault;
it is just handled and goes away.

 There are two levels of page faults - at the guest level, the
guest handles everything.   When the hypervisors supports
multplexing multple guests on a core, it will only handle second
level translation table faults.