On Mon, Oct 25, 2021 at 04:09:59PM +0200, Greg Kroah-Hartman wrote: > On Mon, Oct 25, 2021 at 09:02:40AM -0500, Patrick Williams wrote: > > On Mon, Oct 25, 2021 at 03:34:05PM +0200, Greg Kroah-Hartman wrote: > > > On Mon, Oct 25, 2021 at 08:20:05AM -0500, Patrick Williams wrote: > > > I think "it" is "something needs to be the moderator between the two > > > operating systems". What is the external entity that handles the > > > switching between the two? > > > > Ah, ok. > > > > Those usually end up being system / device specific. In the case of the BIOS > > flash, most designs I've seen use a SPI mux between the BMC and the host > > processor or IO hub (PCH on Xeons). The BMC has a GPIO to control the mux. > > > > As far as state, the BMC on start-up will go through a set of discovery code to > > figure out where it left the system prior to getting reset. That involves > > looking at the power subsystem and usually doing some kind of query to the host > > to see if it is alive. These queries are mostly system / host-processor design > > specific. I've seen anything from an IPMI/IPMB message alert from the BMC to > > the BIOS to ask "are you alive" to reading host processor state over JTAG to > > figure out if the processors are "making progress". > > But which processor is "in control" here over the hardware? The BMC. It owns the GPIO that controls the SPI mux. But, the BMC is responsible for doing all operations in a way that doesn't mess up the running host processor(s). Pulling away the SPI flash containing the BIOS code at an incorrect time might do that. > What method > is used to pass the device from one CPU to another from a logical point > of view? The state of the server as a whole is determined and maintained by the BMC. I'm simplifying here a bit but the operation "turn on the host processors" implies "the host processors will access the BIOS" so the BMC must ensure "SPI mux is switched towards the host" before "turn on the host processors". > Sounds like it is another driver that needs to handle all of > this, so why not have that be the one that adds/removes the devices > under control here? If what you're describing is moving all of the state control logic into the kernel, I don't think that is feasible. For some systems it would mean moving yet another entire IPMI stack into the kernel tree. On others it might be somewhat simpler, but it is still a good amount of code. We could probably write up more details on the scope of this. If what you're describing is a small driver, similar to the board support drivers that were used before the device tree, that instantiates subordinate devices it doesn't seem like an unreasonable alternative to DT overlays to me (for whatever my limited kernel contribution experience counts for). -- Patrick Williams
Attachment:
signature.asc
Description: PGP signature
