Skip to content
  • Jan Kiszka's avatar
    4b8523ee
    kvm: First step to push iothread lock out of inner run loop · 4b8523ee
    Jan Kiszka authored
    
    
    This opens the path to get rid of the iothread lock on vmexits in KVM
    mode. On x86, the in-kernel irqchips has to be used because we otherwise
    need to synchronize APIC and other per-cpu state accesses that could be
    changed concurrently.
    
    Regarding pre/post-run callbacks, s390x and ARM should be fine without
    specific locking as the callbacks are empty. MIPS and POWER require
    locking for the pre-run callback.
    
    For the handle_exit callback, it is non-empty in x86, POWER and s390.
    Some POWER cases could do without the locking, but it is left in
    place for now.
    
    Signed-off-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
    Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
    Message-Id: <1434646046-27150-7-git-send-email-pbonzini@redhat.com>
    4b8523ee
    kvm: First step to push iothread lock out of inner run loop
    Jan Kiszka authored
    
    
    This opens the path to get rid of the iothread lock on vmexits in KVM
    mode. On x86, the in-kernel irqchips has to be used because we otherwise
    need to synchronize APIC and other per-cpu state accesses that could be
    changed concurrently.
    
    Regarding pre/post-run callbacks, s390x and ARM should be fine without
    specific locking as the callbacks are empty. MIPS and POWER require
    locking for the pre-run callback.
    
    For the handle_exit callback, it is non-empty in x86, POWER and s390.
    Some POWER cases could do without the locking, but it is left in
    place for now.
    
    Signed-off-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
    Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
    Message-Id: <1434646046-27150-7-git-send-email-pbonzini@redhat.com>
Loading