Re: Making Lemonade (Floating-point format changes)

On Tue, 14 May 2024 13:49:09 GMT
scott@slp53.sl.home (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.
 

Sounds like it could be problematic from real-time perspective.
When I design PCIe devices, I sometimes have device-side FIFO
sufficient for 2-5 times an expected worst-case PCIe latency, i.e.
for 7-10 usec or so. In scenario, you describe, it could easily overflow
for acquisition-type device or underflow for player-type device.

Now, my devices are not intended to be plugged into visualized server,
but I'd think that I am not the only designer that choses size of FIFOs
by that sort of logic.

 

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.