Re: Stacks, was Segments

On Wed, 12 Feb 2025 0:34:18 +0000, Scott Lurndal wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

On Tue, 11 Feb 2025 20:49:24 +0000, Scott Lurndal wrote:
>

mitchalsup@aol.com (MitchAlsup1) writes:

On Tue, 11 Feb 2025 14:04:59 +0000, Scott Lurndal wrote:
---------------------
This is the missing part:: When a user performs a LD or ST

>
You're missing the point completely.  There no user
performing a LD or ST.   The DMA controller on the device
is initiating the transaction, not the host CPU.
>

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".

>
This is basically how all modern CPUs handle it, yes.
>
But it is not relevent to the inbound traffic initiated
-by the device- which can't be translated by the CPU,
rather must be translated at some point between the
PCIe controller and the internal processor interconnect
(e.g. mesh).

>
I am tracing the path from user of device (core Guest OS).
If I don't understand this "should be simple" path, I am
too lost to continue from the device side looking towards
memory.
>
I can see how core can write Guest Physical Address into
device.BAR using config space access (with appropriate
MMU permissions).
>
But, right now: I can't see how the appropriate bit pattern
from core gets to HostBridge in MMI/O space and is recognized
by matching device.BAR down the PCIe tree.

We will ignore this for a while.

The hardware is generally described to the operating system
through tables provided by the firmware (supplied by the system
builder).  There are two different mechanisms in widespread use;
ACPI and DeviceTree.   The former, sponsered primarily by Microsoft
and Intel, provides a standard mechanism for the hardware to
describe itself to the operating system/hypervisor.

Side topic::
Why not just spoof PCIe config space, and setup config space
headers that cause Guest OS to load the paravirtualized driver ??
instead of the direct device driver ?!?
{{It has to be a speed/latency issue}}

An entry in those tables for a particular device will describe
in standard terms the path from the memory/processor complex
to the device.   Say, for example, your CPU uses a high-speed
mesh interface between cores.   The outer ring on the mesh
will connect to memory controllers and I/O bridges.
>
Each point in the path is described by a table entry
in the ACPI tables.
>
Assume a simple config
>
  +=========+     +========+  +=======+
  |  CPU    |     |  HOST  |  | PCIe  |
  | Memory  |-----| Bridge |--| Ctlr |------+---------------+-----------
  | complex |     |        |  |       |      |               |
  +=========+     +========+  +=======+   Func 0          Func 1
                                          BAR[0]=X        BAR[2]=Y

Now, consider a device with 16 virtual functions, and 16 Guest
OSs. All 16 Guest OSs use the same Guest Physical Address in
their virtual function BARs.
How does the PCIe controller figure out that an MMI/O space
sized write is to GuestOS[7] or GuestOS[14] ?? {{Obviously,
once the command is place in the routing tree, it will be
matched by all the GuestOS BARs.}}
Thus, there is still information missing for my understanding.