All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König via Virtualization" <virtualization@lists.linux-foundation.org>
To: Dmitry Osipenko <dmitry.osipenko@collabora.com>,
	David Airlie <airlied@linux.ie>, Huang Rui <ray.huang@amd.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Trigger Huang <Trigger.Huang@gmail.com>,
	Gert Wollny <gert.wollny@collabora.com>,
	Antonio Caggiano <antonio.caggiano@collabora.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	virtualization@lists.linux-foundation.org,
	Dmitry Osipenko <digetx@gmail.com>,
	kernel@collabora.com
Subject: Re: [PATCH v1] drm/ttm: Refcount allocated tail pages
Date: Mon, 15 Aug 2022 12:14:00 +0200	[thread overview]
Message-ID: <4fcc4739-2da9-1b89-209c-876129604d7d@amd.com> (raw)
In-Reply-To: <8caf3008-dcf3-985a-631e-e019b277c6f0@amd.com>

Am 15.08.22 um 12:11 schrieb Christian König:
> Am 15.08.22 um 12:09 schrieb Dmitry Osipenko:
>> On 8/15/22 13:05, Christian König wrote:
>>> Am 15.08.22 um 11:54 schrieb Dmitry Osipenko:
>>>> Higher order pages allocated using alloc_pages() aren't refcounted and
>>>> they
>>>> need to be refcounted, otherwise it's impossible to map them by 
>>>> KVM. This
>>>> patch sets the refcount of the tail pages and fixes the KVM memory
>>>> mapping
>>>> faults.
>>>>
>>>> Without this change guest virgl driver can't map host buffers into 
>>>> guest
>>>> and can't provide OpenGL 4.5 profile support to the guest. The host
>>>> mappings are also needed for enabling the Venus driver using host GPU
>>>> drivers that are utilizing TTM.
>>>>
>>>> Based on a patch proposed by Trigger Huang.
>>> Well I can't count how often I have repeated this: This is an 
>>> absolutely
>>> clear NAK!
>>>
>>> TTM pages are not reference counted in the first place and because of
>>> this giving them to virgl is illegal.
>> A? The first page is refcounted when allocated, the tail pages are not.
>
> No they aren't. The first page is just by coincident initialized with 
> a refcount of 1. This refcount is completely ignored and not used at all.
>
> Incrementing the reference count and by this mapping the page into 
> some other address space is illegal and corrupts the internal state 
> tracking of TTM.

See this comment in the source code as well:

         /* Don't set the __GFP_COMP flag for higher order allocations.
          * Mapping pages directly into an userspace process and calling
          * put_page() on a TTM allocated page is illegal.
          */

I have absolutely no idea how somebody had the idea he could do this.

Regards,
Christian.

>
>>> Please immediately stop this completely broken approach. We have
>>> discussed this multiple times now.
>> Could you please give me a link to these discussions?
>
> Not of hand, please search the dri-devel list for similar patches. 
> This was brought up multiple times now.
>
> Regards,
> Christian.

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig@amd.com>
To: Dmitry Osipenko <dmitry.osipenko@collabora.com>,
	David Airlie <airlied@linux.ie>, Huang Rui <ray.huang@amd.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Trigger Huang <Trigger.Huang@gmail.com>,
	Gert Wollny <gert.wollny@collabora.com>,
	Antonio Caggiano <antonio.caggiano@collabora.com>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	Dmitry Osipenko <digetx@gmail.com>,
	kvm@vger.kernel.org, kernel@collabora.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [PATCH v1] drm/ttm: Refcount allocated tail pages
Date: Mon, 15 Aug 2022 12:14:00 +0200	[thread overview]
Message-ID: <4fcc4739-2da9-1b89-209c-876129604d7d@amd.com> (raw)
In-Reply-To: <8caf3008-dcf3-985a-631e-e019b277c6f0@amd.com>

