Skip to content
Snippets Groups Projects
Select Git revision
  • feature/libtcg-rebase default protected
1 result
Search by author
  • Any Author
  • Anton Anton anjo
1 author
  1. Aug 16, 2019
  3. Aug 02, 2019
    • Peter Maydell's avatar
      target/arm: Avoid bogus NSACR traps on M-profile without Security Extension · 02ac2f7f
      Peter Maydell authored 
      In Arm v8.0 M-profile CPUs without the Security Extension and also in
v7M CPUs, there is no NSACR register. However, the code we have to handle
the FPU does not always check whether the ARM_FEATURE_M_SECURITY bit
is set before testing whether env->v7m.nsacr permits access to the
FPU. This means that for a CPU with an FPU but without the Security
Extension we would always take a bogus fault when trying to stack
the FPU registers on an exception entry.

We could fix this by adding extra feature bit checks for all uses,
but it is simpler to just make the internal value of nsacr 0xcff
("all non-secure accesses allowed"), since this is not guest
visible when the Security Extension is not present. This allows
us to continue to follow the Arm ARM pseudocode which takes a
similar approach. (In particular, in the v8.1 Arm ARM the register
is documented as reading as 0xcff in this configuration.)

Fixes: https://bugs.launchpad.net/qemu/+bug/1838475


Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: default avatarDamien Hedde <damien.hedde@greensocs.com>
Message-id: 20190801105742.20036-1-peter.maydell@linaro.org
      02ac2f7f
  5. Jul 30, 2019
  7. Jul 29, 2019
  9. Jul 24, 2019
  11. Jul 22, 2019
  13. Jul 19, 2019
    • Jiri Slaby's avatar
      target/i386: sev: fix failed message typos · d4b976c0
      Jiri Slaby authored 
      
In these multiline messages, there were typos. Fix them -- add a missing
space and remove a superfluous apostrophe.

Inspired by Tom's patch.

Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: qemu-trivial@nongnu.org
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <20190719104118.17735-1-jslaby@suse.cz>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      d4b976c0
    • Denis V. Lunev's avatar
      i386: indicate that 'pconfig' feature was removed intentionally · 2924ab02
      Denis V. Lunev authored 
      
pconfig feature was added in 5131dc43 and removed in 712f807e.
This patch mark this feature as known to QEMU and removed by
intentinally. This follows the convention of 9ccb9784 and f1a23522
dealing with 'osxsave' and 'ospke'.

Signed-off-by: default avatarDenis V. Lunev <den@openvz.org>
CC: Paolo Bonzini <pbonzini@redhat.com>
CC: Richard Henderson <rth@twiddle.net>
CC: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20190719111222.14943-1-den@openvz.org>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      2924ab02
    • Paolo Bonzini's avatar
      target/i386: skip KVM_GET/SET_NESTED_STATE if VMX disabled, or for SVM · 1e44f3ab
      Paolo Bonzini authored 
      
Do not allocate env->nested_state unless we later need to migrate the
nested virtualization state.

With this change, nested_state_needed() will return false if the
VMX flag is not included in the virtual machine.  KVM_GET/SET_NESTED_STATE
is also disabled for SVM which is safer (we know that at least the NPT
root and paging mode have to be saved/loaded), and thus the corresponding
subsection can go away as well.

Inspired by a patch from Liran Alon.

Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      1e44f3ab
    • Liran Alon's avatar
      target/i386: kvm: Demand nested migration kernel capabilities only when vCPU may have enabled VMX · 79a197ab
      Liran Alon authored 
      
Previous to this change, a vCPU exposed with VMX running on a kernel
without KVM_CAP_NESTED_STATE or KVM_CAP_EXCEPTION_PAYLOAD resulted in
adding a migration blocker. This was because when the code was written
it was thought there is no way to reliably know if a vCPU is utilising
VMX or not at runtime. However, it turns out that this can be known to
some extent:

In order for a vCPU to enter VMX operation it must have CR4.VMXE set.
Since it was set, CR4.VMXE must remain set as long as the vCPU is in
VMX operation. This is because CR4.VMXE is one of the bits set
in MSR_IA32_VMX_CR4_FIXED1.
There is one exception to the above statement when vCPU enters SMM mode.
When a vCPU enters SMM mode, it temporarily exits VMX operation and
may also reset CR4.VMXE during execution in SMM mode.
When the vCPU exits SMM mode, vCPU state is restored to be in VMX operation
and CR4.VMXE is restored to its original state of being set.
Therefore, when the vCPU is not in SMM mode, we can infer whether
VMX is being used by examining CR4.VMXE. Otherwise, we cannot
know for certain but assume the worse that vCPU may utilise VMX.

Summaring all the above, a vCPU may have enabled VMX in case
CR4.VMXE is set or vCPU is in SMM mode.

Therefore, remove migration blocker and check before migration
(cpu_pre_save()) if the vCPU may have enabled VMX. If true, only then
require relevant kernel capabilities.

While at it, demand KVM_CAP_EXCEPTION_PAYLOAD only when the vCPU is in
guest-mode and there is a pending/injected exception. Otherwise, this
kernel capability is not required for proper migration.

Reviewed-by: default avatarJoao Martins <joao.m.martins@oracle.com>
Signed-off-by: default avatarLiran Alon <liran.alon@oracle.com>
Reviewed-by: default avatarMaran Wilson <maran.wilson@oracle.com>
Tested-by: default avatarMaran Wilson <maran.wilson@oracle.com>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      79a197ab
  15. Jul 16, 2019
  17. Jul 15, 2019
  19. Jul 14, 2019
  21. Jul 09, 2019
  23. Jul 08, 2019
  25. Jul 05, 2019