On 20/05/2019 08.12, Laurent Vivier wrote: > 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. Ok, since we're only calling H_CEDE once here, we should be fine, indeed. Sorry for the confusion. Thomas
