Linux Virtualization - Sep 2013 - [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.

On Thu, Sep 05, 2013 at 04:41:55PM -0700, Sudeep Dutt
wrote:
> +What:		/sys/class/mic/mic(x)/firmware
> +Date:		August 2013
> +KernelVersion:	3.11
> +Contact:	Sudeep Dutt <sudeep.dutt at intel.com>
> +Description:
> +		When read, this sysfs entry provides the path name under
> +		/lib/firmware/ where the firmware image to be booted on the
> +		card can be found. The entry can be written to change the
> +		firmware image location under /lib/firmware/.
I don't understand, is the path under the HOST device, or the Client
device's disk?  Why do you need to change the path on the HOST?  What's
wrong with the existing firmware path selection we have in the kernel?

thanks,

greg k-h

On Thu, 2013-09-05 at 22:01 -0700, Greg Kroah-Hartman
wrote:
> On Thu, Sep 05, 2013 at 04:41:55PM -0700, Sudeep Dutt wrote:
> > +What:		/sys/class/mic/mic(x)/firmware
> > +Date:		August 2013
> > +KernelVersion:	3.11
> > +Contact:	Sudeep Dutt <sudeep.dutt at intel.com>
> > +Description:
> > +		When read, this sysfs entry provides the path name under
> > +		/lib/firmware/ where the firmware image to be booted on the
> > +		card can be found. The entry can be written to change the
> > +		firmware image location under /lib/firmware/.
> 
> I don't understand, is the path under the HOST device, or the Client
> device's disk?  Why do you need to change the path on the HOST? 
What's
> wrong with the existing firmware path selection we have in the kernel?
> 
The path is on the host. The card does not have a physical persistent
disk device. Our customers like the flexibility of changing the card
firmware/ramdisk contents and file names for individual MIC cards. This
flexibility is not possible with a static set of firmware file names in
the kernel for all cards.

Once the firmware/ramdisk path under /lib/firmware/ is set up via sysfs,
card boot is initiated via the "state" sysfs entry. The host driver
then
obtains the contents of the firmware and ramdisk via the standard
request_firmware(..) interface, copies the contents to card memory and
interrupts the card BIOS to initiate boot.

Thanks,
Sudeep Dutt

On Fri, Sep 06, 2013 at 11:41:03AM -0700, Sudeep Dutt
wrote:
> On Thu, 2013-09-05 at 22:01 -0700, Greg Kroah-Hartman wrote:
> > On Thu, Sep 05, 2013 at 04:41:55PM -0700, Sudeep Dutt wrote:
> > > +What:		/sys/class/mic/mic(x)/firmware
> > > +Date:		August 2013
> > > +KernelVersion:	3.11
> > > +Contact:	Sudeep Dutt <sudeep.dutt at intel.com>
> > > +Description:
> > > +		When read, this sysfs entry provides the path name under
> > > +		/lib/firmware/ where the firmware image to be booted on the
> > > +		card can be found. The entry can be written to change the
> > > +		firmware image location under /lib/firmware/.
> > 
> > I don't understand, is the path under the HOST device, or the
Client
> > device's disk?  Why do you need to change the path on the HOST? 
What's
> > wrong with the existing firmware path selection we have in the kernel?
> > 
> 
> The path is on the host. The card does not have a physical persistent
> disk device. Our customers like the flexibility of changing the card
> firmware/ramdisk contents and file names for individual MIC cards. This
> flexibility is not possible with a static set of firmware file names in
> the kernel for all cards.
> 
> Once the firmware/ramdisk path under /lib/firmware/ is set up via sysfs,
> card boot is initiated via the "state" sysfs entry. The host
driver then
> obtains the contents of the firmware and ramdisk via the standard
> request_firmware(..) interface, copies the contents to card memory and
> interrupts the card BIOS to initiate boot.
So this is really a "filename" that might contain some directories as
well, right?  The fact you used "path" confused me, as that
doesn't
usually imply a filename.

And is the "firmware" just the initramfs image for the kernel to boot?

thanks,

greg k-h