From: Michal Wajdeczko <michal.wajdeczko@intel.com>
To: Matthew Brost <matthew.brost@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 9/9] drm/xe/vf: Custom HuC initialization if VF
Date: Thu, 20 Jun 2024 01:34:43 +0200 [thread overview]
Message-ID: <0e854a3e-b552-474e-8080-1e139e466509@intel.com> (raw)
In-Reply-To: <ZnNofcyDFwoy7MDi@DUT025-TGLU.fm.intel.com>
On 20.06.2024 01:23, Matthew Brost wrote:
> On Thu, Jun 20, 2024 at 01:14:29AM +0200, Michal Wajdeczko wrote:
>>
>>
>> On 20.06.2024 01:11, Matthew Brost wrote:
>>> On Wed, Jun 19, 2024 at 11:45:57PM +0200, Michal Wajdeczko wrote:
>>>> The HuC firmware is loaded and initialized by the PF driver. Make
>>>> sure VF driver performs only limited data structure initialization.
>>>>
>>>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>>> ---
>>>> drivers/gpu/drm/xe/xe_huc.c | 4 ++++
>>>> 1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/xe/xe_huc.c b/drivers/gpu/drm/xe/xe_huc.c
>>>> index 6238fb354914..c88761fe31c9 100644
>>>> --- a/drivers/gpu/drm/xe/xe_huc.c
>>>> +++ b/drivers/gpu/drm/xe/xe_huc.c
>>>> @@ -21,6 +21,7 @@
>>>> #include "xe_guc.h"
>>>> #include "xe_map.h"
>>>> #include "xe_mmio.h"
>>>> +#include "xe_sriov.h"
>>>> #include "xe_uc_fw.h"
>>>>
>>>> static struct xe_gt *
>>>> @@ -92,6 +93,9 @@ int xe_huc_init(struct xe_huc *huc)
>>>> if (!xe_uc_fw_is_enabled(&huc->fw))
>>>> return 0;
>>>>
>>>> + if (IS_SRIOV_VF(xe))
>>>> + return 0;
>>>> +
>>>
>>> With this change I assume the main part of xe_huc_auth is never called
>>> on a VF?
>>>
>>> Does xe_uc_fw_is_loadable return false on a VF?
>>
>> yes, as on VF it is marked as PRELOADED, so:
>>
>> static inline bool xe_uc_fw_is_loadable(struct xe_uc_fw *uc_fw)
>> {
>> return __xe_uc_fw_status(uc_fw) >= XE_UC_FIRMWARE_LOADABLE &&
>> __xe_uc_fw_status(uc_fw) != XE_UC_FIRMWARE_PRELOADED;
>> }
>>
>> returns false
>>
>
> To be clear, I'd add asserts to parts of functions which should not be
> executed on a VF if it is expected to short circuit on another function.
>
> e.g.
>
> xe_huc_auth()
> if (!xe_uc_fw_is_loadable)
> return
>
> xe_assert(!VF);
hmm, but then we might pollute the whole driver with such asserts, as VF
really can do only limited stuff
besides, we already track any unwanted access to unavailable registers
from VFs in xe_mmio_read32()
if (!reg.vf && IS_SRIOV_VF(gt_to_xe(gt)))
val = xe_gt_sriov_vf_read32(gt, reg);
...
xe_gt_WARN(gt, IS_ENABLED(CONFIG_DRM_XE_DEBUG),
"VF is trying to read an inaccessible register %#x+%#x\n",
reg.addr, addr - reg.addr);
and I'm planning to add similar code (or xe_assert) to xe_mmio_write()
finally, GuC will report errors if VF will try to execute privileged action
so IMO spreading xe_assert(!VF) all over is not ideal
>
> This patch LGTM to me though. With that:
> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
>
>>>
>>> Matt
>>>
>>>> if (huc->fw.has_gsc_headers) {
>>>> ret = huc_alloc_gsc_pkt(huc);
>>>> if (ret)
>>>> --
>>>> 2.43.0
>>>>
next prev parent reply other threads:[~2024-06-19 23:35 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-19 21:45 [PATCH 0/9] Adapt the driver to boot on the VF device Michal Wajdeczko
2024-06-19 21:45 ` [PATCH 1/9] drm/xe/vf: Disable features that do not apply to VFs Michal Wajdeczko
2024-06-20 9:17 ` Piotr Piórkowski
2024-06-20 10:05 ` Michal Wajdeczko
2024-06-20 10:01 ` [PATCH v2 " Michal Wajdeczko
2024-06-20 10:06 ` Piotr Piórkowski
2024-06-19 21:45 ` [PATCH 2/9] drm/xe/vf: Don't run any save-restore RTP actions if VF Michal Wajdeczko
2024-06-20 9:20 ` Piotr Piórkowski
2024-06-20 17:30 ` Matt Roper
2024-06-19 21:45 ` [PATCH 3/9] drm/xe/vf: Don't apply tile workarounds " Michal Wajdeczko
2024-06-20 9:21 ` Piotr Piórkowski
2024-06-20 17:31 ` Matt Roper
2024-06-19 21:45 ` [PATCH 4/9] drm/xe/vf: Don't change hwe IRQ masks if using memory IRQs Michal Wajdeczko
2024-06-20 9:29 ` Piotr Piórkowski
2024-06-19 21:45 ` [PATCH 5/9] drm/xe/vf: Don't initialize OA if VF Michal Wajdeczko
2024-06-19 21:56 ` Dixit, Ashutosh
2024-06-19 22:10 ` Dixit, Ashutosh
2024-06-19 22:40 ` Michal Wajdeczko
2024-06-19 22:57 ` Dixit, Ashutosh
2024-06-19 23:01 ` Michal Wajdeczko
2024-06-19 21:45 ` [PATCH 6/9] drm/xe/vf: Don't support gtidle " Michal Wajdeczko
2024-06-20 9:38 ` Piotr Piórkowski
2024-06-19 21:45 ` [PATCH 7/9] drm/xe/vf: Don't use register based TLB invalidation " Michal Wajdeczko
2024-06-19 23:13 ` Matthew Brost
2024-06-19 23:25 ` Michal Wajdeczko
2024-06-20 10:07 ` Piotr Piórkowski
2024-06-19 21:45 ` [PATCH 8/9] drm/xe/vf: Skip engine ring enabling " Michal Wajdeczko
2024-06-20 10:03 ` Piotr Piórkowski
2024-06-19 21:45 ` [PATCH 9/9] drm/xe/vf: Custom HuC initialization " Michal Wajdeczko
2024-06-19 23:11 ` Matthew Brost
2024-06-19 23:14 ` Michal Wajdeczko
2024-06-19 23:23 ` Matthew Brost
2024-06-19 23:34 ` Michal Wajdeczko [this message]
2024-06-20 1:59 ` Matthew Brost
2024-06-19 21:51 ` ✓ CI.Patch_applied: success for Adapt the driver to boot on the VF device Patchwork
2024-06-19 21:51 ` ✓ CI.checkpatch: " Patchwork
2024-06-19 21:52 ` ✓ CI.KUnit: " Patchwork
2024-06-19 22:04 ` ✓ CI.Build: " Patchwork
2024-06-19 22:06 ` ✗ CI.Hooks: failure " Patchwork
2024-06-19 22:07 ` ✓ CI.checksparse: success " Patchwork
2024-06-19 22:22 ` ✗ CI.BAT: failure " Patchwork
2024-06-20 6:28 ` Michal Wajdeczko
2024-06-20 6:16 ` ✗ CI.FULL: " Patchwork
2024-06-20 6:28 ` ✓ CI.Patch_applied: success for Adapt the driver to boot on the VF device (rev2) Patchwork
2024-06-20 6:28 ` ✓ CI.checkpatch: " Patchwork
2024-06-20 6:29 ` ✓ CI.KUnit: " Patchwork
2024-06-20 6:41 ` ✓ CI.Build: " Patchwork
2024-06-20 6:43 ` ✗ CI.Hooks: failure " Patchwork
2024-06-20 6:44 ` ✓ CI.checksparse: success " Patchwork
2024-06-20 7:01 ` ✓ CI.BAT: " Patchwork
2024-06-20 8:32 ` ✗ CI.FULL: failure " Patchwork
2024-06-20 10:09 ` ✓ CI.Patch_applied: success for Adapt the driver to boot on the VF device (rev3) Patchwork
2024-06-20 10:09 ` ✓ CI.checkpatch: " Patchwork
2024-06-20 10:10 ` ✓ CI.KUnit: " Patchwork
2024-06-20 10:22 ` ✓ CI.Build: " Patchwork
2024-06-20 10:24 ` ✗ CI.Hooks: failure " Patchwork
2024-06-20 10:26 ` ✓ CI.checksparse: success " Patchwork
2024-06-20 10:52 ` ✗ CI.BAT: failure " Patchwork
2024-06-20 14:29 ` Michal Wajdeczko
2024-06-20 13:01 ` ✗ CI.FULL: " Patchwork
2024-06-20 14:32 ` Michal Wajdeczko
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=0e854a3e-b552-474e-8080-1e139e466509@intel.com \
--to=michal.wajdeczko@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.brost@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