Am 15.08.22 um 12:11 schrieb Christian König:
> Am 15.08.22 um 12:09 schrieb Dmitry Osipenko:
>> On 8/15/22 13:05, Christian König wrote:
>>> Am 15.08.22 um 11:54 schrieb Dmitry Osipenko:
>>>> Higher order pages allocated using alloc_pages() aren't refcounted and
>>>> they
>>>> need to be refcounted, otherwise it's impossible to map them by 
>>>> KVM. This
>>>> patch sets the refcount of the tail pages and fixes the KVM memory
>>>> mapping
>>>> faults.
>>>>
>>>> Without this change guest virgl driver can't map host buffers into 
>>>> guest
>>>> and can't provide OpenGL 4.5 profile support to the guest. The host
>>>> mappings are also needed for enabling the Venus driver using host GPU
>>>> drivers that are utilizing TTM.
>>>>
>>>> Based on a patch proposed by Trigger Huang.
>>> Well I can't count how often I have repeated this: This is an 
>>> absolutely
>>> clear NAK!
>>>
>>> TTM pages are not reference counted in the first place and because of
>>> this giving them to virgl is illegal.
>> A? The first page is refcounted when allocated, the tail pages are not.
>
> No they aren't. The first page is just by coincident initialized with 
> a refcount of 1. This refcount is completely ignored and not used at all.
>
> Incrementing the reference count and by this mapping the page into 
> some other address space is illegal and corrupts the internal state 
> tracking of TTM.

See this comment in the source code as well:

         /* Don't set the __GFP_COMP flag for higher order allocations.
          * Mapping pages directly into an userspace process and calling
          * put_page() on a TTM allocated page is illegal.
          */

I have absolutely no idea how somebody had the idea he could do this.

Regards,
Christian.

>
>>> Please immediately stop this completely broken approach. We have
>>> discussed this multiple times now.
>> Could you please give me a link to these discussions?
>
> Not of hand, please search the dri-devel list for similar patches. 
> This was brought up multiple times now.
>
> Regards,
> Christian.


WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig@amd.com>
To: Dmitry Osipenko <dmitry.osipenko@collabora.com>,
	David Airlie <airlied@linux.ie>, Huang Rui <ray.huang@amd.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Trigger Huang <Trigger.Huang@gmail.com>,
	Gert Wollny <gert.wollny@collabora.com>,
	Antonio Caggiano <antonio.caggiano@collabora.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	virtualization@lists.linux-foundation.org,
	Dmitry Osipenko <digetx@gmail.com>,
	kernel@collabora.com
Subject: Re: [PATCH v1] drm/ttm: Refcount allocated tail pages
Date: Mon, 15 Aug 2022 12:14:00 +0200	[thread overview]
Message-ID: <4fcc4739-2da9-1b89-209c-876129604d7d@amd.com> (raw)
In-Reply-To: <8caf3008-dcf3-985a-631e-e019b277c6f0@amd.com>

Am 15.08.22 um 12:11 schrieb Christian König:
> Am 15.08.22 um 12:09 schrieb Dmitry Osipenko:
>> On 8/15/22 13:05, Christian König wrote:
>>> Am 15.08.22 um 11:54 schrieb Dmitry Osipenko:
>>>> Higher order pages allocated using alloc_pages() aren't refcounted and
>>>> they
>>>> need to be refcounted, otherwise it's impossible to map them by 
>>>> KVM. This
>>>> patch sets the refcount of the tail pages and fixes the KVM memory
>>>> mapping
>>>> faults.
>>>>
>>>> Without this change guest virgl driver can't map host buffers into 
>>>> guest
>>>> and can't provide OpenGL 4.5 profile support to the guest. The host
>>>> mappings are also needed for enabling the Venus driver using host GPU
>>>> drivers that are utilizing TTM.
>>>>
>>>> Based on a patch proposed by Trigger Huang.
>>> Well I can't count how often I have repeated this: This is an 
>>> absolutely
>>> clear NAK!
>>>
>>> TTM pages are not reference counted in the first place and because of
>>> this giving them to virgl is illegal.
>> A? The first page is refcounted when allocated, the tail pages are not.
>
> No they aren't. The first page is just by coincident initialized with 
> a refcount of 1. This refcount is completely ignored and not used at all.
>
> Incrementing the reference count and by this mapping the page into 
> some other address space is illegal and corrupts the internal state 
> tracking of TTM.

See this comment in the source code as well:

         /* Don't set the __GFP_COMP flag for higher order allocations.
          * Mapping pages directly into an userspace process and calling
          * put_page() on a TTM allocated page is illegal.
          */

I have absolutely no idea how somebody had the idea he could do this.

Regards,
Christian.

