Re: Making Lemonade (Floating-point format changes)

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.

This was something I was not aware of but probably should have anticipated.
GuestOS initiates an I/O request (command) using a virtual function.
Rather than going through a bunch of activities to verify the user
owns the page and it is present, GuestOS just launches request and
then the I/O device page faults and pins the required page (if it is
not already so)--much like the page fault volcano when a new process
begins running:: page faulting in .text, the stack, and data pages
as they get touched.
This way, GuestOS simply considers all pages in its "portfolio" to be
present in memory, and HV does the heavy lifting and page virtualization.
I guess I should have anticipated this. Sorry !!

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.