Re: Stacks, was Segments

On Tue, 11 Feb 2025 14:04:59 +0000, Scott Lurndal wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

On Mon, 10 Feb 2025 20:18:04 +0000, Scott Lurndal wrote:
>

mitchalsup@aol.com (MitchAlsup1) writes:

On Fri, 7 Feb 2025 20:32:39 +0000, Scott Lurndal wrote:

-----------------isolating---------------------------------
>

HyperVisor maintains a PTE to map guest physical addresses
within an aperture to the page matching the device's BAR.

>
Standard HV stuff.   Although you may want to consider that
the value in the function's BAR, must be a guest PA, not a
machine PA.

>
I need a "WHY" on this sentence before responding to the rest.

>
The guest OS (or user application) is directly programming the addresses
in the
PCIe function DMA engine[*].   The point is to completely
avoid the hypervisor from being involved in the I/O,
so the guest programs the function DMA engine using guest PA and the
IOMMU translates the guest PA into machine
addresses for all transactions initiated by the
function.
>
(Each PCIe function is treated as an individual device
by the OS/HV.  The entire purpose of SR-IOV is to
present the device directly to the guest to avoid any
hypervisor involvment in the I/O path).

This is the missing part:: When a user performs a LD or ST
the guest Virtual address is translated to Guest Physical
by Guest OS translation tables. Guest Physical is then
interpreted as Host virtual and translated a second time
by {SM,HV} mapping tables. This nested MMU does both
translations in a single access; so core TLB is organized
to associate guest virtual directly with machine physical !
as if there were a level crossing PTE providing all the
"right bits".
Now that the device has been configured, Guest OS decides
to write some control registers of the device. Guest OS
has its own translation tables for Guest Virtual to Guest
Physical--but the core MMU then translates guest Physical
to Machine Physical before it gets transported over the
interconnect. So, by the time said address gets to Host-
Bridge it is already in Machine Physical, not the Guest
physical you mention.*
------------------------------------------------------
UNLESS HV and Guest OS have an agreement that Guest Physical
has a range by which Guest Physical == Machine Physical !!
And if there is such an agreement, calling the address
Machine Physical is just as valid as calling it Guest
Physical.
(*) it sounds like you are assuming there is a way to trans-
late the first nesting level to guest physical and then
sidestep the translation of guest physical to machine
physical until the request gets to the I/O MMU, allowing
the I/O MMU to perform the second level of nesting trans-
lation.
{{Back to the other stuff later}}