Path: ...!npeer.as286.net!npeer-ng0.as286.net!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Making Lemonade (Floating-point format changes)
Date: Tue, 14 May 2024 14:18:45 -0500
Organization: A noiseless patient Spider
Lines: 63
Message-ID: <v20der$bfja$1@dont-email.me>
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=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 14 May 2024 21:18:52 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f7bb63f21ae876478e2f78c3252a6146";
	logging-data="376426"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/tzG3AGQeN1bJ+1SwZQMJjFstmZ4YPo8w="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:R+/sfRKvmBgv1pRoFK8ExB/7CEk=
Content-Language: en-US
In-Reply-To: <pZJ0O.14089$yT%1.12952@fx33.iad>
Bytes: 4103

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.