Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu
切换分支/标签
  1. 19 9月, 2017 2 次提交
  3. 31 8月, 2017 1 次提交
  5. 11 7月, 2017 1 次提交
    • A
      ARM: KVM: Enable in-kernel timers with user space gic · 5d721b78
      由 Alexander Graf 提交于 
      When running with KVM enabled, you can choose between emulating the
gic in kernel or user space. If the kernel supports in-kernel virtualization
of the interrupt controller, it will default to that. If not, if will
default to user space emulation.

Unfortunately when running in user mode gic emulation, we miss out on
interrupt events which are only available from kernel space, such as the timer.
This patch leverages the new kernel/user space pending line synchronization for
timer events. It does not handle PMU events yet.
Signed-off-by: NAlexander Graf <agraf@suse.de>
Reviewed-by: NAndrew Jones <drjones@redhat.com>
Message-id: 1498577737-130264-1-git-send-email-agraf@suse.de
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      5d721b78
  7. 04 7月, 2017 2 次提交
  9. 15 6月, 2017 2 次提交
  11. 13 6月, 2017 1 次提交
  13. 08 6月, 2017 1 次提交
    • G
      kvm: don't register smram_listener when smm is off · d870cfde
      由 Gonglei 提交于 
      If the user set disable smm by '-machine smm=off', we
should not register smram_listener so that we can
avoid waster memory in kvm since the added sencond
address space.

Meanwhile we should assign value of the global kvm_state
before invoking the kvm_arch_init(), because
pc_machine_is_smm_enabled() may use it by kvm_has_mm().
Signed-off-by: NGonglei <arei.gonglei@huawei.com>
Message-Id: <1496316915-121196-1-git-send-email-arei.gonglei@huawei.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      d870cfde
  15. 07 6月, 2017 1 次提交
  17. 06 6月, 2017 1 次提交
    • D
      migration: Mark CPU states dirty before incoming migration/loadvm · 75e972da
      由 David Gibson 提交于 
      As a rule, CPU internal state should never be updated when
!cpu->kvm_vcpu_dirty (or the HAX equivalent).  If that is done, then
subsequent calls to cpu_synchronize_state() - usually safe and idempotent -
will clobber state.

However, we routinely do this during a loadvm or incoming migration.
Usually this is called shortly after a reset, which will clear all the cpu
dirty flags with cpu_synchronize_all_post_reset().  Nothing is expected
to set the dirty flags again before the cpu state is loaded from the
incoming stream.

This means that it isn't safe to call cpu_synchronize_state() from a
post_load handler, which is non-obvious and potentially inconvenient.

We could cpu_synchronize_all_state() before the loadvm, but that would be
overkill since a) we expect the state to already be synchronized from the
reset and b) we expect to completely rewrite the state with a call to
cpu_synchronize_all_post_init() at the end of qemu_loadvm_state().

To clear this up, this patch introduces cpu_synchronize_pre_loadvm() and
associated helpers, which simply marks the cpu state as dirty without
actually changing anything.  i.e. it says we want to discard any existing
KVM (or HAX) state and replace it with what we're going to load.

Cc: Juan Quintela <quintela@redhat.com>
Cc: Dave Gilbert <dgilbert@redhat.com>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Reviewed-by: NJuan Quintela <quintela@redhat.com>
      75e972da
  19. 23 5月, 2017 1 次提交
    • E
      shutdown: Add source information to SHUTDOWN and RESET · cf83f140
      由 Eric Blake 提交于 
      Time to wire up all the call sites that request a shutdown or
reset to use the enum added in the previous patch.

It would have been less churn to keep the common case with no
arguments as meaning guest-triggered, and only modified the
host-triggered code paths, via a wrapper function, but then we'd
still have to audit that I didn't miss any host-triggered spots;
changing the signature forces us to double-check that I correctly
categorized all callers.

Since command line options can change whether a guest reset request
causes an actual reset vs. a shutdown, it's easy to also add the
information to reset requests.
Signed-off-by: NEric Blake <eblake@redhat.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au> [ppc parts]
Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> [SPARC part]
Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> [s390x parts]
Message-Id: <20170515214114.15442-5-eblake@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      cf83f140
  21. 14 3月, 2017 1 次提交
  23. 03 3月, 2017 5 次提交
    • P
      KVM: use KVM_CAP_IMMEDIATE_EXIT · cf0f7cf9
      由 Paolo Bonzini 提交于 
      The purpose of the KVM_SET_SIGNAL_MASK API is to let userspace "kick"
a VCPU out of KVM_RUN through a POSIX signal.  A signal is attached
to a dummy signal handler; by blocking the signal outside KVM_RUN and
unblocking it inside, this possible race is closed:

          VCPU thread                     service thread
   --------------------------------------------------------------
        check flag
                                          set flag
                                          raise signal
        (signal handler does nothing)
        KVM_RUN