>
>>> Please immediately stop this completely broken approach. We have
>>> discussed this multiple times now.
>> Could you please give me a link to these discussions?
>
> Not of hand, please search the dri-devel list for similar patches. 
> This was brought up multiple times now.
>
> Regards,
> Christian.


  reply	other threads:[~2022-08-15 10:14 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-15  9:54 [PATCH v1] drm/ttm: Refcount allocated tail pages Dmitry Osipenko
2022-08-15  9:54 ` Dmitry Osipenko
2022-08-15 10:05 ` Christian König
2022-08-15 10:05   ` Christian König
2022-08-15 10:05   ` Christian König via Virtualization
2022-08-15 10:09   ` Dmitry Osipenko
2022-08-15 10:09     ` Dmitry Osipenko
2022-08-15 10:11     ` Christian König
2022-08-15 10:11       ` Christian König
2022-08-15 10:11       ` Christian König via Virtualization
2022-08-15 10:14       ` Christian König via Virtualization [this message]
2022-08-15 10:14         ` Christian König
2022-08-15 10:14         ` Christian König
2022-08-15 10:18         ` Dmitry Osipenko
2022-08-15 10:18           ` Dmitry Osipenko
2022-08-15 10:42           ` Christian König
2022-08-15 10:42             ` Christian König
2022-08-15 10:42             ` Christian König via Virtualization
2022-08-15 10:47           ` Dmitry Osipenko
2022-08-15 10:47             ` Dmitry Osipenko
2022-08-15 10:51             ` Christian König
2022-08-15 10:51               ` Christian König
2022-08-15 10:51               ` Christian König via Virtualization
2022-08-15 11:19               ` Dmitry Osipenko
2022-08-15 11:19                 ` Dmitry Osipenko
2022-08-15 11:28                 ` Christian König
2022-08-15 11:28                   ` Christian König
2022-08-15 11:28                   ` Christian König via Virtualization
2022-08-15 11:50                   ` Dmitry Osipenko
2022-08-15 11:50                     ` Dmitry Osipenko
2022-08-15 13:06                     ` Christian König
2022-08-15 13:06                       ` Christian König
2022-08-15 13:06                       ` Christian König via Virtualization
2022-08-15 13:45                       ` Dmitry Osipenko
2022-08-15 13:45                         ` Dmitry Osipenko
2022-08-15 13:53                         ` Christian König
2022-08-15 13:53                           ` Christian König
2022-08-15 13:53                           ` Christian König via Virtualization
2022-08-15 14:57                           ` Dmitry Osipenko
2022-08-15 14:57                             ` Dmitry Osipenko
2022-08-15 15:54                             ` Dmitry Osipenko
2022-08-15 15:54                               ` Dmitry Osipenko
2022-08-17 22:57                               ` Dmitry Osipenko
2022-08-17 22:57                                 ` Dmitry Osipenko
2022-08-17 23:13                                 ` Dmitry Osipenko
2022-08-17 23:13                                   ` Dmitry Osipenko
2022-08-18  9:41                                   ` Christian König
2022-08-18  9:41                                     ` Christian König
2022-08-18  9:41                                     ` Christian König via Virtualization
2023-01-11 17:05                                     ` Sean Christopherson
2023-01-11 17:05                                       ` Sean Christopherson
2023-01-11 21:24                                       ` Dmitry Osipenko
2023-01-11 21:24                                         ` Dmitry Osipenko
2022-09-06 20:01   ` Daniel Vetter
2022-09-06 20:01     ` Daniel Vetter
2022-09-06 20:01     ` Daniel Vetter
2022-09-06 20:05     ` Daniel Vetter
2022-09-06 20:05       ` Daniel Vetter
2022-09-07  6:48       ` Christian König via Virtualization
2022-09-07  6:48         ` Christian König
2023-01-11 17:13       ` Sean Christopherson
2022-09-08 11:04     ` Rob Clark
2022-09-08 11:04       ` Rob Clark

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4fcc4739-2da9-1b89-209c-876129604d7d@amd.com \
    --to=virtualization@lists.linux-foundation.org \
    --cc=Trigger.Huang@gmail.com \
    --cc=airlied@linux.ie \
    --cc=antonio.caggiano@collabora.com \
    --cc=christian.koenig@amd.com \
    --cc=daniel@ffwll.ch \
    --cc=digetx@gmail.com \
    --cc=dmitry.osipenko@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gert.wollny@collabora.com \
    --cc=kernel@collabora.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ray.huang@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.