On 11/22/2022 4:44 AM, Borislav Petkov wrote:
On Tue, Nov 22, 2022 at 04:32:18AM -0600, Kalra, Ashish wrote:
Please note that in both cases, these non-reclaimed pages cannot be
freed/returned back to the page allocator.
You keep repeating "these pages". Which pages?
The pages which have been allocated for firmware use (such as for
SNP_INIT command, TMR memory for SEV-ES usage, etc), command buffers
used for SEV legacy commands when SNP is enabled.
Here is a detailed description of the SEV legacy command handling when
SNP is enabled:
The behavior of the SEV-legacy commands is altered when the SNP firmware
is in the INIT state. When SNP is in INIT state, all the SEV-legacy
commands that cause the firmware to write to memory must be in the
firmware state before issuing the command. A command buffer may contain
a system physical address that the firmware may write to. In case the
command buffer contains a system physical address points to a guest
memory, we need to change the page state to the firmware in the RMP
table before issuing the command and restore the state to shared after
the command completes.
Then there are host buffers allocated for SNP platform status command,
SNP launch update and SNP launch update vmsa command.
The other pages which can be user or guest provided are SNP guest
requests and SNP guest debug helpers.
It is important to note that if invalid address/len are supplied, the
failure will happen at the initial stage itself of transitioning these
pages to firmware state.
But if the above pages have been successfully transitioned to firmware
state and passed on to the SNP firmware, then after return, they need to
be restored to shared state. If this restoration/reclamation fails, then
accessing these pages will cause the kernel to panic.
What if you specify the wrong, innocent pages because the kernel is
wrong?
In such a case the kernel panic is justifiable, but again if incorrect
addresses are supplied, the failure will happen at the initial stage of
transitioning these pages to firmware state and there is no need to
reclaim.
Or, otherwise dump a warning and let the pages not be freed/returned
back to the page allocator.
It is either innocent pages or kernel panic or an innocent host process
crash (these are the choices to make).
Thanks,
Ashish
