We have addressed the issues raised on lkml after the first submission 
of the driver several weeks back and enhanced the driver with better 
sysfs support and additional device IDs to support more hardware with
the ME firmware.

The "legacy" device is not really legacy as it is available in most 
recent desktops as a firmware options in the ME (AMT 1.0) and is 
still supported by Intel and many 3rd party applications; removing 
it will break many applications.

The Intel Management Engine Interface (aka HECI: Host Embedded 
Controller Interface ) enables communication between the host OS and 
the Management Engine firmware. MEI is bi-directional, and either the 
host or Intel AMT firmware can initiate transactions.

The core hardware architecture of Intel Active Management Technology 
(Intel AMT) is resident in firmware. The micro-controller within the 
chipset's graphics and memory controller (GMCH) hub houses the 
Management Engine (ME) firmware, which implements various services 
on behalf of management applications. 

Some of the ME subsystems that can be access via MEI driver:

- Intel(R) Quiet System Technology (QST) is implemented as a firmware 
subsystem  that  runs in the ME.  Programs that wish to expose the 
health monitoring and fan speed control capabilities of Intel(R) QST 
will need to use the MEI driver to communicate with the ME sub-system.
- ASF is the "Alert Standard Format" which is an DMTF manageability 
standard. It is implemented in the PC's hardware and firmware, and is 
managed from a remote console.

Most recent Intel desktop chipsets have one or more of the above ME 
services. The MEI driver will make it possible to support the above 
features on Linux and provides applications access to the ME and it's 
features. 

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Signed-off-by: Marek Dabek <marek.dabek@intel.com>
Signed-off-by: Marcin Obara <marcin.obara@intel.com>


---
diff --git a/MAINTAINERS b/MAINTAINERS
index 9a91d9e...
[ message continues ]

There is a little problem: the driver doesn't work at all with the "64-bit 
kernel and 32-bit userspace" combination.

ioctl32(lms:7759): Unknown cmd fd(0) cmd(c0084800){t:'H';sz:8} arg(ffdfea44) on 
/dev/heci

Could you please fix it?

-- 
Alexander E. Patrakov
--

Can you please expand a bit on who on the host OS would actually communicate
with the management engine? It looks like this driver just exports
an interface to user space. What user space would use it and for
what?

I would be definitely interested in a way to save oops information
away using this.  I remember you had a demo for this, is support
for that coming soon?

-Andi
--

There are different ways you can connect to the Firmware and it all depends on
the ME subsystem you want to communicate with.
For Intel AMT, you would use LMS (Local Manageability Service) which acts as a
proxy for SOAP messages coming for management applications. LMS is available via
http://openamt.org/wiki/LocalManageabilityService.

The demo we had for storing kernel oops messages in the firmware used the AMT
1.0 interface (legacy) which allowed direct access to 3PDS using the MEI driver
interfaces. In AMT 3.0 (current platforms) this has been disabled and only SOAP
is possible which is why in the demo we changed the ME firmware to use AMT 1.0.

To have a feel for all of this, with many examples, samples and documentation
you can download the AMT 3.0 SDK (google: intel amt sdk).

Anas



--

Ok but saving oops is such a useful facility that we'll probably need 
to think about implementing SOAP in the kernel. Before everybody complains
that I went crazy: I suspect with some simplifying assumptions it could
be made relatively straight forward code. In particular if one assumes
no packets get lost then it would be possible to strip down TCP greatly
(so it doesn't need to be much more complicated than netconsole) 
and I suspect a very minimal SOAP parser just for this application would

I would be more interested right now how the kernel can use this without
additional user space support. Any ideas on this? 

-Andi

--

Actually no TCP/IP is needed here. Basically the MEI driver writes and reads the
messages to/from the firmware. When communicating in-band using LMS, TCP/IP

I will dig for some documents on that.

--

..

Sample code for storing a trace_back() would be much better.

-ml
--

Better just a patch that handles all oopses or perhaps better
all printk output (meconsole?) 

-Andi
--

Ah that's good to know. I suspect the SOAP interchange could be stripped
down a lot to make it reasonably simple; ideally with all strings just hardcoded
somewhere. Would much parsing be needed?

-Andi
--

From: Andi Kleen <andi@firstfloor.org>

Ummm, no.

UDP is stateless, a stripped down copy of TCP we simply
do not need.  We also do not need XML in the kernel either.

If they want to support things like this they should do it in the
firmware of the management entity like every other sane server
platform does these days.

The console and OOPS messages should go over an extremely resilient
transport which is as simple as possible which usually means shared
memory or I/O memory with some simple handshake or doorbell.  This
gets it to the management entity board or whatever, and how it gets
from there to the remote system is it's business not that of the
kernel.

Not TCP, and definitely not this XML SOAP crap.
--

Even if it means you can get users to submit clear logged oopses out 
of many machines who hung silently before? 

Sure most of the XML infrastructure that tends to be used in 
user space is pure bloat. But if you don't want universal
interoperability and just for specific applications
you'll essentially just have a few hardcoded strings that
you'll write down some firmware interface and then a simple
parser to read the results. Again that wouldn't be a generic
XML parser, but just something tailored to the specific job.

I doubt it would be much worse code-wise than some of the more 

They do -- the problem is that you need SOAP to talk the firmware.

With soap it would be a slightly more complicated handshake 
and a few hard coded text strings around the actual information.
While that's not pretty if the result is worth it (and I think
general oops logging would be worth a lot of things) that's not too
bad.

-Andi
--