summaryrefslogtreecommitdiff
path: root/drivers/leds/leds-powernv.c
diff options
context:
space:
mode:
authorDavid Hildenbrand <dahi@linux.vnet.ibm.com>2016-02-15 11:42:25 +0300
committerChristian Borntraeger <borntraeger@de.ibm.com>2016-03-08 15:57:52 +0300
commitdb0758b29709815d93a963e31e2ec87ecf74f8bd (patch)
tree799b8cea02bf3275c39db7d890206fe7c29013ee /drivers/leds/leds-powernv.c
parent4287f247f6cfaea0ed73b5104e94cd737e1ac0ae (diff)
downloadlinux-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