> From: Jason Gunthorpe
> Sent: Friday, September 27, 2024 6:57 AM
>
> On Thu, Sep 26, 2024 at 09:55:28AM -0300, Jason Gunthorpe wrote:
>
> > I'm not entirely sure yet what this whole 'mgr' component is actually
> > doing though.
>
> Looking more closely I think some of it is certainly appropri
On Thu, Sep 26, 2024 at 09:55:28AM -0300, Jason Gunthorpe wrote:
> I'm not entirely sure yet what this whole 'mgr' component is actually
> doing though.
Looking more closely I think some of it is certainly appropriate to be
in vfio. Like when something opens the VFIO device it should allocate
the
On Sun, Sep 22, 2024 at 05:49:40AM -0700, Zhi Wang wrote:
> diff --git a/include/drm/nvkm_vgpu_mgr_vfio.h
> b/include/drm/nvkm_vgpu_mgr_vfio.h
> index d9ed2cd202ff..5c2c650c2df9 100644
> --- a/include/drm/nvkm_vgpu_mgr_vfio.h
> +++ b/include/drm/nvkm_vgpu_mgr_vfio.h
> @@ -6,8 +6,13 @@
> #ifndef
On Sun, Sep 22, 2024 at 05:49:28AM -0700, Zhi Wang wrote:
> The registry object "RMSetSriovMode" is required to be set when vGPU is
> enabled.
>
> Set "RMSetSriovMode" to 1 when nvkm is loading the GSP firmware and
> initialize the GSP registry objects, if vGPU is enabled.
Also really weird, this
On Sun, Sep 22, 2024 at 05:49:27AM -0700, Zhi Wang wrote:
> +void nvkm_vgpu_mgr_populate_gsp_vf_info(struct nvkm_device *device,
> + void *info)
> +{
> + struct pci_dev *pdev = nvkm_to_pdev(device);
> + GspSystemInfo *gsp_info = info;
> + GSP_VF_INFO
On Sun, Sep 22, 2024 at 05:49:26AM -0700, Zhi Wang wrote:
> GSP firmware needs to know the number of max-supported vGPUs when
> initialization.
>
> The field of VF partition count in the GSP WPR2 is required to be set
> according to the number of max-supported vGPUs.
>
> Set the VF partition coun
On Thu, Sep 26, 2024 at 11:40:57AM -0300, Jason Gunthorpe wrote:
> On Thu, Sep 26, 2024 at 02:54:38PM +0200, Greg KH wrote:
> >
> > No, I do object to "we are ignoring the driver being proposed by the
> > developers involved for this hardware by adding to the old one instead"
> > which it seems li
On Thu, Sep 26, 2024 at 11:07:56AM -0700, Andy Ritger wrote:
>
> I hope and expect the nova and vgpu_mgr efforts to ultimately converge.
>
> First, for the fw ABI debacle: yes, it is unfortunate that we still don't
> have a stable ABI from GSP. We /are/ working on it, though there isn't
> anythi
I hope and expect the nova and vgpu_mgr efforts to ultimately converge.
First, for the fw ABI debacle: yes, it is unfortunate that we still don't
have a stable ABI from GSP. We /are/ working on it, though there isn't
anything to show, yet. FWIW, I expect the end result will be a much
simpler i
On Thu, Sep 26, 2024 at 02:54:38PM +0200, Greg KH wrote:
> That's fine, but again, do NOT make design decisions based on what you
> can, and can not, feel you can slide by one of these companies to get it
> into their old kernels. That's what I take objection to here.
It is not slide by. It is a
On 24/09/2024 10:12, Thomas Zimmermann wrote:
Call drm_client_setup_with_color_mode() to run the kernel's default
client setup for DRM. Set fbdev_probe in struct drm_driver, so that
the client setup can start the common fbdev client.
v5:
- select DRM_CLIENT_SELECTION
v3:
- add DRM_FBDEV_DMA_DRIV
On 24/09/2024 10:12, Thomas Zimmermann wrote:
Call drm_client_setup_with_fourcc() to run the kernel's default client
setup for DRM. Set fbdev_probe in struct drm_driver, so that the client
setup can start the common fbdev client.
v5:
- select DRM_CLIENT_SELECTION
v2:
- use drm_client_setup_with_
On 24/09/2024 10:13, Thomas Zimmermann wrote:
Rework fbdev probing to support fbdev_probe in struct drm_driver
and remove the old fb_probe callback. Provide an initializer macro
for struct drm_driver that sets the callback according to the kernel
configuration.
Call drm_client_setup() to run the
On Thu, Sep 26, 2024 at 02:54:38PM +0200, Greg KH wrote:
> On Thu, Sep 26, 2024 at 09:42:39AM -0300, Jason Gunthorpe wrote:
> > On Thu, Sep 26, 2024 at 11:14:27AM +0200, Greg KH wrote:
> > > On Mon, Sep 23, 2024 at 12:01:40PM -0300, Jason Gunthorpe wrote:
> > > > On Mon, Sep 23, 2024 at 10:49:07AM
Hi,
On 24/09/2024 10:13, Thomas Zimmermann wrote:
Store instances of drm_fb_helper and struct omap_fbdev separately.
This will allow omapdrm to use the common fbdev client, which allocates
its own instance of struct drm_fb_helper.
There is at most one instance of each per DRM device, so both ca
On Thu, Sep 26, 2024 at 06:43:44AM +, Tian, Kevin wrote:
> Then there comes an open whether VFIO is a right place to host such
> vendor specific provisioning interface. The existing mdev type based
> provisioning mechanism was considered a bad fit already.
> IIRC the previous discussion came
On Thu, Sep 26, 2024 at 09:42:39AM -0300, Jason Gunthorpe wrote:
> On Thu, Sep 26, 2024 at 11:14:27AM +0200, Greg KH wrote:
> > On Mon, Sep 23, 2024 at 12:01:40PM -0300, Jason Gunthorpe wrote:
> > > On Mon, Sep 23, 2024 at 10:49:07AM +0200, Danilo Krummrich wrote:
> > > > > 2. Proposal for upstream
On Thu, Sep 26, 2024 at 11:14:27AM +0200, Greg KH wrote:
> On Mon, Sep 23, 2024 at 12:01:40PM -0300, Jason Gunthorpe wrote:
> > On Mon, Sep 23, 2024 at 10:49:07AM +0200, Danilo Krummrich wrote:
> > > > 2. Proposal for upstream
> > > >
> > >
> > > What is the strategy in th
On 24/09/2024 10:12, Thomas Zimmermann wrote:
Call drm_client_setup() to run the kernel's default client setup
for DRM. Set fbdev_probe in struct drm_driver, so that the client
setup can start the common fbdev client.
The tidss driver specifies a preferred color mode of 32. As this
is the defaul
On Sun, Sep 22, 2024 at 05:49:23AM -0700, Zhi Wang wrote:
> NVIDIA GPU virtualization is a technology that allows multiple virtual
> machines (VMs) to share the power of a single GPU, enabling greater
> flexibility, efficiency, and cost-effectiveness in data centers and cloud
> environments.
>
> T
On Sun, Sep 22, 2024 at 05:49:24AM -0700, Zhi Wang wrote:
> nvkm is a HW abstraction layer(HAL) that initializes the HW and
> allows its clients to manipulate the GPU functions regardless of the
> generations of GPU HW. On the top layer, it provides generic APIs for a
> client to connect to NVKM, e
On Mon, Sep 23, 2024 at 12:01:40PM -0300, Jason Gunthorpe wrote:
> On Mon, Sep 23, 2024 at 10:49:07AM +0200, Danilo Krummrich wrote:
> > > 2. Proposal for upstream
> > >
> >
> > What is the strategy in the mid / long term with this?
> >
> > As you know, we're trying to mo
22 matches
Mail list logo
