Message-ID: <03ff4983-d8a9-6ad7-a655-a8dcde3da360@intel.com>
Date:   Tue, 26 Oct 2021 10:41:12 -0700
From:   Russ Weight <russell.h.weight@...el.com>
To:     "Wu, Hao" <hao.wu@...el.com>, "Xu, Yilun" <yilun.xu@...el.com>
CC:     Tom Rix <trix@...hat.com>, "mdf@...nel.org" <mdf@...nel.org>,
        "linux-fpga@...r.kernel.org" <linux-fpga@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "lgoncalv@...hat.com" <lgoncalv@...hat.com>,
        "Gerlach, Matthew" <matthew.gerlach@...el.com>
Subject: Re: [PATCH v17 0/5] FPGA Image Load (previously Security Manager)



On 10/25/21 11:45 PM, Wu, Hao wrote:
>>>>>>>> The FPGA Image Load Framework was designed with the concept of
>>>>>>>> transferring data to a device without imposing a purpose on the data.
>>>>>>>> The expectation is that the lower-level driver or the device will
>>>>>>>> validate the data. Is there something fundamentally wrong with that
>>>>>>> I think there is something wrong here. As I said before, persistent
>>>>>>> storage updating has different software process from some runtime
>>>>>>> updating, so the class driver should be aware of what the HW engine
>>>>>>> is doing.
>>>>>> So far, there are no self-describing images that cause a
>>>>>> change in run-time behavior, and I don't think that will
>>>>>> happen for the very reason that the class-driver would
>>>>>> need to know about it.
>>>>> Again, the class driver needs to know what is happening, at some
>>>>> abstraction level, to ensure the system is aligned with the HW state.
>>>>>
>>>>> If the class driver cannot tell the detail, it has to assume the
>>>>> whole FPGA region will be changed, and removal & re-enumeration is
>>>>> needed.
>>>> So we make it a requirement that the self-describing files
>>>> cannot make changes that require the class driver to manage
>>>> state.
>>> The API should not only define what it won't do, but also define what
>>> it will do. But the "image load" just specifies the top half of the
>>> process. So I don't think this API would be accepted.
>> So what is the path forward. It seems like you are saying
>> that the self-describing files do not fit in the fpga-mgr.
>> Can we reconsider the FPGA Image Load Framework, which does
>> not make any assumptions about the contents of the image
>> files?
> Why we need such "generic data transfer" interface in FPGA
> framework? 
Are you referring to the use of self-describing files?
or the generic nature of this class driver?
> we need to handle the common need for FPGA
> devices only, not all devices, like programming FPGA images.
> So far we even don't know, what's the hardware response on
> these self-describing files, how we define it as a common need
> interface in the framework?
The class driver does not _need_ to reside in the FPGA
framework. I sent an inquiry to the maintainer of the
Firmware update subsystem (and cc'd the kernel mailing list)
and received no responses. I placed it under the FPGA
framework only because the first user of the class driver
is an FPGA driver.

> If you just want to reuse the
> fpga-mgr/framework code for your own purpose, Yes, it seems
> saving some code for you, but finally it loses flexibility, as it's
> not possible to extend common framework for your own
> purpose in the future.
If I understand correctly, you are saying that it doesn't
fit well in the FPGA manager, because not all file types
fit the definition of a firmware update? And future file
types may not fit in fpga-mgr context?

- Russ
>  
> Thanks
> Hao

Powered by blists - more mailing lists