All of lore.kernel.org
 help / color / mirror / Atom feed
From: zhoucm1 <david1.zhou-5C7GfCeVMHo@public.gmane.org>
To: "Ding, Pixel" <Pixel.Ding-5C7GfCeVMHo@public.gmane.org>,
	"amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: [PATCH 2/2] drm/amdgpu/virt: schedule work to handle vm fault for VF
Date: Mon, 6 Feb 2017 16:36:01 +0800	[thread overview]
Message-ID: <58983571.9010009@amd.com> (raw)
In-Reply-To: <B238C54C-4230-411A-890F-00FDDBED699B-5C7GfCeVMHo@public.gmane.org>

Hi Pixel,
I got your mean just now, since your VF must use KIQ to read/write 
registers, which use fence_wait to wait reading register completed.
The alternative way is implementing a new kiq reading/writing register 
way by using udelay instead of fence wait when reading/writing register 
in interrupt context.

Regards,
David Zhou

On 2017年02月06日 15:55, Ding, Pixel wrote:
> Thanks you for your comments, David. I totally agree on your point.
>
> However, The VM fault status registers record the latest VM fault info no matter when they’re changed, that’s what we care about since we don’t handle too much for VM fault even in bare metal system.
>
> On the other hand, what do you think if we insist to sleep in the interrupt context and let the driver runs into a software bug?
>
> The VM registers are shared among all VFs and we don’t have a copy for each in hardware, I think there's no other way to access them in this case. Do you have any suggestion?
>
> —
> Sincerely Yours,
> Pixel
>
>
>
>
>
>
>
>
> On 06/02/2017, 3:33 PM, "Zhou, David(ChunMing)" <David1.Zhou@amd.com> wrote:
>
>> INIT_WORK(&work->base, gmc_v8_0_vm_fault_sched);
>> However VF is used or not, schedule work shouldn't handle registers reading for interrupt, especially for status register, which could have been changed when you handle it in schedule work after interrupt.
>>
>> Regards,
>> David Zhou
>>
>> -----Original Message-----
>> From: amd-gfx [mailto:amd-gfx-bounces@lists.freedesktop.org] On Behalf Of Pixel Ding
>> Sent: Monday, February 06, 2017 3:00 PM
>> To: amd-gfx@lists.freedesktop.org
>> Cc: Ding, Pixel <Pixel.Ding@amd.com>
>> Subject: [PATCH 2/2] drm/amdgpu/virt: schedule work to handle vm fault for VF
>>
>> VF uses KIQ to access registers that invoking fence_wait to get the accessing completed. When VM fault occurs, the driver can't sleep in interrupt context.
>>
>> For some test cases, VM fault is 'legal' and shouldn't cause driver soft lockup.
>>
>> Signed-off-by: Pixel Ding <Pixel.Ding@amd.com>
>> ---
>> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 46 ++++++++++++++++++++++++++++++++---
>> 1 file changed, 43 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>> index 7669b32..75c913f 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>> @@ -1231,9 +1231,9 @@ static int gmc_v8_0_vm_fault_interrupt_state(struct amdgpu_device *adev,
>> 	return 0;
>> }
>>
>> -static int gmc_v8_0_process_interrupt(struct amdgpu_device *adev,
>> -				      struct amdgpu_irq_src *source,
>> -				      struct amdgpu_iv_entry *entry)
>> +static int gmc_v8_0_process_vm_fault(struct amdgpu_device *adev,
>> +				     struct amdgpu_irq_src *source,
>> +				     struct amdgpu_iv_entry *entry)
>> {
>> 	u32 addr, status, mc_client;
>>
>> @@ -1262,6 +1262,46 @@ static int gmc_v8_0_process_interrupt(struct amdgpu_device *adev,
>> 	return 0;
>> }
>>
>> +struct gmc_vm_fault_work {
>> +	struct work_struct      base;
>> +	struct amdgpu_device    *adev;
>> +	struct amdgpu_irq_src   *source;
>> +	struct amdgpu_iv_entry  *entry;
>> +};
>> +
>> +static void gmc_v8_0_vm_fault_sched(struct work_struct *work) {
>> +	struct gmc_vm_fault_work *vm_work =
>> +		container_of(work, struct gmc_vm_fault_work, base);
>> +	struct amdgpu_device *adev = vm_work->adev;
>> +	struct amdgpu_irq_src *source = vm_work->source;
>> +	struct amdgpu_iv_entry *entry = vm_work->entry;
>> +
>> +	gmc_v8_0_process_vm_fault(adev, source, entry);
>> +
>> +	kfree(vm_work);
>> +}
>> +
>> +static int gmc_v8_0_process_interrupt(struct amdgpu_device *adev,
>> +				      struct amdgpu_irq_src *source,
>> +				      struct amdgpu_iv_entry *entry) {
>> +	struct gmc_vm_fault_work *work = NULL;
>> +
>> +	if (amdgpu_sriov_vf(adev)) {
>> +		work = kmalloc(sizeof(struct gmc_vm_fault_work), GFP_ATOMIC);
>> +		if (!work)
>> +			return -ENOMEM;
>> +		INIT_WORK(&work->base, gmc_v8_0_vm_fault_sched);
>> +		work->adev = adev;
>> +		work->source = source;
>> +		work->entry = entry;
>> +		return schedule_work(&work->base);
>> +	}
>> +
>> +	return gmc_v8_0_process_vm_fault(adev, source, entry); }
>> +
>> static void fiji_update_mc_medium_grain_clock_gating(struct amdgpu_device *adev,
>> 						     bool enable)
>> {
>> --
>> 2.7.4
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  parent reply	other threads:[~2017-02-06  8:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-06  7:00 [PATCH 2/2] drm/amdgpu/virt: schedule work to handle vm fault for VF Pixel Ding
     [not found] ` <1486364403-29374-1-git-send-email-Pixel.Ding-5C7GfCeVMHo@public.gmane.org>
2017-02-06  7:33   ` Zhou, David(ChunMing)
     [not found]     ` <MWHPR1201MB020685071A36546095A5A248B4400-3iK1xFAIwjrUF/YbdlDdgWrFom/aUZj6nBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
2017-02-06  7:55       ` Ding, Pixel
     [not found]         ` <B238C54C-4230-411A-890F-00FDDBED699B-5C7GfCeVMHo@public.gmane.org>
2017-02-06  8:36           ` zhoucm1 [this message]
     [not found]             ` <58983571.9010009-5C7GfCeVMHo@public.gmane.org>
2017-02-06  8:56               ` Christian König
     [not found]                 ` <83606ab6-6cf4-fcb6-31e9-a30d35339497-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
2017-02-07  5:30                   ` Ding, Pixel

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=58983571.9010009@amd.com \
    --to=david1.zhou-5c7gfcevmho@public.gmane.org \
    --cc=Pixel.Ding-5C7GfCeVMHo@public.gmane.org \
    --cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.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.