On 20/05/2019 06:47, Suraj Jitindar Singh wrote: > On Fri, 2019-05-17 at 15:10 +0200, Thomas Huth wrote: >> On 17/05/2019 15.03, Laurent Vivier wrote: >>> From: Suraj Jitindar Singh <sjitindarsingh@xxxxxxxxx> >>> >>> Currently the handler for a decrementer exception will simply >>> reload the >>> maximum value (0x7FFFFFFF), which will take ~4 seconds to expire >>> again. >>> This means that if a vcpu cedes, it will be ~4 seconds between >>> wakeups. >>> >>> The h_cede_tm test is testing a known breakage when a guest cedes >>> while >>> suspended. To be sure we cede 500 times to check for the bug. >>> However >>> since it takes ~4 seconds to be woken up once we've ceded, we only >>> get >>> through ~20 iterations before we reach the 90 seconds timeout and >>> the >>> test appears to fail. >>> >>> Add an option when registering the decrementer handler to specify >>> the >>> value which should be reloaded by the handler, allowing the timeout >>> to be >>> chosen. >>> >>> Modify the spr test to use the max timeout to preserve existing >>> behaviour. >>> Modify the h_cede_tm test to use a 10ms timeout to ensure we can >>> perform >>> 500 iterations before hitting the 90 second time limit for a test. >>> >>> This means the h_cede_tm test now succeeds rather than timing out. >>> >>> Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@xxxxxxxxx> >>> Reviewed-by: Thomas Huth <thuth@xxxxxxxxxx> >>> Reviewed-by: Laurent Vivier <lvivier@xxxxxxxxxx> >>> [lv: reset initial value to 0x3FFFFFFF] >> >> Looks like something went wrong here? There is still the 0x7FFFFFFF >> in >> the hunk below... > > No, I think this is correct. > Max value is ox7FFFFFFF, but the initial value we load via mtdec is the > original 0x3FFFFFFF. Yes, that's it. Thanks, Laurent
