diff options
| author | Michael Roth <michael.roth@amd.com> | 2022-04-26 19:53:23 +0000 |
|---|---|---|
| committer | Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> | 2022-07-13 17:27:31 -0500 |
| commit | b7fe62a656bffc8c559b2183ccd747e923fe0f3e (patch) | |
| tree | 18a7ab957948dc3a7dc1925ef9fca9ec89594479 /scripts/stackusage | |
| parent | f32e1cc788b1191c90b701e84c82984972970519 (diff) | |
| download | cachepc-linux-b7fe62a656bffc8c559b2183ccd747e923fe0f3e.tar.gz cachepc-linux-b7fe62a656bffc8c559b2183ccd747e923fe0f3e.zip | |
*debug: warn and retry failed rmpupdates
In some cases on B0 hardware exhibits something like the following
behavior (where M < 512):
Guest A | Guest B
|-------------------------------|----------------------------------|
| | rc = rmpupdate pfn=N*512,4K,priv
| rmpupdate pfn=N*512+M,4K,priv |
| rc = FAIL_OVERLAP | rc = SUCCESS
The FAIL_OVERLAP might possible be the result of hardware temporarily
treating Guest B's rmpupdate for pfn=N*512 as a 2M update, causing the
subsequent update from Guest A for pfn=N*512+M to report FAIL_OVERLAP
at that particular instance. Retrying the update for N*512+M immediately
afterward seems to resolve the FAIL_OVERLAP issue reliably however.
A similar failure has also been observed when transitioning pages back
to shared during VM destroy. In this case repeating the rmpupdate does
not always seem to resolve the failure immediately.
Both situations are much more likely to occur if THP is disabled, or
if it is enabled/disabled while guests are actively being
started/stopped.
Include some debug/error information to get a better idea of the
behavior on different hardware, and add the rmpupdate retry as a
workaround for Milan B0 testing.
Signed-off-by: Michael Roth <michael.roth@amd.com>
Diffstat (limited to 'scripts/stackusage')
0 files changed, 0 insertions, 0 deletions
