All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Osipenko <dmitry.osipenko@collabora.com>
To: "Christian König" <christian.koenig@amd.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>,
	"Paolo Bonzini" <pbonzini@redhat.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 18:54:47 +0300	[thread overview]
Message-ID: <6effcd33-8cc3-a4e0-3608-b9cef7a76da7@collabora.com> (raw)
In-Reply-To: <c9d89644-409e-0363-69f0-a3b8f2ef0ae4@collabora.com>

On 8/15/22 17:57, Dmitry Osipenko wrote:
> On 8/15/22 16:53, Christian König wrote:
>> Am 15.08.22 um 15:45 schrieb Dmitry Osipenko:
>>> [SNIP]
>>>> Well that comment sounds like KVM is doing the right thing, so I'm
>>>> wondering what exactly is going on here.
>>> KVM actually doesn't hold the page reference, it takes the temporal
>>> reference during page fault and then drops the reference once page is
>>> mapped, IIUC. Is it still illegal for TTM? Or there is a possibility for
>>> a race condition here?
>>>
>>
>> Well the question is why does KVM grab the page reference in the first
>> place?
>>
>> If that is to prevent the mapping from changing then yes that's illegal
>> and won't work. It can always happen that you grab the address, solve
>> the fault and then immediately fault again because the address you just
>> grabbed is invalidated.
>>
>> If it's for some other reason than we should probably investigate if we
>> shouldn't stop doing this.
> 
> CC: +Paolo Bonzini who introduced this code
> 
> commit add6a0cd1c5ba51b201e1361b05a5df817083618
> Author: Paolo Bonzini <pbonzini@redhat.com>
> Date:   Tue Jun 7 17:51:18 2016 +0200
> 
>     KVM: MMU: try to fix up page faults before giving up
> 
>     The vGPU folks would like to trap the first access to a BAR by setting
>     vm_ops on the VMAs produced by mmap-ing a VFIO device.  The fault
> handler
>     then can use remap_pfn_range to place some non-reserved pages in the
> VMA.
> 
>     This kind of VM_PFNMAP mapping is not handled by KVM, but follow_pfn
>     and fixup_user_fault together help supporting it.  The patch also
> supports
>     VM_MIXEDMAP vmas where the pfns are not reserved and thus subject to
>     reference counting.
> 
> @Paolo,
> https://lore.kernel.org/dri-devel/73e5ed8d-0d25-7d44-8fa2-e1d61b1f5a04@amd.com/T/#m7647ce5f8c4749599d2c6bc15a2b45f8d8cf8154
> 

If we need to bump the refcount only for VM_MIXEDMAP and not for
VM_PFNMAP, then perhaps we could add a flag for that to the kvm_main
code that will denote to kvm_release_page_clean whether it needs to put
the page?

-- 
Best regards,
Dmitry

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <dmitry.osipenko@collabora.com>
To: "Christian König" <christian.koenig@amd.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>,
	"Paolo Bonzini" <pbonzini@redhat.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 18:54:47 +0300	[thread overview]
Message-ID: <6effcd33-8cc3-a4e0-3608-b9cef7a76da7@collabora.com> (raw)
In-Reply-To: <c9d89644-409e-0363-69f0-a3b8f2ef0ae4@collabora.com>

On 8/15/22 17:57, Dmitry Osipenko wrote:
> On 8/15/22 16:53, Christian König wrote:
>> Am 15.08.22 um 15:45 schrieb Dmitry Osipenko:
>>> [SNIP]
>>>> Well that comment sounds like KVM is doing the right thing, so I'm
>>>> wondering what exactly is going on here.
>>> KVM actually doesn't hold the page reference, it takes the temporal
>>> reference during page fault and then drops the reference once page is
>>> mapped, IIUC. Is it still illegal for TTM? Or there is a possibility for
>>> a race condition here?
>>>
>>
>> Well the question is why does KVM grab the page reference in the first
>> place?
>>
>> If that is to prevent the mapping from changing then yes that's illegal
>> and won't work. It can always happen that you grab the address, solve
>> the fault and then immediately fault again because the address you just
>> grabbed is invalidated.
>>
>> If it's for some other reason than we should probably investigate if we
>> shouldn't stop doing this.
> 
> CC: +Paolo Bonzini who introduced this code
> 
> commit add6a0cd1c5ba51b201e1361b05a5df817083618
> Author: Paolo Bonzini <pbonzini@redhat.com>
> Date:   Tue Jun 7 17:51:18 2016 +0200
> 
>     KVM: MMU: try to fix up page faults before giving up
> 
>     The vGPU folks would like to trap the first access to a BAR by setting
>     vm_ops on the VMAs produced by mmap-ing a VFIO device.  The fault
> handler
>     then can use remap_pfn_range to place some non-reserved pages in the
> VMA.
> 
>     This kind of VM_PFNMAP mapping is not handled by KVM, but follow_pfn
>     and fixup_user_fault together help supporting it.  The patch also
> supports
>     VM_MIXEDMAP vmas where the pfns are not reserved and thus subject to
>     reference counting.
> 
> @Paolo,
> https://lore.kernel.org/dri-devel/73e5ed8d-0d25-7d44-8fa2-e1d61b1f5a04@amd.com/T/#m7647ce5f8c4749599d2c6bc15a2b45f8d8cf8154
> 

If we need to bump the refcount only for VM_MIXEDMAP and not for
VM_PFNMAP, then perhaps we could add a flag for that to the kvm_main
code that will denote to kvm_release_page_clean whether it needs to put
the page?

-- 
Best regards,
Dmitry

  reply	other threads:[~2022-08-15 15:54 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
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 [this message]
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=6effcd33-8cc3-a4e0-3608-b9cef7a76da7@collabora.com \
    --to=dmitry.osipenko@collabora.com \
    --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=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=pbonzini@redhat.com \
    --cc=ray.huang@amd.com \
    --cc=virtualization@lists.linux-foundation.org \
    /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.