[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5da095e6-040d-4531-91f9-cd3cf4f4c80d@nvidia.com>
Date: Wed, 1 Oct 2025 08:09:37 +0000
From: Zhi Wang <zhiw@...dia.com>
To: John Hubbard <jhubbard@...dia.com>, Alexandre Courbot
<acourbot@...dia.com>, Danilo Krummrich <dakr@...nel.org>
CC: Joel Fernandes <joelagnelf@...dia.com>, Timur Tabi <ttabi@...dia.com>,
Alistair Popple <apopple@...dia.com>, Surath Mitra <smitra@...dia.com>, David
Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, Bjorn Helgaas
<bhelgaas@...gle.com>, Krzysztof Wilczyński
<kwilczynski@...nel.org>, Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor
<alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>, Gary Guo
<gary@...yguo.net>, Björn Roy Baron
<bjorn3_gh@...tonmail.com>, Benno Lossin <lossin@...nel.org>, Andreas
Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>, Trevor
Gross <tmgross@...ch.edu>, "nouveau@...ts.freedesktop.org"
<nouveau@...ts.freedesktop.org>, "linux-pci@...r.kernel.org"
<linux-pci@...r.kernel.org>, "rust-for-linux@...r.kernel.org"
<rust-for-linux@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, Jason
Gunthorpe <jgg@...dia.com>, Alex Williamson <alex.williamson@...hat.com>
Subject: Re: [PATCH 0/2] rust: pci: expose is_virtfn() and reject VFs in
nova-core
On 1.10.2025 4.45, John Hubbard wrote:
> On 9/30/25 6:39 PM, Alexandre Courbot wrote:
>> On Wed Oct 1, 2025 at 10:26 AM JST, John Hubbard wrote:
>>> On 9/30/25 5:26 PM, Alexandre Courbot wrote:
>>>> On Wed Oct 1, 2025 at 7:07 AM JST, John Hubbard wrote:
>>>>> Post-Kangrejos, the approach for NovaCore + VFIO has changed a bit: the
>>>>> idea now is that VFIO drivers, for NVIDIA GPUs that are supported by
>>>>> NovaCore, should bind directly to the GPU's VFs. (An earlier idea was to
>>>>> let NovaCore bind to the VFs, and then have NovaCore call into the upper
>>>>> (VFIO) module via Aux Bus, but this turns out to be awkward and is no
>>>>> longer in favor.) So, in order to support that:
>>>>>
>>>>> Nova-core must only bind to Physical Functions (PFs) and regular PCI
>>>>> devices, not to Virtual Functions (VFs) created through SR-IOV.
>>>>
>>>> Naive question: will guests also see the passed-through VF as a VF? If
>>>> so, wouldn't this change also prevents guests from using Nova?
>>>
pdev->virtfn (VF) is set to "true" when admin enabling VFs via the sysfs
and PF driver. Presumably, pdev->virtfn will be "false" all the time in
the guest.
>>> I'm also new to this area. I would expect that guests *must* see
>>> these as PFs, otherwise...nothing makes any sense.
>>
>> But if the guest sees the passed-through VF as a PF, won't it try to
>> do things it is not supposed to do like loading the GSP firmware (which
>> is managed by the host)?
>
The guest driver will read PMC_BOOT_1 and check PMC_BOOT_1_VGPU_VF flag
to tell if it is running on a VF or a PF.
https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/src/nvidia/arch/nvalloc/unix/src/os-hypervisor.c#L945
> Yes. A non-paravirtualized guest will attempt to behave just like a
> bare metal driver would behave. It's the job of the various layers
> of virtualization to intercept and modify such things appropriately.
>
> Looking ahead: if the VFIO experts come back and tell us that guests
> see these as VFs, then there is still a way forward, because we
> talked about loading nova-core with a "vfio_mode" kernel module
> parameter. So then it becomes "if vfio_mode, then skip VFs".
>
>
> thanks,
Powered by blists - more mailing lists