From: cross@spitfire.i.gajendra.net
In article <7O7bM.3161054$iS99.2255655@fx16.iad>,
Scott Lurndal wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>In article ,
>>Scott Lurndal wrote:
>>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>>In article ,
>>>>Scott Lurndal wrote:
>>>>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>>>[snip]
>>>>>>It's still not entirely clear to me now the BSP/BSC is supposed
>>>>>>to boot, however. If the world starts in 64-bit mode, and that
>>>>>>still requires paging to be enabled, then who sets up the page
>>>>>>tables that the BSP starts up on?
>
>>>The boostrap processor:
>>>
>>> "The CPU starts executing in 64-bit paged mode after reset. The
>>> Firmware Interface Table (FIT) contains a reset state structure
>>> containing RIP and CR3 that defines the initial execution state of
>>> the CPU."
>>>
>>>I'm presuming that a management processor provided by the
>>>mainboard vendor will initialize the FIT out-of-band before
>>>releasing the BSP from reset sufficent to execute the UEFI
>>>firmware and boot loader.
>>
>>Ah, the AMD PSP approach, aka, how to start the engine on a
>>ship. I guess the days of DRAM training from the BSP are over,
>>which isn't necessarily a bad thing.
>
>That doesn't necessarily follow. It is possible to run the
>training code from the L1/L2 caches with careful coding.
Are we assuming the external processor can write to those
caches? If so, perhaps, but it begs the question: why? I've
evidently got a perfectly capable processor running before the
x86 cores can even come out of reset, and it can mess with the
microarchitectural state of the x86 CPU anyway: why not just
let it train DRAM as well?
If it can't write to those caches, then I don't see how it could
initialize page tables that the CPU would start executing from,
unless it dumped them into a mandatory SRAM buffer or something.
>>>Ok. Coming from the unix/linux world, ring 3 access to those
>>>has generally not been allowed and I don't see removal of that
>>>capability as a loss, but rather a gain.
>>
>>ioperm(2) and iopl(2)? :-)
>
> Hence "generally". Can't recall ever seeing it used.
I suppose I misinterpreted "generally." A general-purpose
mechanism to expose the functionality exists, though I agree
that relatively few applications make use of it. A friend of
mine did a PhD back in the 90s and did use it pretty extensively
to take data from an ISA-bus device (no interrupts though; he
just burned CPU polling).
>[snip]
>>Sigh. Actually, I checked the PCIe spec last night and I think
>>I was just wrong. It looks like you can still do it, but
>>address/data register pairs are problematic, so I always just
>>use ECAM.
>
>Yeah, cf8/cfc was always an intel specific mechanism anyway;
>I don't recall it being defined in the PCI Spec (check's 1993
>copy, which states "System dependent issues ... such as mapping
>various PCI address spaces (config, memory, i/o) into host
>CPU address spaces, ordering rules, etc are described in the
>PCI System Design guide" - which I don't have a copy of handy)
I checked my copy of the 6.0 spec yesterday and it mentions
"io" in addition to config and MMIO, which I interpret to mean
port-space IO.
>>I think port IO can be useful at very early boot for writing
>>debugging data to the UART, or for supporting legacy "PC"
>>devices; beyond that, I find it annoying.
>
>Yes, there's no doubt about that. On the AArch64 chips I
>work with, the UART is memory mapped (compatible with the
>ARM PL011 UART), and has a PCI configuration space; so
>the early boot code needs to scan the PCI bus, read the
>BAR and use MMIO through that bar (the PCI Enhanced
>Allocation capability is present, so the BARs are
>fixed rather than programable). Interrupts are handled
>via MSI-X vectors (and being level sensitive, a pair
>of vectors are used, one to assert and one to deassert
>the interrupt).
Level sensitive? Huh.
I wrote a driver for a memory-mapped UART in an AMD SoC complex
a few months ago; we use it for early boot on our machines. It
is soon enough after coming out of reset that I don't bother
with interrupts; we just poll.
Having to go through config space to map a BAR to drive a UART
seems excessive to me.
>[snip]
>Well, existing art included various peek/poke backdoors similar
>to cf8/cfc using MMIO registers at the time. I was on the architecture
>team when we started the ARMv8 processors and pushed using ECAM in our
>implemention; our MIPS chips had used peek/poke registers in the
>PCI controller (onboard devices didn't look like PCI). In the
>ARM chip, for discovery purposes, we chose make all the on-chip
>devices and accelerators look like PCI devices and thus something
>like the ECAM became necessary.
Oh of course; memory-mapped address/data register pairs would
give the same effect.
Making everything look like PCI certainly makes things regular.
>>Definitely some really cool things have happened in that space
>>while those of us slumming it with x86 have looked on with envy.
>
>I've been fortunate to have worked near the bleeding edge:
>from new mainframe architecture (updating a 20 Y.O. Arch) in the early 80s to
>uKernel based distributed Unix-like operating systems in the late 80s/early
90's
>to a distributed version of IRIX in the late 90's transitioning to
>linux (contributed KDB while at SGI) and hypervisors in late 90s
>(somewhat in parallel with disco) and a distributed hypervisor
>in the 2000's (3Leaf Systems) it's been quite a ride.
Nice. 3Leaf sounds interesting; are there any papers on it
available?
- Dan C.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
