Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: Making Lemonade (Floating-point format changes)
Date: Tue, 14 May 2024 17:51:15 +0300
Organization: A noiseless patient Spider
Lines: 51
Message-ID: <20240514175115.00000516@yahoo.com>
References: <abe04jhkngt2uun1e7ict8vmf1fq8p7rnm@4ax.com>
	<memo.20240512203459.16164W@jgd.cix.co.uk>
	<v1rab7$2vt3u$1@dont-email.me>
	<20240513151647.0000403f@yahoo.com>
	<v1tre1$3leqn$1@dont-email.me>
	<9c79fb24a0cf92c5fac633a409712691@www.novabbs.org>
	<v1u6oi$3o53t$1@dont-email.me>
	<bcbda29c4c23543d1ed6de8290d1dc3b@www.novabbs.org>
	<v1ubel$3p1kt$1@dont-email.me>
	<01b78f15d6b5f87809163ce539356ef2@www.novabbs.org>
	<pZJ0O.14089$yT%1.12952@fx33.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 14 May 2024 16:51:18 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="dcb64060f415e7fe23ed2e09ecf0fa94";
	logging-data="242832"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19eBMsJbHU4IPUzzAxgd5NC9lgvjxaku+8="
Cancel-Lock: sha1:JW8NQ/o4LeD9sEKdFvX3gqOKVWo=
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
Bytes: 3670

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.