On Thu Sep 4, 2025 at 5:43 PM CEST, Zhi Wang wrote:
> On Thu, 04 Sep 2025 11:41:03 +0200
> "Danilo Krummrich" <[email protected]> wrote:
>
>> (Cc: Alex, John, Joel, Alistair, nouveau)
>>
>> On Thu Sep 4, 2025 at 11:37 AM CEST, Danilo Krummrich wrote:
>> > nova-core won't provide any firmware specific APIs, it is meant to serve
>> > as a
>> > hardware and firmware abstraction layer for higher level drivers, such as
>> > vGPU
>> > or nova-drm.
>> >
>> > As a general rule the interface between nova-core and higher level drivers
>> > must
>> > not leak any hardware or firmware specific details, but work on a higher
>> > level
>> > abstraction layer.
>> >
>
> It is more a matter of where we are going to place vGPU specific
> functionality in the whole picture. In this case, if we are thinking about
> the requirement of vGPU type loading, which requires the GSP version
> number and checking. Are we leaning towards putting some vGPU specific
> functionality also in nova-core?
As much as needed to abstract firmware (and hardware) API details.
> Regarding not leaking any of the hardware details, is that doable?
> Looking at {nv04 * _fence}.c {chan*}.c in the current NVIF interfaces, I
> think we will expose the HW concept somehow.
I don't really mean that vGPU must be entirely unaware of the hardware, it's
still a driver of course. But for the API between nova-core and client drivers
we want to abstract how the firmware and hardware is programmed, i.e. not leak
any (version specific) RM structures or provide APIs that consume raw register
values to write, etc.
