Re: [RFC] Expose a memory poison detector ioctl to user space.

[Dave Hansen <dave.hansen@intel.com>]

From your description, you have me mostly convinced that this is
something that needs to get fixed.  The hardware patrol scrubber(s)
address the same basic problem, but don't seem to be flexible to your
specific needs.

But, have hardware vendors been receptive at all to making the patrol
scrubbers more tunable?

On 4/25/22 09:34, Jue Wang wrote:
> /* Could stop and return after the 1st poison is detected */
> #define MCESCAN_IOCTL_SCAN 0
> 
> struct SysramRegion {
>   /* input */
>   uint64_t first_byte;   /* first page-aligned physical address to scan */
>   uint64_t length;       /* page-aligned length of memory region to scan */
>   /* output */
>   uint32_t poisoned;     /* 1 - a poisoned page is found, 0 - otherwise */
>   uint32_t poisoned_pfn; /* PFN of the 1st detected poisoned page */
> }

So, the ioctl() caller has to know the physical address layout of the
system?

While this is a good start at a conversation, I think you might want to
back up a bit.  You alluded to a few requirements that you have, like:

 * Adjustable detector resource use based on system utilization
 * Adjustable scan rate to ensure issues are found at a deterministic
   rate
 * Detector must be able to find errors in allocated, in-use memory

What about SEV-SNP or TDX private memory?  It might be unmapped *and*
limited in how it can be accessed.  For instance, TDX hosts can't
practically read guest memory.  SEV-SNP hosts have special page mapping
requirements; the cost can't create arbitrary mappings with arbitrary
mapping sizes.  What would this ioctl() do if asked to scan a TDX guest
private page?

Is doing it from userspace a strict requirement?

Would the detector just read memory?

Are there any other physical addresses which are RAM but should not have
the detector used on them?