From: Zhenyu Wang <zhenyuw.linux@gmail.com>
To: "Cavitt, Jonathan" <jonathan.cavitt@intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>
Cc: "Gupta, Saurabhg" <saurabhg.gupta@intel.com>,
"Zuo, Alex" <alex.zuo@intel.com>,
"Cavitt, Jonathan" <jonathan.cavitt@intel.com>
Subject: RE: [PATCH] drm/i915/gvt: Cast u64 array to u32 array
Date: Sat, 21 Feb 2026 23:34:25 +0800 [thread overview]
Message-ID: <87y0km9kla.fsf@dell-wzy> (raw)
In-Reply-To: <CH0PR11MB544431641B604EF86BC0CE7BE568A@CH0PR11MB5444.namprd11.prod.outlook.com>
"Cavitt, Jonathan" <jonathan.cavitt@intel.com> writes:
> -----Original Message-----
> From: Zhenyu Wang <zhenyuw.linux@gmail.com>
> Sent: Friday, February 20, 2026 6:41 AM
> To: Cavitt, Jonathan <jonathan.cavitt@intel.com>; intel-gfx@lists.freedesktop.org
> Cc: Gupta, Saurabhg <saurabhg.gupta@intel.com>; Zuo, Alex <alex.zuo@intel.com>; Cavitt, Jonathan <jonathan.cavitt@intel.com>
> Subject: RE: [PATCH] drm/i915/gvt: Cast u64 array to u32 array
>>
>> "Cavitt, Jonathan" <jonathan.cavitt@intel.com> writes:
>>
>> > -----Original Message-----
>> > From: Zhenyu Wang <zhenyuw.linux@gmail.com>
>> > Sent: Friday, February 13, 2026 2:42 AM
>> > To: Cavitt, Jonathan <jonathan.cavitt@intel.com>; intel-gfx@lists.freedesktop.org
>> > Cc: Gupta, Saurabhg <saurabhg.gupta@intel.com>; Zuo, Alex <alex.zuo@intel.com>; Cavitt, Jonathan <jonathan.cavitt@intel.com>
>> > Subject: Re: [PATCH] drm/i915/gvt: Cast u64 array to u32 array
>> >>
>> >> Jonathan Cavitt <jonathan.cavitt@intel.com> writes:
>> >>
>> >> > Static analysis issue:
>> >> >
>> >> > The u64 array workload->shadow_mm->ppgtt_mm.shadow_pdps is cast to a
>> >> > void pointer and passed as a u32 array to set_context_pdp_root_pointer
>> >> > as a part of update_shadow_pdps. This isn't wrong, per se, but we
>> >> > should properly cast it to an appropriately-sized u32 array before
>> >> > submission.
>> >> >
>> >> > Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
>> >> > ---
>> >> > drivers/gpu/drm/i915/gvt/scheduler.c | 6 ++++--
>> >> > 1 file changed, 4 insertions(+), 2 deletions(-)
>> >> >
>> >> > diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c b/drivers/gpu/drm/i915/gvt/scheduler.c
>> >> > index 15fdd514ca83..1a95c9f76faa 100644
>> >> > --- a/drivers/gpu/drm/i915/gvt/scheduler.c
>> >> > +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
>> >> > @@ -72,6 +72,7 @@ static void update_shadow_pdps(struct intel_vgpu_workload *workload)
>> >> > {
>> >> > struct execlist_ring_context *shadow_ring_context;
>> >> > struct intel_context *ctx = workload->req->context;
>> >> > + u32 pdp[8];
>> >> >
>> >> > if (WARN_ON(!workload->shadow_mm))
>> >> > return;
>> >> > @@ -79,9 +80,10 @@ static void update_shadow_pdps(struct intel_vgpu_workload *workload)
>> >> > if (WARN_ON(!atomic_read(&workload->shadow_mm->pincount)))
>> >> > return;
>> >> >
>> >> > + memcpy(pdp, workload->shadow_mm->ppgtt_mm.shadow_pdps,
>> >> > + sizeof(u64) * ARRAY_SIZE(workload->shadow_mm->ppgtt_mm.shadow_pdps));
>> >> > shadow_ring_context = (struct execlist_ring_context *)ctx->lrc_reg_state;
>> >> > - set_context_pdp_root_pointer(shadow_ring_context,
>> >> > - (void *)workload->shadow_mm->ppgtt_mm.shadow_pdps);
>> >> > + set_context_pdp_root_pointer(shadow_ring_context, pdp);
>> >> > }
>> >> >
>> >>
>> >> I think we'd better just cast the type instead of extra copy.
>> >
>> > I'm not certain that would resolve the static analysis issue.
>> >
>> > To specify, the static analyzer is complaining that we're taking a pointer to an object
>> > of type 'unsigned long long' and dereferencing it as an object of type 'unsigned int'.
>> > The analyzer is getting uppity about this causing unexpected results depending on
>> > machine endianness (which... it won't, but the static analyzer doesn't know that),
>> > so I suspect the only way to get it to calm down is to do a direct memory copy, as
>> > seen here. Casting the type would just result in the same static analysis issue.
>> >
>> > This is the part of the email that I'd throw around terms like "strict aliasing" and
>> > "type punning" if I thought they were relevant. They probably aren't, though.
>> >
>>
>> I really don't want to do extra copy as this is hot path for every exec submission.
>> How about below change?
>> Btw, which static analysis you're using? Looks I don't get such warning
>> with either sparse or smatch...
>
> I'm not allowed to go into detail about that. Sorry.
>
>>
>> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c b/drivers/gpu/drm/i915/gvt/scheduler.c
>> index 63ad1fed525a..3f09d6440827 100644
>> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
>> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
>> @@ -1,3 +1,4 @@
>> +
>> /*
>> * Copyright(c) 2011-2016 Intel Corporation. All rights reserved.
>> *
>> @@ -54,7 +55,7 @@
>>
>> static void set_context_pdp_root_pointer(
>> struct execlist_ring_context *ring_context,
>> - u32 pdp[8])
>> + u32 *pdp)
>> {
>> int i;
>>
>> @@ -75,7 +76,7 @@ static void update_shadow_pdps(struct intel_vgpu_workload *workload)
>>
>> shadow_ring_context = (struct execlist_ring_context *)ctx->lrc_reg_state;
>> set_context_pdp_root_pointer(shadow_ring_context,
>> - (void *)workload->shadow_mm->ppgtt_mm.shadow_pdps);
>> + (u32 *)workload->shadow_mm->ppgtt_mm.shadow_pdps);
>> }
>
> This still results in us casting a u64 pointer to a u32 pointer.
>
It's normal in some driver cases we really need to access 32b fields indeed..
> If this change is undesirable, I can mark it as a false positive on my end.
Above version should be better but original one doesn't hurt... so in
case of private tool, please mark it so. Thanks.
prev parent reply other threads:[~2026-02-21 15:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-12 19:41 [PATCH] drm/i915/gvt: Cast u64 array to u32 array Jonathan Cavitt
2026-02-12 21:05 ` ✓ i915.CI.BAT: success for " Patchwork
2026-02-12 23:48 ` ✗ i915.CI.Full: failure " Patchwork
2026-02-13 10:42 ` [PATCH] " Zhenyu Wang
2026-02-13 16:27 ` Cavitt, Jonathan
2026-02-19 20:43 ` Cavitt, Jonathan
2026-02-24 7:29 ` Krzysztof Karas
2026-02-20 14:40 ` Zhenyu Wang
2026-02-20 16:03 ` Cavitt, Jonathan
2026-02-21 15:34 ` Zhenyu Wang [this message]
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=87y0km9kla.fsf@dell-wzy \
--to=zhenyuw.linux@gmail.com \
--cc=alex.zuo@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jonathan.cavitt@intel.com \
--cc=saurabhg.gupta@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox