Hello Boris,
On 11/22/2022 4:17 AM, Borislav Petkov wrote:
On Mon, Nov 21, 2022 at 06:37:18PM -0600, Kalra, Ashish wrote:
I agree, but these pages are not in the right state to be released back to
Which pages exactly?
Some pages' state has really changed underneath or you've given the
wrong range?
It might be a user/sev-guest error, but these pages are now unsafe to use.
So is a kernel panic justified here, instead of not releasing the pages back
to host and logging errors for the same.
Ok, there are two cases:
* kernel error: I guess a big fat warning is the least we can issue
here. Not sure about panic considering this should almost never happen
and a warning would allow for people to catch dumps and debug the issue.
* firmware error: I don't think you can know that that is really
the case on a production system without additional fw debugging
capabilities. Dumping a warning would be the least we can do here too,
to signal that something's out of the ordinary and so people can look
into it further.
Please note that in both cases, these non-reclaimed pages cannot be
freed/returned back to the page allocator. Anytime the kernel accesses
these pages it will cause a panic or host process crash.
So along with warning, the pages will be added to a leaked pages list,
but there is no poisoning or anything, only need to ensure that these
pages are not touched/accessed again.
Thanks,
Ashish
So yeah, a big fat warning is a good start. And then you don't need any
memory poisoning etc gunk.