RE: [RFC PATCH v2 00/34] MSR refactor with new MSR instructions support

Luck, Tony
2025-04-22T18:05:53Z

> >> base-commit: f30a0c0d2b08b355c01392538de8fc872387cb2b
> >
> > This commit doesn't exist in Linus' tree or the tip tree, and the series doesn't
> > apply cleanly on any of the "obvious" choices. Reviewing a 34 patches series
> > without being able to apply it is a wee bit difficult...
> >
>
> $ git show f30a0c0d2b08b355c01392538de8fc872387cb2b
> commit f30a0c0d2b08b355c01392538de8fc872387cb2b
> Merge: 49b517e68cf7 e396dd85172c
> Author: Ingo Molnar <mingo@kernel.org>
> Date: Tue Apr 22 08:37:32 2025 +0200
>
> Merge branch into tip/master: 'x86/sev'
>
> # New commits in x86/sev:
> e396dd85172c ("x86/sev: Register tpm-svsm platform device")
> 93b7c6b3ce91 ("tpm: Add SNP SVSM vTPM driver")
> b2849b072366 ("svsm: Add header with SVSM_VTPM_CMD helpers")
> 770de678bc28 ("x86/sev: Add SVSM vTPM probe/send_command
> functions")
>
> Signed-off-by: Ingo Molnar <mingo@kernel.org>
>
>
> You probably need to git pull from the tip tree :-)

If possible, you should avoid basing a series on tip/master as it gets recreated
frequently by merging all the topic branches. The SHA1 is here today, gone
tomorrow.

If your changes only depend on one TIP topic branch, base on that and mention
in the cover letter (as well as the SHA1 supplied from git format-patches --base=xxx).

If you do depend on multiple tip topic branches, then maybe tip/master is your
only hope. But in that case cover letter should say "tip/master as of yyy-mm-dd.

-Tony