On 7.10.2025 13.14, Danilo Krummrich wrote: > On Tue Oct 7, 2025 at 8:51 AM CEST, Zhi Wang wrote: >> From the device vendor’s perspective, we have no support or use case for >> a bare-metal VF model, not now and not in the foreseeable future. > > Who is we? I think there'd be a ton of users that do see such use-cases. > > What does "no support" mean? Are there technical limitation that prevent an> > implementation (I haven't seen any so far)? > >> Even >> hypothetically, such support would not come from nova-core.ko, since >> that would defeat the purpose of maintaining a trimmed-down kernel >> module where minimizing the attack surface and preserving strict >> security boundaries are primary design goals. > > I wouldn't say the *primary* design goal is to be as trimmed-down as possible. > > The primary design goals are rather proper firmware abstraction, addressing > design incompatibilities with modern graphics and compute APIs, memory safety > concerns and general maintainability. > > It does make sense to not run the vGPU use-case on top of all the additional > DRM > stuff that will go into nova-drm, since this is clearly not needed in the vGPU > use-case. But, it doesn't mean that we have to keep everything out of > nova-core > for this purpose. > > I think the bare-metal VF model is a very interesting use-case and if it is > technically feasable we should support it. And I think it should be in > nova-core. The difference between nova-core running on a bare metal VF and > nova-core running on the same VF in a VM shouldn't be that different anyways, > no?
@Neo. Can you shed some light here?
