From: sashiko-bot@kernel.org
To: "Wei Hu" <weh@linux.microsoft.com>
Cc: linux-hyperv@vger.kernel.org
Subject: Re: [PATCH v5 7/9] mshv: detect and report SEV-SNP support at init
Date: Tue, 08 Sep 2026 12:28:05 +0000 [thread overview]
Message-ID: <20260908122807.5E3F51F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260908121403.1160280-8-weh@linux.microsoft.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The patch uses the compiler-defined `__x86_64__` macro instead of the kernel standard `CONFIG_X86_64`.
--
commit 25a294afba0df1fc3823f90fe382591fefe4ae1f
Author: Wei Liu <wei.liu@kernel.org>
mshv: detect and report SEV-SNP support at init
This commit queries MSHV dynamic processor features during parent
initialization to report SEV-SNP availability and the maximum number
of encrypted partitions. It also ensures the misc device rejects opens
until the partition hash table and interrupt handling are fully ready.
> diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
> index 42eb81b257092..bf43f1f1e6da5 100644
> --- a/drivers/hv/mshv_root_main.c
> +++ b/drivers/hv/mshv_root_main.c
[ ... ]
> @@ -3232,6 +3235,104 @@ static int mshv_root_scheduler_cleanup(unsigned int cpu)
> }
>
> /* Must be called after retrieving the scheduler type */
> +#if defined(__x86_64__)
[Severity: Low]
Should this use the kernel standard CONFIG_X86_64 instead of the
compiler-defined __x86_64__ macro? Using the compiler macro circumvents
kernel configuration management and creates an inconsistency with the rest
of the file which relies on standard Kconfig macros.
> +static const char *hv_snp_status_to_string(enum hv_snp_status status)
> +{
> + switch (status) {
> + case HV_SNP_STATUS_NONE:
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260908121403.1160280-1-weh@linux.microsoft.com?part=7
next prev parent reply other threads:[~2026-09-08 12:28 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 4:04 [PATCH v3 0/7] mshv: add SEV-SNP support for MSHV root partitions Wei Hu
2026-08-25 4:04 ` [PATCH v3 1/7] mshv: add SEV-SNP UAPI definitions Wei Hu
2026-08-25 4:04 ` [PATCH v3 2/7] mshv: add SEV-SNP PSP request hypercall Wei Hu
2026-08-25 4:17 ` sashiko-bot
2026-08-25 4:04 ` [PATCH v3 3/7] mshv: add SEV-SNP isolated page hypercalls Wei Hu
2026-08-25 4:04 ` [PATCH v3 4/7] mshv: wire SEV-SNP partition ioctls Wei Hu
2026-08-25 4:22 ` sashiko-bot
2026-08-25 4:04 ` [PATCH v3 5/7] mshv: detect and report SEV-SNP support at init Wei Hu
2026-08-25 4:19 ` sashiko-bot
2026-08-25 4:04 ` [PATCH v3 6/7] mshv: use safe partition CPU feature defaults Wei Hu
2026-08-25 4:04 ` [PATCH v3 7/7] mshv: set up own SynIC registers on a nested root partition Wei Hu
2026-08-25 4:20 ` sashiko-bot
2026-08-31 11:26 ` [PATCH v4 0/9] mshv: add SEV-SNP support for MSHV root partitions Wei Hu
2026-08-31 11:26 ` [PATCH v4 1/9] mshv: retain memory regions until unmap succeeds Wei Hu
2026-08-31 11:48 ` sashiko-bot
2026-09-01 12:04 ` [EXTERNAL] " Wei Hu
2026-08-31 11:26 ` [PATCH v4 2/9] mshv: clear SynIC mappings before freeing them Wei Hu
2026-08-31 11:26 ` [PATCH v4 3/9] mshv: add SEV-SNP UAPI definitions Wei Hu
2026-08-31 11:26 ` [PATCH v4 4/9] mshv: add SEV-SNP PSP request hypercall Wei Hu
2026-08-31 11:26 ` [PATCH v4 5/9] mshv: add SEV-SNP isolated page hypercalls Wei Hu
2026-08-31 11:53 ` sashiko-bot
2026-08-31 11:26 ` [PATCH v4 6/9] mshv: wire SEV-SNP partition ioctls Wei Hu
2026-08-31 12:07 ` sashiko-bot
2026-08-31 11:26 ` [PATCH v4 7/9] mshv: detect and report SEV-SNP support at init Wei Hu
2026-08-31 11:26 ` [PATCH v4 8/9] mshv: use safe partition CPU feature defaults Wei Hu
2026-08-31 11:26 ` [PATCH v4 9/9] mshv: set up own SynIC registers on a nested root partition Wei Hu
2026-08-31 12:09 ` sashiko-bot
2026-09-08 12:13 ` [PATCH v5 0/9] mshv: add SEV-SNP support for MSHV root partitions Wei Hu
2026-09-08 12:13 ` [PATCH v5 1/9] mshv: retain memory regions until unmap succeeds Wei Hu
2026-09-08 12:33 ` sashiko-bot
2026-09-08 12:13 ` [PATCH v5 2/9] mshv: clear SynIC mappings before freeing them Wei Hu
2026-09-08 12:13 ` [PATCH v5 3/9] mshv: add SEV-SNP UAPI definitions Wei Hu
2026-09-08 12:13 ` [PATCH v5 4/9] mshv: add SEV-SNP PSP request hypercall Wei Hu
2026-09-08 12:13 ` [PATCH v5 5/9] mshv: add SEV-SNP isolated page hypercalls Wei Hu
2026-09-08 12:13 ` [PATCH v5 6/9] mshv: wire SEV-SNP partition ioctls Wei Hu
2026-09-08 12:29 ` sashiko-bot
2026-09-08 12:13 ` [PATCH v5 7/9] mshv: detect and report SEV-SNP support at init Wei Hu
2026-09-08 12:28 ` sashiko-bot [this message]
2026-09-08 12:13 ` [PATCH v5 8/9] mshv: use safe partition CPU feature defaults Wei Hu
2026-09-08 12:13 ` [PATCH v5 9/9] mshv: set up own SynIC registers on a nested root partition Wei Hu
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=20260908122807.5E3F51F00A3D@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=weh@linux.microsoft.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