Re: [PATCH v10 0/6] Add RMPOPT support.
"Kalra, Ashish" <[email protected]>
| Newsgroups | dev.linux.lists.linux-coco,org.kernel.vger.kvm,org.kernel.vger.linux-crypto,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
Hello Boris,
On 7/20/2026 3:28 PM, Borislav Petkov wrote:
> On Mon, Jul 20, 2026 at 03:17:23PM -0500, Kalra, Ashish wrote:
>> Just a gentle ping on this series. I believe v10 addresses the feedback from the earlier rounds.
>> Please let me know if it looks good to merge, or if there's anything else you'd like me to change.
>
> What about those Sashiko comments to it:
>
> https://sashiko.dev/#/patchset/cover.1782841284.git.ashish.kalra%40amd.com
>
> ?
>
The three Sashiko comments on v10 all resolved to no code change, with rationale posted inline:
1. Suspend/resume vs. hotplug disable (patch 3): pre-existing base-SNP behavior — an SNP host doesn't support suspend/resume anyway (SnpEn is set once before
SNP_INIT and can't be rebuilt on resume), so it can't arise.
2. snp_setup_rmpopt() re-init pass (patch 4): performance-only and self-correcting, doesn't occur on RMPOPT-capable platforms (the x86_snp_shutdown path frees
the workqueue, so re-init re-runs the pass) — the guarded case is legacy-firmware-only.
3. mod_delayed_work() and VM churn (patch 6): deliberate — queue_delayed_work() would regress the common case (scanning a guest before its page conversion
completes), the deferral is best-effort and self-limiting.
Thanks,
Ashish