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:

quoted

On Mon, Oct 25, 2021 at 08:20:05AM -0500, Patrick Williams wrote:

quoted

On Mon, Oct 25, 2021 at 03:58:25PM +0300, Andy Shevchenko wrote:

quoted

On Mon, Oct 25, 2021 at 06:44:26AM -0500, Patrick Williams wrote:

quoted

On Mon, Oct 25, 2021 at 08:15:41AM +0200, Greg Kroah-Hartman wrote:

quoted

On Mon, Oct 25, 2021 at 12:38:08AM -0500, Frank Rowand wrote:

quoted

On 10/23/21 3:56 AM, Greg Kroah-Hartman wrote:

quoted

We have the bind/unbind ability today, from userspace, that can control
this.  Why not just have Linux grab the device when it boots, and then
when userspace wants to "give the device up", it writes to "unbind" in
sysfs, and then when all is done, it writes to the "bind" file and then
Linux takes back over.

Unless for some reason Linux should _not_ grab the device when booting,
then things get messier, as we have seen in this thread.

This is probably more typical on a BMC than atypical.  The systems often require
the BMC (running Linux) to be able to reboot independently from the managed host
(running anything).  In the example Zev gave, the BMC rebooting would rip away
the BIOS chip from the running host.

The BMC almost always needs to come up in a "I don't know what could possibly be
going on in the system" state and re-discover where the system was left off.

Isn't it an architectural issue then?

I'm not sure what "it" you are referring to here.

I was trying to explain why starting in "bind" state is not a good idea for a
BMC in most of these cases where we want to be able to dynamically add a device.

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?  What method
is used to pass the device from one CPU to another from a logical point
of view?  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?

thanks,

greg k-h