However, one issue with KVM_SET_SIGNAL_MASK is that it has to take
tsk->sighand->siglock on every KVM_RUN.  This lock is often on a
remote NUMA node, because it is on the node of a thread's creator.
Taking this lock can be very expensive if there are many userspace
exits (as is the case for SMP Windows VMs without Hyper-V reference
time counter).

KVM_CAP_IMMEDIATE_EXIT provides an alternative, where the flag is
placed directly in kvm_run so that KVM can see it:

          VCPU thread                     service thread
   --------------------------------------------------------------
                                          raise signal
        signal handler
          set run->immediate_exit
        KVM_RUN
          check run->immediate_exit

The previous patches changed QEMU so that the only blocked signal is
SIG_IPI, so we can now stop using KVM_SET_SIGNAL_MASK and sigtimedwait
if KVM_CAP_IMMEDIATE_EXIT is available.

On a 14-VCPU guest, an "inl" operation goes down from 30k to 6k on
an unlocked (no BQL) MemoryRegion, or from 30k to 15k if the BQL
is involved.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      cf0f7cf9
    • P
      kvm: use atomic_read/atomic_set to access cpu->exit_request · c5c6679d
      由 Paolo Bonzini 提交于 
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      c5c6679d
    • P
      KVM: move SIG_IPI handling to kvm-all.c · 18268b60
      由 Paolo Bonzini 提交于 
      This lets us remove a bunch of CONFIG_LINUX defines.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      18268b60
    • P
      KVM: do not use sigtimedwait to catch SIGBUS · 2ae41db2
      由 Paolo Bonzini 提交于 
      Call kvm_on_sigbus_vcpu asynchronously from the VCPU thread.
Information for the SIGBUS can be stored in thread-local variables
and processed later in kvm_cpu_exec.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      2ae41db2
    • P
      KVM: remove kvm_arch_on_sigbus · 4d39892c
      由 Paolo Bonzini 提交于 
      Build it on kvm_arch_on_sigbus_vcpu instead.  They do the same
for "action optional" SIGBUSes, and the main thread should never get
"action required" SIGBUSes because it blocks the signal.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      4d39892c
  25. 16 2月, 2017 2 次提交
  27. 01 2月, 2017 1 次提交
  29. 31 10月, 2016 1 次提交
  31. 23 10月, 2016 1 次提交
  33. 04 10月, 2016 1 次提交
  35. 27 9月, 2016 1 次提交
    • A
      cpus: pass CPUState to run_on_cpu helpers · e0eeb4a2
      由 Alex Bennée 提交于 
      CPUState is a fairly common pointer to pass to these helpers. This means
if you need other arguments for the async_run_on_cpu case you end up
having to do a g_malloc to stuff additional data into the routine. For
the current users this isn't a massive deal but for MTTCG this gets
cumbersome when the only other parameter is often an address.

This adds the typedef run_on_cpu_func for helper functions which has an
explicit CPUState * passed as the first parameter. All the users of
run_on_cpu and async_run_on_cpu have had their helpers updated to use
CPUState where available.
Signed-off-by: NAlex Bennée <alex.bennee@linaro.org>
[Sergey Fedorov:
 - eliminate more CPUState in user data;
 - remove unnecessary user data passing;
 - fix target-s390x/kvm.c and target-s390x/misc_helper.c]
Signed-off-by: NSergey Fedorov <sergey.fedorov@linaro.org>
Acked-by: David Gibson <david@gibson.dropbear.id.au> (ppc parts)
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> (s390 parts)
Signed-off-by: NAlex Bennée <alex.bennee@linaro.org>
Message-Id: <1470158864-17651-3-git-send-email-alex.bennee@linaro.org>
Reviewed-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      e0eeb4a2
  37. 14 9月, 2016 1 次提交
  39. 08 8月, 2016 1 次提交
  41. 03 8月, 2016 1 次提交
  43. 22 7月, 2016 5 次提交
  45. 17 6月, 2016 2 次提交
  47. 07 6月, 2016 1 次提交
  49. 30 5月, 2016 1 次提交
  51. 27 5月, 2016 1 次提交
    • G
      PPC/KVM: early validation of vcpu id · 41264b38
      由 Greg Kurz 提交于 
      The KVM API restricts vcpu ids to be < KVM_CAP_MAX_VCPUS. On PowerPC
targets, depending on the number of threads per core in the host and
in the guest, some topologies do generate higher vcpu ids actually.
When this happens, QEMU bails out with the following error:

kvm_init_vcpu failed: Invalid argument

The KVM_CREATE_VCPU ioctl has several EINVAL return paths, so it is
not possible to fully disambiguate.

This patch adds a check in the code that computes vcpu ids, so that
we can detect the error earlier, and print a friendlier message instead
of calling KVM_CREATE_VCPU with an obviously bogus vcpu id.
Signed-off-by: NGreg Kurz <gkurz@linux.vnet.ibm.com>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      41264b38
  53. 18 5月, 2016 1 次提交