diff options
author | David Hildenbrand <dahi@linux.vnet.ibm.com> | 2016-02-15 11:42:25 +0300 |
---|---|---|
committer | Christian Borntraeger <borntraeger@de.ibm.com> | 2016-03-08 15:57:52 +0300 |
commit | db0758b29709815d93a963e31e2ec87ecf74f8bd (patch) | |
tree | 799b8cea02bf3275c39db7d890206fe7c29013ee /drivers/leds/leds-powernv.c | |
parent | 4287f247f6cfaea0ed73b5104e94cd737e1ac0ae (diff) | |
download | linux-db0758b29709815d93a963e31e2ec87ecf74f8bd.tar.xz |
KVM: s390: step VCPU cpu timer during kvm_run ioctl
Architecturally we should only provide steal time if we are scheduled
away, and not if the host interprets a guest exit. We have to step
the guest CPU timer in these cases.
In the first shot, we will step the VCPU timer only during the kvm_run
ioctl. Therefore all time spent e.g. in interception handlers or on irq
delivery will be accounted for that VCPU.
We have to take care of a few special cases:
- Other VCPUs can test for pending irqs. We can only report a consistent
value for the VCPU thread itself when adding the delta.
- We have to take care of STP sync, therefore we have to extend
kvm_clock_sync() and disable preemption accordingly
- During any call to disable/enable/start/stop we could get premeempted
and therefore get start/stop calls. Therefore we have to make sure we
don't get into an inconsistent state.
Whenever a VCPU is scheduled out, sleeping, in user space or just about
to enter the SIE, the guest cpu timer isn't stepped.
Please note that all primitives are prepared to be called from both
environments (cpu timer accounting enabled or not), although not completely
used in this patch yet (e.g. kvm_s390_set_cpu_timer() will never be called
while cpu timer accounting is enabled).
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Diffstat (limited to 'drivers/leds/leds-powernv.c')
0 files changed, 0 insertions, 0 deletions