Skip to content
  • Paolo Bonzini's avatar
    2e7f7a3c
    main-loop: use qemu_mutex_lock_iothread consistently · 2e7f7a3c
    Paolo Bonzini authored
    
    
    The next patch will require the BQL to be always taken with
    qemu_mutex_lock_iothread(), while right now this isn't the case.
    
    Outside TCG mode this is not a problem.  In TCG mode, we need to be
    careful and avoid the "prod out of compiled code" step if already
    in a VCPU thread.  This is easily done with a check on current_cpu,
    i.e. qemu_in_vcpu_thread().
    
    Hopefully, multithreaded TCG will get rid of the whole logic to kick
    VCPUs whenever an I/O event occurs!
    
    Cc: Frederic Konrad <fred.konrad@greensocs.com>
    Message-Id: <1434646046-27150-2-git-send-email-pbonzini@redhat.com>
    Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
    2e7f7a3c
    main-loop: use qemu_mutex_lock_iothread consistently
    Paolo Bonzini authored
    
    
    The next patch will require the BQL to be always taken with
    qemu_mutex_lock_iothread(), while right now this isn't the case.
    
    Outside TCG mode this is not a problem.  In TCG mode, we need to be
    careful and avoid the "prod out of compiled code" step if already
    in a VCPU thread.  This is easily done with a check on current_cpu,
    i.e. qemu_in_vcpu_thread().
    
    Hopefully, multithreaded TCG will get rid of the whole logic to kick
    VCPUs whenever an I/O event occurs!
    
    Cc: Frederic Konrad <fred.konrad@greensocs.com>
    Message-Id: <1434646046-27150-2-git-send-email-pbonzini@redhat.com>
    Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
Loading