[Openib-windows] RE: tools support

[Tillier, Fabian]

> From: Leonid Keller [mailto:leonid at mellanox.co.il]
> Sent: Tuesday, September 13, 2005 11:56 AM
> 
> > -----Original Message-----
> > From: Fab Tillier [mailto:ftillier at silverstorm.com]
> > Sent: Tuesday, September 13, 2005 8:03 PM
> >
> > > From: Leonid Keller [mailto:leonid at mellanox.co.il]
> > > Sent: Tuesday, September 13, 2005 2:58 AM
> > >
> > > There are 2 ways of doing that: via gateway in PCI config
> > > space of the HCA
> > > cards, which is supported by the driver, but is slow,
> > > and by direct writing into  CR
> > > space of the card after mapping it to the address space of
> > > the process.
> >
> > Why does the CR space have to be mapped into user-mode?  Why
> > can't the kernel
> > driver just write directly into the CR space, and have the
> > user-mode tool pass a
> > buffer with the firmware image?
>
> [LK] Because user tools may have very complicate logic of how to work
with
> device.
> [it also answers on your below question]
> We are not going to expose this interface, but we need to provide
effective
> tools.

If there's an IOCTL that can get CR space access to user-mode, then it
is exposed, whether or not it is public and documented.  This is a
potential security issue.  However, this security issue still exists
today in the sense that access to configuration cycles are exposed.  We
should probably plan to use WMI for this functionality rather than
IOCTLs since WMI requests can have individual access control rights -
this would allow only administrators access to this functionality.

Let's get the functionality in place, including mapping the CR space to
user-mode, and then work on the security aspects of it.

> > > Another requirement - support of "live fishes" (flash
> > > burner devices).
> > > Any our device can be jumpered to work without CR-space in
> > > case when it
> > > has an invalid (or doesn't have at all) FW on it. In that
> > > case it has
> > > device_id greater by one than its original one (e.g. 23109
> > > - for Tavor).
> > > The burning is performed by configuration cycles.
> > > How would you suggest to add support for those devices ?
> >
> > When an HCA registers itself, IBAL creates a CA object to
> > represent that device.
> > For the driver to support the "live fish" mode, it would
> > simply report itself as
> > an HCA with no support for any resources except protection
> > domains.  The
> > protection domain creation simply returns success (but is a
> > noop internally),
> > and all other resource creation verbs return failure.  This
> > will prevent the
> > SMI/GSI from loading, but will allow the HCA to be available
> > for use, which
> > means user-mode processes can see it.  Once user-mode
> > processes can see the
> > device, the HCA FW update tool should be able to work without issue.
> >
> [LK] Is there an issue with GUID ?
> HCA driver uses GUID as an identifier of the card.
> It can't find out it in this case.

The GUID is only there to serve as an identifier, and doesn't have to be
a real, valid value - it is opaque and you could make one up.  IBAL will
fail registration of an HCA with the same GUID as an existing HCA.

- Fab