[kvm-unit-tests PATCH 7/7] arm/run: add --debug option
This allows you to pass debug options through to the QEMU command line. e.g.: ./arm/run --debug -name debug-threads=on -- arm/vos-spinlock-test.flat -smp 4 Signed-off-by: Alex Bennée alex.ben...@linaro.org --- arm/run | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arm/run b/arm/run index 43d7508..871e35e 100755 --- a/arm/run +++ b/arm/run @@ -18,10 +18,15 @@ if [ -c /dev/kvm ]; then fi fi +debugopts= while :; do case $1 in --force-tcg) usingkvm=0 + ;; + --debug) + shift + debugopts=$1 shift ;; --) @@ -78,7 +83,7 @@ if [ $usingkvm = 1 ] [ $ARCH = arm64 ]; then fi command=$qemu $M -cpu $processor $chr_testdev -command+= -display none -serial stdio -kernel +command+= -display none -serial stdio $debugopts -kernel echo $command $@ $command $@ -- 2.4.5 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 12/17] irq: bypass: Extend skeleton for ARM forwarding control
Hi Paolo,
On 07/02/2015 03:40 PM, Paolo Bonzini wrote:
On 02/07/2015 15:17, Eric Auger wrote:
- new fields are added on producer side: linux irq, vfio_device handle,
active which reflects whether the source is active (at interrupt
controller level or at VFIO level - automasked -) and finally an
opaque pointer which will be used to point to the vfio_platform_device
in this series.
Linux IRQ and active should be okay. As to the vfio_device handle, you
should link it from the vfio_platform_device instead. And for the
vfio_platform_device, you can link it from the vfio_platform_irq instead.
For this last one, I don't think this is achievable since if I store the
vfio_platform_irq in the opaque, it matches irqs[i] of
vfio_platform_device and I don't have any mean to retrieve i when
calling container_of.
struct vfio_platform_irq *irq =
container_of(prod, struct vfio_platform_irq, producer);
struct vfio_platform_device *vpdev =
container_of(irq, struct vfio_platform_device, irqs[i?]);
struct vfio_platform_device {
../..
struct vfio_platform_irq*irqs;
../..
}
So I think I still need to pass vfio_platform_device in the opaque and
look on irqs array to identify the right vfio_platform_irq *.
Do I miss sthg?
- Eric
Once you've done this, embed the irq_bypass_producer struct in the
vfio_platform_irq struct; in the new kvm_arch_* functions, go back to
the vfio_platform_irq struct via container_of. From there you can
retrieve pointers to the vfio_platform_device and the vfio_device.
- new fields on consumer side: the kvm handle, the gsi
You do not need to add these. Instead, add the kvm handle to irqfd
only. Like above, embed the irq_bypass_consumer struct in the irqfd
struct; in the new kvm_arch_* functions, go back to the
vfio_platform_irq struct via container_of.
Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: VMX: fix vmwrite to invalid VMCS
On 03/07/2015 15:49, Radim Krčmář wrote: fpu_activate is called outside of vcpu_load(), which means it should not touch VMCS, but fpu_activate needs to. Avoid the call by moving it to a point where we know that the guest needs eager FPU and VMCS is loaded. This will get rid of the following trace vmwrite error: reg 6800 value 0 (err 1) [8162035b] dump_stack+0x19/0x1b [a046c701] vmwrite_error+0x2c/0x2e [kvm_intel] [a045f26f] vmcs_writel+0x1f/0x30 [kvm_intel] [a04617e5] vmx_fpu_activate.part.61+0x45/0xb0 [kvm_intel] [a0461865] vmx_fpu_activate+0x15/0x20 [kvm_intel] [a0560b91] kvm_arch_vcpu_create+0x51/0x70 [kvm] [a0548011] kvm_vm_ioctl+0x1c1/0x760 [kvm] [8118b55a] ? handle_mm_fault+0x49a/0xec0 [811e47d5] do_vfs_ioctl+0x2e5/0x4c0 [8127abbe] ? file_has_perm+0xae/0xc0 [811e4a51] SyS_ioctl+0xa1/0xc0 [81630949] system_call_fastpath+0x16/0x1b (Note: we also unconditionally activate FPU in vmx_vcpu_reset(), so the removed code added nothing.) Fixes: c447e76b4cab (kvm/fpu: Enable eager restore kvm FPU for MPX) Cc: sta...@vger.kernel.org Reported-by: Vlastimil Holer vlastimil.ho...@gmail.com Signed-off-by: Radim Krčmář rkrc...@redhat.com Andrey reported offlist that the bug went away by reverting 1cde293. So the patch would at least need a new commit message. :) I'm putting it on hold. Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[kvm-unit-tests PATCH 6/7] arm/run: introduce basic option parsing
So far this simple option parsing loop allows us to --force-tcg even
when running on ARM hardware.
Signed-off-by: Alex Bennée alex.ben...@linaro.org
---
arm/run | 17 +
1 file changed, 17 insertions(+)
diff --git a/arm/run b/arm/run
index a3a33b3..43d7508 100755
--- a/arm/run
+++ b/arm/run
@@ -18,6 +18,23 @@ if [ -c /dev/kvm ]; then
fi
fi
+while :; do
+ case $1 in
+ --force-tcg)
+ usingkvm=0
+ shift
+ ;;
+ --)
+ # End of all options.
+ shift
+ break
+ ;;
+ *)
+ break
+ ;;
+ esac
+done
+
qemu=${QEMU:-qemu-system-$ARCH_NAME}
qpath=$(which $qemu 2/dev/null)
--
2.4.5
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[kvm-unit-tests PATCH 4/7] run/arm: introduce usingkvm var and use it
This makes it easier to force KVM off in later patches.
Signed-off-by: Alex Bennée alex.ben...@linaro.org
---
arm/run | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arm/run b/arm/run
index 6b42a2e..493ce0d 100755
--- a/arm/run
+++ b/arm/run
@@ -8,6 +8,16 @@ fi
source config.mak
processor=$PROCESSOR
+# Default to using KVM if available and on the right ARM host
+usingkvm=0
+if [ -c /dev/kvm ]; then
+ if [ $HOST = arm ] [ $ARCH = arm ]; then
+ usingkvm=1
+ elif [ $HOST = aarch64 ]; then
+ usingkvm=1
+ fi
+fi
+
qemu=${QEMU:-qemu-system-$ARCH_NAME}
qpath=$(which $qemu 2/dev/null)
@@ -39,7 +49,7 @@ chr_testdev='-device virtio-serial-device'
chr_testdev+=' -device virtconsole,chardev=ctd -chardev testdev,id=ctd'
# arm64 must use '-cpu host' with kvm
-if [ $(arch) = aarch64 ] [ $ARCH = arm64 ] [ -c /dev/kvm ]; then
+if [ $usingkvm = 1 ] [ $ARCH = arm64 ]; then
processor=host
fi
--
2.4.5
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[kvm-unit-tests PATCH 1/7] READ: add some CONTRIBUTING notes
Signed-off-by: Alex Bennée alex.ben...@linaro.org --- README | 22 ++ 1 file changed, 22 insertions(+) diff --git a/README b/README index e9869d1..4001456 100644 --- a/README +++ b/README @@ -25,3 +25,25 @@ Directory structure: ./ARCH: the sources of the tests and the created objects/images See ARCH/README for architecture specific documentation. + +CONTRIBUTING: += + +Style +- + + - C: please use standard linux-with-tabs + - Shell: use TABs for indentation + +Patches +--- + +Patches are welcome at the KVM mailing list kvm@vger.kernel.org. + +Please prefix messages with: [kvm-unit-tests PATCH] + +You can add the following to .git/config to do this automatically for you: + +[format] + subjectprefix = kvm-unit-tests PATCH + -- 2.4.5 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[kvm-unit-tests PATCH 5/7] arm/run: clean-up setting of accel options
It would be nice to use --no-kvm but that flags a warning on pure-TCG builds. We echo the fact we are using TCG for the benefit of interactive use. Signed-off-by: Alex Bennée alex.ben...@linaro.org --- arm/run | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/arm/run b/arm/run index 493ce0d..a3a33b3 100755 --- a/arm/run +++ b/arm/run @@ -44,7 +44,14 @@ if $qemu $M -chardev testdev,id=id -initrd . 21 \ exit 2 fi -M='-machine virt,accel=kvm:tcg' +M='-machine virt' +if [ $usingkvm = 1 ]; then + M+=,accel=kvm +else + echo Running with TCG + M+=',accel=tcg' +fi + chr_testdev='-device virtio-serial-device' chr_testdev+=' -device virtconsole,chardev=ctd -chardev testdev,id=ctd' -- 2.4.5 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[kvm-unit-tests PATCH 2/7] configure: emit HOST=$host to config.mak
This is useful information for the run scripts to know, especially if
they want to drop to using TCG.
Signed-off-by: Alex Bennée alex.ben...@linaro.org
---
configure | 2 ++
1 file changed, 2 insertions(+)
diff --git a/configure b/configure
index b2ad32a..078b70c 100755
--- a/configure
+++ b/configure
@@ -7,6 +7,7 @@ ld=ld
objcopy=objcopy
ar=ar
arch=`uname -m | sed -e s/i.86/i386/ | sed -e 's/arm.*/arm/'`
+host=$arch
cross_prefix=
usage() {
@@ -122,6 +123,7 @@ ln -s $asm lib/asm
cat EOF config.mak
PREFIX=$prefix
KERNELDIR=$(readlink -f $kerneldir)
+HOST=$host
ARCH=$arch
ARCH_NAME=$arch_name
PROCESSOR=$processor
--
2.4.5
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[kvm-unit-tests PATCH 3/7] arm/run: set indentation defaults for emacs
Signed-off-by: Alex Bennée alex.ben...@linaro.org --- arm/run | 1 + 1 file changed, 1 insertion(+) diff --git a/arm/run b/arm/run index 662a856..6b42a2e 100755 --- a/arm/run +++ b/arm/run @@ -1,4 +1,5 @@ #!/bin/bash +# -*- sh-basic-offset:8 indent-tabs-mode: t -*- if [ ! -f config.mak ]; then echo run ./configure first. See ./configure -h -- 2.4.5 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[kvm-unit-tests PATCH 0/7] A number of small arm/run fixes
Following on from yesterdays comments I've re-spun the changes as suggested. I've also added a very simple opt parsing for arm/run to allow us to --force-tcg and --debug more qemu cmdline. As a bonus I've codified some notes for contributing into the README. Alex Bennée (7): READ: add some CONTRIBUTING notes configure: emit HOST=$host to config.mak arm/run: set indentation defaults for emacs run/arm: introduce usingkvm var and use it arm/run: clean-up setting of accel options arm/run: introduce basic option parsing arm/run: add --debug option README| 22 ++ arm/run | 46 +++--- configure | 2 ++ 3 files changed, 67 insertions(+), 3 deletions(-) -- 2.4.5 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 100671] vmwrite error in vmx_vcpu_run
https://bugzilla.kernel.org/show_bug.cgi?id=100671 Andrey Smetanin asmeta...@virtuozzo.com changed: What|Removed |Added CC||asmeta...@virtuozzo.com --- Comment #3 from Andrey Smetanin asmeta...@virtuozzo.com --- Created attachment 181741 -- https://bugzilla.kernel.org/attachment.cgi?id=181741action=edit another one dmesg I have the encountered the same bug, guest OS - Windows 2012R2, the guest just after start goes into paused state. The attached dmesg dump contains guest/vms state. The kernel is linux (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git) with top commit 9bdc771f2c29a11920f477fba05a58e23ee42554 Merge: 7df9ab8 ea7d521 Author: Linus Torvalds torva...@linux-foundation.org Date: Thu Jul 2 17:11:28 2015 -0700 -- You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm/run: don't enable KVM if system can't do it
Andrew Jones drjo...@redhat.com writes: On Thu, Jul 02, 2015 at 03:45:17PM +0200, Paolo Bonzini wrote: On 02/07/2015 13:51, Andrew Jones wrote: 4) I recently mentioned[*] it might be nice to add a '-force-tcg' type of arm/run command line option, allowing tcg to be used even if it's possible to use kvm. Adding that at the same time would be nice. Can you just use --no-kvm? It is equivalent to -machine accel=tcg, Sounds perfect. Thanks! and it overrides previous -machine accel=foo options. For a TCG only build it complains: Option no-kvm not supported for this target :-/ Paolo ps: I also share the yay feeling, of course! -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Alex Bennée -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm/run: don't enable KVM if system can't do it
On 03/07/2015 14:24, Alex Bennée wrote: Andrew Jones drjo...@redhat.com writes: On Thu, Jul 02, 2015 at 03:45:17PM +0200, Paolo Bonzini wrote: On 02/07/2015 13:51, Andrew Jones wrote: 4) I recently mentioned[*] it might be nice to add a '-force-tcg' type of arm/run command line option, allowing tcg to be used even if it's possible to use kvm. Adding that at the same time would be nice. Can you just use --no-kvm? It is equivalent to -machine accel=tcg, Sounds perfect. Thanks! and it overrides previous -machine accel=foo options. For a TCG only build it complains: Option no-kvm not supported for this target :-/ Should be easy to fix though (or just use -machine accel=tcg, it's longer but it works). Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] KVM: VMX: fix vmwrite to invalid VMCS
fpu_activate is called outside of vcpu_load(), which means it should not touch VMCS, but fpu_activate needs to. Avoid the call by moving it to a point where we know that the guest needs eager FPU and VMCS is loaded. This will get rid of the following trace vmwrite error: reg 6800 value 0 (err 1) [8162035b] dump_stack+0x19/0x1b [a046c701] vmwrite_error+0x2c/0x2e [kvm_intel] [a045f26f] vmcs_writel+0x1f/0x30 [kvm_intel] [a04617e5] vmx_fpu_activate.part.61+0x45/0xb0 [kvm_intel] [a0461865] vmx_fpu_activate+0x15/0x20 [kvm_intel] [a0560b91] kvm_arch_vcpu_create+0x51/0x70 [kvm] [a0548011] kvm_vm_ioctl+0x1c1/0x760 [kvm] [8118b55a] ? handle_mm_fault+0x49a/0xec0 [811e47d5] do_vfs_ioctl+0x2e5/0x4c0 [8127abbe] ? file_has_perm+0xae/0xc0 [811e4a51] SyS_ioctl+0xa1/0xc0 [81630949] system_call_fastpath+0x16/0x1b (Note: we also unconditionally activate FPU in vmx_vcpu_reset(), so the removed code added nothing.) Fixes: c447e76b4cab (kvm/fpu: Enable eager restore kvm FPU for MPX) Cc: sta...@vger.kernel.org Reported-by: Vlastimil Holer vlastimil.ho...@gmail.com Signed-off-by: Radim Krčmář rkrc...@redhat.com --- I also thought about adding a sanity check when we enable eager FPU WARN_ON(kvm_check_request(KVM_REQ_DEACTIVATE_FPU, vcpu)); but it would be poinless now for two reasons * REQ_DEACTIVATE_FPU can't be set before vcpu_run loads FPU and CPUID shouldn't change after vcpu_run (userspace has bigger problems then) * guest MPX requires host support and those hosts should have eager FPU Let's be wild and employed! arch/x86/kvm/cpuid.c | 2 ++ arch/x86/kvm/x86.c | 5 - 2 files changed, 2 insertions(+), 5 deletions(-) diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index 64dd46793099..2fbea2544f24 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -98,6 +98,8 @@ int kvm_update_cpuid(struct kvm_vcpu *vcpu) best-ebx = xstate_required_size(vcpu-arch.xcr0, true); vcpu-arch.eager_fpu = use_eager_fpu() || guest_cpuid_has_mpx(vcpu); + if (vcpu-arch.eager_fpu) + kvm_x86_ops-fpu_activate(vcpu); /* * The existing code assumes virtual address is 48-bit in the canonical diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index bbaf44e8f0d3..6bd19c7abc65 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -7315,11 +7315,6 @@ struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm, vcpu = kvm_x86_ops-vcpu_create(kvm, id); - /* -* Activate fpu unconditionally in case the guest needs eager FPU. It will be -* deactivated soon if it doesn't. -*/ - kvm_x86_ops-fpu_activate(vcpu); return vcpu; } -- 2.4.5 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi
Hi! OK so both of you say the same thing. Will respin accordingly You may also want to add this: Tested-by: Pavel Fedin p.fe...@samsung.com Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi
Hi,
On 03/07/15 10:05, Andre Przywara wrote:
Hi Pavel,
On 02/07/15 08:26, Pavel Fedin wrote:
Hello!
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
Behalf Of Eric Auger
Sent: Monday, June 29, 2015 6:37 PM
To: eric.au...@st.com; eric.au...@linaro.org;
linux-arm-ker...@lists.infradead.org;
marc.zyng...@arm.com; christoffer.d...@linaro.org; andre.przyw...@arm.com;
kvm...@lists.cs.columbia.edu; kvm@vger.kernel.org
Cc: linux-ker...@vger.kernel.org; patc...@linaro.org; p.fe...@samsung.com;
pbonz...@redhat.com
Subject: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi
On ARM, the MSI msg (address and data) comes along with
out-of-band device ID information. The device ID encodes the device
that composes the MSI msg. Let's create a new routing entry type,
dubbed KVM_IRQ_ROUTING_EXTENDED_MSI and use the __u32 pad space
to convey the device ID.
Signed-off-by: Eric Auger eric.au...@linaro.org
---
RFC - PATCH
- remove kvm_irq_routing_extended_msi and use union instead
---
Documentation/virtual/kvm/api.txt | 9 -
include/uapi/linux/kvm.h | 6 +-
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index d20fd94..6426ae9 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1414,7 +1414,10 @@ struct kvm_irq_routing_entry {
__u32 gsi;
__u32 type;
__u32 flags;
- __u32 pad;
+ union {
+ __u32 pad;
+ __u32 devid;
+ };
union {
struct kvm_irq_routing_irqchip irqchip;
struct kvm_irq_routing_msi msi;
devid is actually a part of MSI bunch. Shouldn't it be a part of struct
kvm_irq_routing_msi then?
It also has reserved pad.
@@ -1427,6 +1430,10 @@ struct kvm_irq_routing_entry {
#define KVM_IRQ_ROUTING_IRQCHIP 1
#define KVM_IRQ_ROUTING_MSI 2
#define KVM_IRQ_ROUTING_S390_ADAPTER 3
+#define KVM_IRQ_ROUTING_EXTENDED_MSI 4
+
+In case of KVM_IRQ_ROUTING_EXTENDED_MSI routing type, devid is used to
convey
+the device ID.
No flags are specified so far, the corresponding field must be set to zero.
What if we use KVM_MSI_VALID_DEVID flag instead of new
KVM_IRQ_ROUTING_EXTENDED_MSI definition? I
believe this would make an API more consistent and introduce less new
definitions.
I like this approach, but it runs into problems:
As you read above the current documentation says that the flags field
must be zero and the current KVM_SET_GSI_ROUTING handler bails out if it
isn't. So userland would need to know whether it's safe to set that
field. Introducing a new KVM_CAP_... value seems overkill if we could
just have a new routing entry type. So we could still reuse the existing
struct kvm_irq_routing_msi (and extend that with the devid field), but
we would have to add a new routing type number.
Maybe we could collapse this into the existing MSI type + flag when
handing it further down the kernel?
FWIW, I gave this a try, this doesn't look to bad. I carried the new
type down till virt/kvm/arm/vgic.c:kvm_set_routing_entry(), where the
EXTENDED type got turned back into the normal MSI type while setting the
flag in the internal struct kvm_kernel_irq_routing_entry. This keeps the
new type only to the userland facing side, with the kernel code staying
mostly the same.
Together with a new KVM_CAP_MSIS_REQUIRE_DEVID capability I can now
drive both GICv2M and ITS emulation from the same userland base in a
sane manner.
If someone wants to have a look now, tell me, otherwise I will wait for
Eric's upcoming code drop and comment on that then.
Cheers,
Andre.
Cheers,
Andre.
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 2a23705..8484681 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -841,12 +841,16 @@ struct kvm_irq_routing_s390_adapter {
#define KVM_IRQ_ROUTING_IRQCHIP 1
#define KVM_IRQ_ROUTING_MSI 2
#define KVM_IRQ_ROUTING_S390_ADAPTER 3
+#define KVM_IRQ_ROUTING_EXTENDED_MSI 4
struct kvm_irq_routing_entry {
__u32 gsi;
__u32 type;
__u32 flags;
- __u32 pad;
+ union {
+ __u32 pad;
+ __u32 devid;
+ };
union {
struct kvm_irq_routing_irqchip irqchip;
struct kvm_irq_routing_msi msi;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] arm/arm64: speed up spinlocks and atomic ops
On 25/06/2015 20:45, Andrew Jones wrote:
spinlock torture tests made it clear that checking mmu_enabled()
every time we call spin_lock is a bad idea. As most tests will
want the MMU enabled the entire time, then we can inline a light
weight nobody disabled the mmu check, and bail out early.
Adding a light weight inlined check vs. a compile-time flag
suggested by Paolo.
Signed-off-by: Andrew Jones drjo...@redhat.com
---
lib/arm/asm/mmu-api.h | 7 ++-
lib/arm/mmu.c | 9 +++--
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/lib/arm/asm/mmu-api.h b/lib/arm/asm/mmu-api.h
index 12fdc57918c27..b2fc900a30add 100644
--- a/lib/arm/asm/mmu-api.h
+++ b/lib/arm/asm/mmu-api.h
@@ -1,7 +1,12 @@
#ifndef __ASMARM_MMU_API_H_
#define __ASMARM_MMU_API_H_
extern pgd_t *mmu_idmap;
-extern bool mmu_enabled(void);
+extern unsigned int mmu_disabled_cpu_count;
+extern bool __mmu_enabled(void);
+static inline bool mmu_enabled(void)
+{
+ return mmu_disabled_cpu_count == 0 || __mmu_enabled();
+}
extern void mmu_enable(pgd_t *pgtable);
extern void mmu_disable(void);
extern void mmu_enable_idmap(void);
diff --git a/lib/arm/mmu.c b/lib/arm/mmu.c
index ad558e177dd1c..e661d4f26e4b7 100644
--- a/lib/arm/mmu.c
+++ b/lib/arm/mmu.c
@@ -15,8 +15,9 @@ extern unsigned long etext;
pgd_t *mmu_idmap;
static cpumask_t mmu_disabled_cpumask;
+unsigned int mmu_disabled_cpu_count;
-bool mmu_enabled(void)
+bool __mmu_enabled(void)
{
int cpu = current_thread_info()-cpu;
@@ -30,7 +31,9 @@ void mmu_enable(pgd_t *pgtable)
asm_mmu_enable(__pa(pgtable));
flush_tlb_all();
- cpumask_clear_cpu(cpu, mmu_disabled_cpumask);
+
+ if (cpumask_test_and_clear_cpu(cpu, mmu_disabled_cpumask))
+ --mmu_disabled_cpu_count;
}
extern void asm_mmu_disable(void);
@@ -39,6 +42,8 @@ void mmu_disable(void)
int cpu = current_thread_info()-cpu;
cpumask_set_cpu(cpu, mmu_disabled_cpumask);
+ ++mmu_disabled_cpu_count;
+
asm_mmu_disable();
}
Applied, thanks.
Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 09/11] KVM: arm64: guest debug, HW assisted debug support
Will Deacon will.dea...@arm.com writes:
Hi Alex,
On Thu, Jul 02, 2015 at 02:50:33PM +0100, Alex Bennée wrote:
Are you happy with this?:
[...]
+/**
+ * kvm_arch_dev_ioctl_check_extension
+ *
+ * We currently assume that the number of HW registers is uniform
+ * across all CPUs (see cpuinfo_sanity_check).
+ */
int kvm_arch_dev_ioctl_check_extension(long ext)
{
int r;
@@ -64,6 +71,12 @@ int kvm_arch_dev_ioctl_check_extension(long ext)
case KVM_CAP_ARM_EL1_32BIT:
r = cpu_has_32bit_el1();
break;
+ case KVM_CAP_GUEST_DEBUG_HW_BPS:
+ r = hw_breakpoint_slots(TYPE_INST);
+ break;
+ case KVM_CAP_GUEST_DEBUG_HW_WPS:
+ r = hw_breakpoint_slots(TYPE_DATA);
+ break;
Whilst I much prefer this code, it actually adds an unwanted dependency
on PERF_EVENTS that I didn't think about to start with. Sorry to keep
messing you about -- I guess your original patch is the best thing after
all.
Everything looks to be in hw_breakpoint.[ch] which does depend on
CONFIG_HAVE_HW_BREAKPOINT which depends on PERF_EVENTS to be built.
However the previous code depended on this behaviour as well.
It would seem weird to enable guest debug using HW debug registers to
debug the guest yet not allowing the host kernel to use them? Of course
this is the only code they would share as all the magic of guest
debugging is already mostly there for dirty guest handling.
I'm not familiar with Kconfig but it looks like this is all part of
arm64 defconfig. Are people really going to want to disable PERF_EVENTS
but still debug their guests with HW support?
Will
--
Alex Bennée
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/13] KVM: arm64: implement ITS command queue command handlers
Hi Christoffer,
+
+static struct its_collection *vits_new_collection(struct kvm *kvm, u32
coll_id)
+{
+struct its_collection *collection;
+
+collection = kmalloc(sizeof(struct its_collection), GFP_KERNEL);
If I manage to understand the structure here, you're calling all these
handler functions with a spinlock held so any operation that may sleep
could cause your system to deadlock.
I'll stop looking for these and recommend you go over the whole series
for these.
Do you reckon it would be sufficient to just avoid the kmallocs inside
the lock? For this case above we could go with some storage space
preallocated outside of the lock (I hope).
Perhaps the right thing to do is to synchronize access to your data
structure (why you hold the spinlock right?) with RCU if you can...
Well, the point is that there is not one ITS data structure, but it's a
mesh of lists connected to each other. I'd like to avoid going down with
RCU there, so I'd like to keep it all under one lock.
I wonder if this could be mutex_lock_interruptible, though. From the top
of your head, is there anything that would prevent that? I reckon ITS
access contention is rather rare (though possible), so a sleeping VCPU
wouldn't harm us so much in practice, would it?
Cheers,
Andre.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 12/17] irq: bypass: Extend skeleton for ARM forwarding control
On 07/03/2015 07:20 PM, Paolo Bonzini wrote: On 03/07/2015 15:12, Eric Auger wrote: Linux IRQ and active should be okay. As to the vfio_device handle, you should link it from the vfio_platform_device instead. And for the vfio_platform_device, you can link it from the vfio_platform_irq instead. For this last one, I don't think this is achievable since if I store the vfio_platform_irq in the opaque, it matches irqs[i] of vfio_platform_device and I don't have any mean to retrieve i when calling container_of. Right, notice I said link it: struct vfio_platform_irq *irq = container_of(prod, struct vfio_platform_irq, producer); struct vfio_platform_device *vpdev = irq-vpdev; struct vfio_device *vdev = vpdev-vdev; Would this be okay? Yes that's what I did. I added the vfio_device handle in struct vfio_platform_irq Thanks ;-) Have a nice WE Eric Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 100671] vmwrite error in vmx_vcpu_run
https://bugzilla.kernel.org/show_bug.cgi?id=100671 --- Comment #4 from Andrey Smetanin asmeta...@virtuozzo.com --- Created attachment 181781 -- https://bugzilla.kernel.org/attachment.cgi?id=181781action=edit With this patch(commit revert) the bug disappears Added patch - revert of commit 1cde2930e15473cb4dd7e5a07d83e605a969bd6e. I had tested twice - with revert bug disappears. -- You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] arm64: KVM: Optimize arm64 skip 30-50% vfp/simd save/restore on exits
On 07/03/2015 04:53 AM, Christoffer Dall wrote: On Thu, Jul 02, 2015 at 02:51:57PM -0700, Mario Smarduch wrote: On 07/01/2015 06:46 AM, Christoffer Dall wrote: On Wed, Jun 24, 2015 at 05:04:11PM -0700, Mario Smarduch wrote: This patch only saves and restores FP/SIMD registers on Guest access. To do this cptr_el2 FP/SIMD trap is set on Guest entry and later checked on exit. lmbench, hackbench show significant improvements, for 30-50% exits FP/SIMD context is not saved/restored Signed-off-by: Mario Smarduch m.smard...@samsung.com --- arch/arm64/include/asm/kvm_arm.h |5 - arch/arm64/kvm/hyp.S | 46 +++--- 2 files changed, 47 insertions(+), 4 deletions(-) diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h index ac6fafb..7605e09 100644 --- a/arch/arm64/include/asm/kvm_arm.h +++ b/arch/arm64/include/asm/kvm_arm.h @@ -171,10 +171,13 @@ #define HSTR_EL2_TTEE (1 16) #define HSTR_EL2_T(x) (1 x) +/* Hyp Coproccessor Trap Register Shifts */ +#define CPTR_EL2_TFP_SHIFT 10 + /* Hyp Coprocessor Trap Register */ #define CPTR_EL2_TCPAC(1 31) #define CPTR_EL2_TTA (1 20) -#define CPTR_EL2_TFP (1 10) +#define CPTR_EL2_TFP (1 CPTR_EL2_TFP_SHIFT) /* Hyp Debug Configuration Register bits */ #define MDCR_EL2_TDRA (1 11) diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S index 5befd01..de0788f 100644 --- a/arch/arm64/kvm/hyp.S +++ b/arch/arm64/kvm/hyp.S @@ -673,6 +673,15 @@ tbz \tmp, #KVM_ARM64_DEBUG_DIRTY_SHIFT, \target .endm +/* + * Check cptr VFP/SIMD accessed bit, if set VFP/SIMD not accessed by guest. This comment doesn't really help me understand the function, may I suggest: Branch to target if CPTR_EL2.TFP bit is set (VFP/SIMD trapping enabled) Yes actually describes what it does. + */ +.macro skip_fpsimd_state tmp, target + mrs \tmp, cptr_el2 + tbnz\tmp, #CPTR_EL2_TFP_SHIFT, \target +.endm + + .macro compute_debug_state target // Compute debug state: If any of KDE, MDE or KVM_ARM64_DEBUG_DIRTY // is set, we do a full save/restore cycle and disable trapping. @@ -763,6 +772,7 @@ ldr x2, [x0, #VCPU_HCR_EL2] msr hcr_el2, x2 mov x2, #CPTR_EL2_TTA + orr x2, x2, #CPTR_EL2_TFP msr cptr_el2, x2 mov x2, #(1 15) // Trap CP15 Cr=15 @@ -785,7 +795,6 @@ .macro deactivate_traps mov x2, #HCR_RW msr hcr_el2, x2 - msr cptr_el2, xzr msr hstr_el2, xzr mrs x2, mdcr_el2 @@ -912,6 +921,28 @@ __restore_fpsimd: restore_fpsimd ret +switch_to_guest_fpsimd: + pushx4, lr + + mrs x2, cptr_el2 + bic x2, x2, #CPTR_EL2_TFP + msr cptr_el2, x2 + + mrs x0, tpidr_el2 + + ldr x2, [x0, #VCPU_HOST_CONTEXT] + kern_hyp_va x2 + bl __save_fpsimd + + add x2, x0, #VCPU_CONTEXT + bl __restore_fpsimd + + pop x4, lr + pop x2, x3 + pop x0, x1 + + eret + /* * u64 __kvm_vcpu_run(struct kvm_vcpu *vcpu); * @@ -932,7 +963,6 @@ ENTRY(__kvm_vcpu_run) kern_hyp_va x2 save_host_regs - bl __save_fpsimd bl __save_sysregs compute_debug_state 1f @@ -948,7 +978,6 @@ ENTRY(__kvm_vcpu_run) add x2, x0, #VCPU_CONTEXT bl __restore_sysregs - bl __restore_fpsimd skip_debug_state x3, 1f bl __restore_debug @@ -967,7 +996,9 @@ __kvm_vcpu_return: add x2, x0, #VCPU_CONTEXT save_guest_regs + skip_fpsimd_state x3, 1f bl __save_fpsimd +1: bl __save_sysregs skip_debug_state x3, 1f @@ -986,7 +1017,11 @@ __kvm_vcpu_return: kern_hyp_va x2 bl __restore_sysregs + skip_fpsimd_state x3, 1f bl __restore_fpsimd +1: + /* Clear FPSIMD and Trace trapping */ + msr cptr_el2, xzr why not simply move the deactivate_traps down here instead? Putting deactivate_traps there trashes x2, setup earlier to restore debug, host registers from host context Do we want deactivate_traps to use another register and move the macro there? Or leave as is? There was some clean symmetry in the code by using deactivate traps, but given this, I don't care strongly which way we end up doing it. I agree. Also it probably makes more sense to keep the trap disable code together to match the trap enables, without objection from Marc I'll rework the patch, repost it after Monday. Thanks, - Mario Thanks, -Christoffer -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi
On 07/03/2015 05:29 PM, Pavel Fedin wrote: Hi! OK so both of you say the same thing. Will respin accordingly You may also want to add this: Tested-by: Pavel Fedin p.fe...@samsung.com Thanks Pavel for the intent. However since I am going to change the uapi and correct the bug you spotted out, this will need to be tested again. T-b is applied when the code is stable and bug-free I think ;-) Best Regards Eric Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 12/17] irq: bypass: Extend skeleton for ARM forwarding control
On 03/07/2015 15:12, Eric Auger wrote: Linux IRQ and active should be okay. As to the vfio_device handle, you should link it from the vfio_platform_device instead. And for the vfio_platform_device, you can link it from the vfio_platform_irq instead. For this last one, I don't think this is achievable since if I store the vfio_platform_irq in the opaque, it matches irqs[i] of vfio_platform_device and I don't have any mean to retrieve i when calling container_of. Right, notice I said link it: struct vfio_platform_irq *irq = container_of(prod, struct vfio_platform_irq, producer); struct vfio_platform_device *vpdev = irq-vpdev; struct vfio_device *vdev = vpdev-vdev; Would this be okay? Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] arm/arm64: drop mmu_set_enabled
On 25/06/2015 20:45, Andrew Jones wrote:
The mmu is enabled automatically for all cpus, they must disable it
themselves if they don't want it on. Switch from managing a cpumask
of enabled cpus to one of disabled cpus. This allows us to remove
the mmu_set_enabled call from secondary_cinit, and the function all
together.
Signed-off-by: Andrew Jones drjo...@redhat.com
---
lib/arm/asm/mmu-api.h | 1 -
lib/arm/mmu.c | 21 ++---
lib/arm/smp.c | 1 -
3 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/lib/arm/asm/mmu-api.h b/lib/arm/asm/mmu-api.h
index c46c4b08b14cc..12fdc57918c27 100644
--- a/lib/arm/asm/mmu-api.h
+++ b/lib/arm/asm/mmu-api.h
@@ -2,7 +2,6 @@
#define __ASMARM_MMU_API_H_
extern pgd_t *mmu_idmap;
extern bool mmu_enabled(void);
-extern void mmu_set_enabled(void);
extern void mmu_enable(pgd_t *pgtable);
extern void mmu_disable(void);
extern void mmu_enable_idmap(void);
diff --git a/lib/arm/mmu.c b/lib/arm/mmu.c
index 5966b408cb455..ad558e177dd1c 100644
--- a/lib/arm/mmu.c
+++ b/lib/arm/mmu.c
@@ -14,32 +14,31 @@ extern unsigned long etext;
pgd_t *mmu_idmap;
-static cpumask_t mmu_enabled_cpumask;
+static cpumask_t mmu_disabled_cpumask;
+
bool mmu_enabled(void)
{
- struct thread_info *ti = current_thread_info();
- return cpumask_test_cpu(ti-cpu, mmu_enabled_cpumask);
-}
+ int cpu = current_thread_info()-cpu;
-void mmu_set_enabled(void)
-{
- struct thread_info *ti = current_thread_info();
- cpumask_set_cpu(ti-cpu, mmu_enabled_cpumask);
+ return !cpumask_test_cpu(cpu, mmu_disabled_cpumask);
}
extern void asm_mmu_enable(phys_addr_t pgtable);
void mmu_enable(pgd_t *pgtable)
{
+ int cpu = current_thread_info()-cpu;
+
asm_mmu_enable(__pa(pgtable));
flush_tlb_all();
- mmu_set_enabled();
+ cpumask_clear_cpu(cpu, mmu_disabled_cpumask);
}
extern void asm_mmu_disable(void);
void mmu_disable(void)
{
- struct thread_info *ti = current_thread_info();
- cpumask_clear_cpu(ti-cpu, mmu_enabled_cpumask);
+ int cpu = current_thread_info()-cpu;
+
+ cpumask_set_cpu(cpu, mmu_disabled_cpumask);
asm_mmu_disable();
}
diff --git a/lib/arm/smp.c b/lib/arm/smp.c
index f389ba6598faa..ca435dcd5f4a2 100644
--- a/lib/arm/smp.c
+++ b/lib/arm/smp.c
@@ -23,7 +23,6 @@ secondary_entry_fn secondary_cinit(void)
secondary_entry_fn entry;
thread_info_init(ti, 0);
- mmu_set_enabled();
/*
* Save secondary_data.entry locally to avoid opening a race
This is needed too on a Cubietruck:
diff --git a/lib/arm/asm/mmu-api.h b/lib/arm/asm/mmu-api.h
index 12fdc57..73bac70 100644
--- a/lib/arm/asm/mmu-api.h
+++ b/lib/arm/asm/mmu-api.h
@@ -3,6 +3,7 @@
extern pgd_t *mmu_idmap;
extern bool mmu_enabled(void);
extern void mmu_enable(pgd_t *pgtable);
+extern void mmu_mark_disabled(int cpu);
extern void mmu_disable(void);
extern void mmu_enable_idmap(void);
extern void mmu_init_io_sect(pgd_t *pgtable, unsigned long virt_offset);
diff --git a/lib/arm/mmu.c b/lib/arm/mmu.c
index ad558e1..8ff659b 100644
--- a/lib/arm/mmu.c
+++ b/lib/arm/mmu.c
@@ -14,7 +14,8 @@ extern unsigned long etext;
pgd_t *mmu_idmap;
-static cpumask_t mmu_disabled_cpumask;
+/* CPU 0 starts with disabled MMU */
+static cpumask_t mmu_disabled_cpumask = { {1} };
bool mmu_enabled(void)
{
@@ -33,6 +34,11 @@ void mmu_enable(pgd_t *pgtable)
cpumask_clear_cpu(cpu, mmu_disabled_cpumask);
}
+void mmu_mark_disabled(int cpu)
+{
+ cpumask_set_cpu(cpu, mmu_disabled_cpumask);
+}
+
extern void asm_mmu_disable(void);
void mmu_disable(void)
{
diff --git a/lib/arm/psci.c b/lib/arm/psci.c
index aca8885..c4469c9 100644
--- a/lib/arm/psci.c
+++ b/lib/arm/psci.c
@@ -9,6 +9,7 @@
#include asm/psci.h
#include asm/setup.h
#include asm/page.h
+#include asm/mmu-api.h
#define T PSCI_INVOKE_ARG_TYPE
__attribute__((noinline))
@@ -29,6 +30,7 @@ int psci_cpu_on(unsigned long cpuid, unsigned long
entry_point)
extern void secondary_entry(void);
int cpu_psci_cpu_boot(unsigned int cpu)
{
+ mmu_mark_disabled(cpu);
int err = psci_cpu_on(cpus[cpu], __pa(secondary_entry));
if (err)
printf(failed to boot CPU%d (%d)\n, cpu, err);
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] arm/arm64: spinlocks: fix memory barriers
On 25/06/2015 18:12, Andrew Jones wrote:
It shouldn't be necessary to use a barrier on the way into
spin_lock. We'll be focused on a single address until we get
it (exclusively) set, and then we'll do a barrier on the way
out. Also, it does make sense to do a barrier on the way in
to spin_unlock, i.e. ensure what we did in the critical section
is ordered wrt to what we do outside it, before we announce that
we're outside.
Signed-off-by: Andrew Jones drjo...@redhat.com
---
lib/arm/spinlock.c | 8
lib/arm64/spinlock.c | 5 ++---
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/lib/arm/spinlock.c b/lib/arm/spinlock.c
index 3b023ceaebf71..116ea5d7db930 100644
--- a/lib/arm/spinlock.c
+++ b/lib/arm/spinlock.c
@@ -7,10 +7,9 @@ void spin_lock(struct spinlock *lock)
{
u32 val, fail;
- dmb();
-
if (!mmu_enabled()) {
lock-v = 1;
+ smp_mb();
return;
}
@@ -25,11 +24,12 @@ void spin_lock(struct spinlock *lock)
: r (lock-v)
: cc );
} while (fail);
- dmb();
+
+ smp_mb();
}
void spin_unlock(struct spinlock *lock)
{
+ smp_mb();
lock-v = 0;
- dmb();
}
diff --git a/lib/arm64/spinlock.c b/lib/arm64/spinlock.c
index 68b68b75ba60d..a3907f03cacda 100644
--- a/lib/arm64/spinlock.c
+++ b/lib/arm64/spinlock.c
@@ -13,10 +13,9 @@ void spin_lock(struct spinlock *lock)
{
u32 val, fail;
- smp_mb();
-
if (!mmu_enabled()) {
lock-v = 1;
+ smp_mb();
return;
}
@@ -35,9 +34,9 @@ void spin_lock(struct spinlock *lock)
void spin_unlock(struct spinlock *lock)
{
+ smp_mb();
if (mmu_enabled())
asm volatile(stlrh wzr, [%0] :: r (lock-v));
else
lock-v = 0;
- smp_mb();
}
Applied, thanks.
Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] arm/arm64: Introduce mmu_disable
On 25/06/2015 20:45, Andrew Jones wrote:
Allow unit test cpus to disable the MMU. Why not? We want the
test framework to be as flexible as possible. Callers will have
to deal with the cache coherency fallout... Cache flush support
is still forthcoming to the framework though.
Signed-off-by: Andrew Jones drjo...@redhat.com
---
arm/cstart.S | 9 +
arm/cstart64.S| 8
lib/arm/asm/mmu-api.h | 1 +
lib/arm/mmu.c | 8
4 files changed, 26 insertions(+)
diff --git a/arm/cstart.S b/arm/cstart.S
index 2b7f8f3d200ef..3943867d2f219 100644
--- a/arm/cstart.S
+++ b/arm/cstart.S
@@ -159,6 +159,15 @@ asm_mmu_enable:
mov pc, lr
+.globl asm_mmu_disable
+asm_mmu_disable:
+ /* SCTLR */
+ mrc p15, 0, r0, c1, c0, 0
+ bic r0, #CR_M
+ mcr p15, 0, r0, c1, c0, 0
+ isb
+ mov pc, lr
+
/*
* Vector stubs
* Simplified version of the Linux kernel implementation
diff --git a/arm/cstart64.S b/arm/cstart64.S
index cdda13c17af9e..44cff32d0f18e 100644
--- a/arm/cstart64.S
+++ b/arm/cstart64.S
@@ -146,6 +146,14 @@ asm_mmu_enable:
ret
+.globl asm_mmu_disable
+asm_mmu_disable:
+ mrs x0, sctlr_el1
+ bic x0, x0, SCTLR_EL1_M
+ msr sctlr_el1, x0
+ isb
+ ret
+
/*
* Vectors
* Adapted from arch/arm64/kernel/entry.S
diff --git a/lib/arm/asm/mmu-api.h b/lib/arm/asm/mmu-api.h
index 68dc707d67241..c46c4b08b14cc 100644
--- a/lib/arm/asm/mmu-api.h
+++ b/lib/arm/asm/mmu-api.h
@@ -4,6 +4,7 @@ extern pgd_t *mmu_idmap;
extern bool mmu_enabled(void);
extern void mmu_set_enabled(void);
extern void mmu_enable(pgd_t *pgtable);
+extern void mmu_disable(void);
extern void mmu_enable_idmap(void);
extern void mmu_init_io_sect(pgd_t *pgtable, unsigned long virt_offset);
extern void mmu_set_range_sect(pgd_t *pgtable, unsigned long virt_offset,
diff --git a/lib/arm/mmu.c b/lib/arm/mmu.c
index 732000a8eb088..5966b408cb455 100644
--- a/lib/arm/mmu.c
+++ b/lib/arm/mmu.c
@@ -35,6 +35,14 @@ void mmu_enable(pgd_t *pgtable)
mmu_set_enabled();
}
+extern void asm_mmu_disable(void);
+void mmu_disable(void)
+{
+ struct thread_info *ti = current_thread_info();
+ cpumask_clear_cpu(ti-cpu, mmu_enabled_cpumask);
+ asm_mmu_disable();
+}
+
void mmu_set_range_ptes(pgd_t *pgtable, unsigned long virt_offset,
unsigned long phys_start, unsigned long phys_end,
pgprot_t prot)
Applied, thanks.
Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 08/11] KVM: arm64: introduce vcpu-arch.debug_ptr
On Wed, Jul 01, 2015 at 07:29:00PM +0100, Alex Bennée wrote:
This introduces a level of indirection for the debug registers. Instead
of using the sys_regs[] directly we store registers in a structure in
the vcpu. The new kvm_arm_reset_debug_ptr() sets the debug ptr to the
guest context.
This also entails updating the sys_regs code to access this new
structure. New access function have been added for each set of debug
registers. The generic functions are still used for the few registers
stored in the main context.
New access function pointers have been added to the sys_reg_desc
structure to support the GET/SET_ONE_REG ioctl operations.
Signed-off-by: Alex Bennée alex.ben...@linaro.org
---
v6:
- fix up some ws issues
- correct clobber info
- re-word commentary in kvm_host.h
- fix endian access issues for aarch32 fields
- revert all KVM_GET/SET_ONE_REG to 64bit (also see ABI update)
v7
- new fn kvm_arm_reset_debug_ptr(), stubbed for arm
- split trap fns into bcr,bvr,bcr,wvr and wxvr
- add set/get fns to sys_regs_desc
- reg_to_dbg/dbg_to_reg helpers for 32bit support
---
arch/arm/include/asm/kvm_host.h | 2 +-
arch/arm/kvm/arm.c| 2 +
arch/arm64/include/asm/kvm_asm.h | 24 ++--
arch/arm64/include/asm/kvm_host.h | 17 ++-
arch/arm64/kernel/asm-offsets.c | 6 +
arch/arm64/kvm/debug.c| 9 ++
arch/arm64/kvm/hyp.S | 24 ++--
arch/arm64/kvm/sys_regs.c | 281
++
arch/arm64/kvm/sys_regs.h | 6 +
9 files changed, 321 insertions(+), 50 deletions(-)
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 746c0c69..f42759b 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -239,5 +239,5 @@ static inline void kvm_arch_sched_in(struct kvm_vcpu
*vcpu, int cpu) {}
static inline void kvm_arm_init_debug(void) {}
static inline void kvm_arm_setup_debug(struct kvm_vcpu *vcpu) {}
static inline void kvm_arm_clear_debug(struct kvm_vcpu *vcpu) {}
-
+static inline void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu) {}
#endif /* __ARM_KVM_HOST_H__ */
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index af60e6f..525473f 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -279,6 +279,8 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
/* Set up the timer */
kvm_timer_vcpu_init(vcpu);
+ kvm_arm_reset_debug_ptr(vcpu);
+
return 0;
}
diff --git a/arch/arm64/include/asm/kvm_asm.h
b/arch/arm64/include/asm/kvm_asm.h
index d6b507e..e997404 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -46,24 +46,16 @@
#define CNTKCTL_EL1 20 /* Timer Control Register (EL1) */
#define PAR_EL1 21 /* Physical Address Register */
#define MDSCR_EL122 /* Monitor Debug System Control Register */
-#define DBGBCR0_EL1 23 /* Debug Breakpoint Control Registers (0-15) */
-#define DBGBCR15_EL1 38
-#define DBGBVR0_EL1 39 /* Debug Breakpoint Value Registers (0-15) */
-#define DBGBVR15_EL1 54
-#define DBGWCR0_EL1 55 /* Debug Watchpoint Control Registers (0-15) */
-#define DBGWCR15_EL1 70
-#define DBGWVR0_EL1 71 /* Debug Watchpoint Value Registers (0-15) */
-#define DBGWVR15_EL1 86
-#define MDCCINT_EL1 87 /* Monitor Debug Comms Channel Interrupt Enable
Reg */
+#define MDCCINT_EL1 23 /* Monitor Debug Comms Channel Interrupt Enable
Reg */
/* 32bit specific registers. Keep them at the end of the range */
-#define DACR32_EL2 88 /* Domain Access Control Register */
-#define IFSR32_EL2 89 /* Instruction Fault Status Register */
-#define FPEXC32_EL2 90 /* Floating-Point Exception Control
Register */
-#define DBGVCR32_EL291 /* Debug Vector Catch Register */
-#define TEECR32_EL1 92 /* ThumbEE Configuration Register */
-#define TEEHBR32_EL193 /* ThumbEE Handler Base Register */
-#define NR_SYS_REGS 94
+#define DACR32_EL2 24 /* Domain Access Control Register */
+#define IFSR32_EL2 25 /* Instruction Fault Status Register */
+#define FPEXC32_EL2 26 /* Floating-Point Exception Control
Register */
+#define DBGVCR32_EL227 /* Debug Vector Catch Register */
+#define TEECR32_EL1 28 /* ThumbEE Configuration Register */
+#define TEEHBR32_EL129 /* ThumbEE Handler Base Register */
+#define NR_SYS_REGS 30
/* 32bit mapping */
#define c0_MPIDR (MPIDR_EL1 * 2) /* MultiProcessor ID Register */
diff --git a/arch/arm64/include/asm/kvm_host.h
b/arch/arm64/include/asm/kvm_host.h
index e2db6a6..461d288 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -108,11 +108,25 @@ struct kvm_vcpu_arch {
Re: [PULL] virtio/vhost: cross endian support
On Fri, Jul 3, 2015 at 12:59 AM, Michael S. Tsirkin m...@redhat.com wrote: Linus, could you please clarify whether making the feature depend on the cross-endian guest support would address your comment, and whether you think this can be merged as is, and the dependency added after -rc1? I'll take it. I still think dynamic byte order is a fundamental (and much too common) mistake, but whatever. Linus -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/13] KVM: arm64: implement ITS command queue command handlers
On Fri, Jul 03, 2015 at 04:57:04PM +0100, Andre Przywara wrote:
Hi Christoffer,
+
+static struct its_collection *vits_new_collection(struct kvm *kvm, u32
coll_id)
+{
+ struct its_collection *collection;
+
+ collection = kmalloc(sizeof(struct its_collection), GFP_KERNEL);
If I manage to understand the structure here, you're calling all these
handler functions with a spinlock held so any operation that may sleep
could cause your system to deadlock.
I'll stop looking for these and recommend you go over the whole series
for these.
Do you reckon it would be sufficient to just avoid the kmallocs inside
the lock? For this case above we could go with some storage space
preallocated outside of the lock (I hope).
Yes, you can preallocate or you need to grab a mutex instead of a
spinlock...
Perhaps the right thing to do is to synchronize access to your data
structure (why you hold the spinlock right?) with RCU if you can...
Well, the point is that there is not one ITS data structure, but it's a
mesh of lists connected to each other. I'd like to avoid going down with
RCU there, so I'd like to keep it all under one lock.
I wonder if this could be mutex_lock_interruptible, though. From the top
of your head, is there anything that would prevent that? I reckon ITS
access contention is rather rare (though possible), so a sleeping VCPU
wouldn't harm us so much in practice, would it?
We know from experience from x86 that one of the things they had to look
at was to get the run-loop lock-free, and we went through a lot of
effort to do that on ARM too. Along came the vgic and that was out the
window, and now it feels like we're just grabbing spinlocks all over the
place.
I'm fine with a mutex if other solutions are not easy/possible and it's
in a truly non-critical path, but I wouldn't to speculate about the
level of contention at this point without profiling something.
In any case, let's fix the potential host-kernel deadlock issues in the
most elegant way first and let's try to think about not grabbing too
many spinlocks in this code and take it from there.
Thanks,
-Christoffer
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 09/11] KVM: arm: implement lazy world switch for debug registers
On Fri, Jul 03, 2015 at 06:06:48PM +0800, Zhichao Huang wrote:
On June 30, 2015 9:15:22 PM GMT+08:00, Christoffer Dall
christoffer.d...@linaro.org wrote:
On Mon, Jun 22, 2015 at 06:41:32PM +0800, Zhichao Huang wrote:
Implement switching of the debug registers. While the number
of registers is massive, CPUs usually don't implement them all
(A15 has 6 breakpoints and 4 watchpoints, which gives us a total
of 22 registers only).
Notice that, for ARMv7, if the CONFIG_HAVE_HW_BREAKPOINT is set in
the guest, debug is always actively in use (ARM_DSCR_MDBGEN set).
We have to do the save/restore dance in this case, because the host
and the guest might use their respective debug registers at any moment.
this sounds expensive, and I suggested an alternative approach in the
previsou patch. In any case, measuring the impact on this on hardware
would be a great idea...
If the CONFIG_HAVE_HW_BREAKPOINT is not set, and if no one flagged
the debug registers as dirty, we only save/resotre DBGDSCR.
restore
Signed-off-by: Zhichao Huang zhichao.hu...@linaro.org
---
arch/arm/kvm/interrupts.S | 16 +++
arch/arm/kvm/interrupts_head.S | 249
-
2 files changed, 263 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S
index 79caf79..d626275 100644
--- a/arch/arm/kvm/interrupts.S
+++ b/arch/arm/kvm/interrupts.S
@@ -116,6 +116,12 @@ ENTRY(__kvm_vcpu_run)
read_cp15_state store_to_vcpu = 0
write_cp15_state read_from_vcpu = 1
+ @ Store hardware CP14 state and load guest state
+ compute_debug_state 1f
+ bl __save_host_debug_regs
+ bl __restore_guest_debug_regs
+
+1:
@ If the host kernel has not been configured with VFPv3 support,
@ then it is safer if we deny guests from using it as well.
#ifdef CONFIG_VFPv3
@@ -201,6 +207,16 @@ after_vfp_restore:
mrc p15, 0, r2, c0, c0, 5
mcr p15, 4, r2, c0, c0, 5
+ @ Store guest CP14 state and restore host state
+ skip_debug_state 1f
+ bl __save_guest_debug_regs
+ bl __restore_host_debug_regs
+ /* Clear the dirty flag for the next run, as all the state has
+ * already been saved. Note that we nuke the whole 32bit word.
+ * If we ever add more flags, we'll have to be more careful...
+ */
+ clear_debug_dirty_bit
+1:
@ Store guest CP15 state and restore host state
read_cp15_state store_to_vcpu = 1
write_cp15_state read_from_vcpu = 0
diff --git a/arch/arm/kvm/interrupts_head.S
b/arch/arm/kvm/interrupts_head.S
index 5662c39..ed406be 100644
--- a/arch/arm/kvm/interrupts_head.S
+++ b/arch/arm/kvm/interrupts_head.S
@@ -7,6 +7,7 @@
#define VCPU_USR_SP (VCPU_USR_REG(13))
#define VCPU_USR_LR (VCPU_USR_REG(14))
#define CP15_OFFSET(_cp15_reg_idx) (VCPU_CP15 + (_cp15_reg_idx * 4))
+#define CP14_OFFSET(_cp14_reg_idx) (VCPU_CP14 + ((_cp14_reg_idx) *
4))
/*
* Many of these macros need to access the VCPU structure, which is
always
@@ -168,8 +169,7 @@ vcpu .reqr0 @ vcpu pointer always
in r0
* Clobbers *all* registers.
*/
.macro restore_guest_regs
- /* reset DBGDSCR to disable debug mode */
- mov r2, #0
+ ldr r2, [vcpu, #CP14_OFFSET(cp14_DBGDSCRext)]
mcr p14, 0, r2, c0, c2, 2
restore_guest_regs_mode svc, #VCPU_SVC_REGS
@@ -250,6 +250,10 @@ vcpu .reqr0 @ vcpu pointer always
in r0
save_guest_regs_mode abt, #VCPU_ABT_REGS
save_guest_regs_mode und, #VCPU_UND_REGS
save_guest_regs_mode irq, #VCPU_IRQ_REGS
+
+ /* DBGDSCR reg */
+ mrc p14, 0, r2, c0, c1, 0
+ str r2, [vcpu, #CP14_OFFSET(cp14_DBGDSCRext)]
.endm
/* Reads cp15 registers from hardware and stores them in memory
@@ -449,6 +453,231 @@ vcpu .reqr0 @ vcpu pointer always
in r0
str r5, [vcpu, #VCPU_DEBUG_FLAGS]
.endm
+/* Assume r11/r12 in used, clobbers r2-r10 */
+.macro cp14_read_and_push Op2 skip_num
+ cmp \skip_num, #8
+ // if (skip_num = 8) then skip c8-c15 directly
+ bge 1f
+ adr r2, 9998f
+ add r2, r2, \skip_num, lsl #2
+ bx r2
+1:
+ adr r2, f
+ sub r3, \skip_num, #8
+ add r2, r2, r3, lsl #2
+ bx r2
+9998:
+ mrc p14, 0, r10, c0, c15, \Op2
+ mrc p14, 0, r9, c0, c14, \Op2
+ mrc p14, 0, r8, c0, c13, \Op2
+ mrc p14, 0, r7, c0, c12, \Op2
+ mrc p14, 0, r6, c0, c11, \Op2
+ mrc p14, 0, r5, c0, c10, \Op2
+ mrc p14, 0, r4, c0, c9, \Op2
+ mrc p14, 0, r3, c0, c8, \Op2
+ push{r3-r10}
you probably don't want to do more stores to memory than required
Yeah, there is no need to push some registers, but I can't find a better
way to optimize it, is there any precedents that I can refer to?
Can you not simply do what you do
Re: [PATCH v7 08/11] KVM: arm64: introduce vcpu-arch.debug_ptr
On Fri, Jul 03, 2015 at 08:14:52AM +0100, Alex Bennée wrote:
Christoffer Dall christoffer.d...@linaro.org writes:
On Wed, Jul 01, 2015 at 07:29:00PM +0100, Alex Bennée wrote:
This introduces a level of indirection for the debug registers. Instead
of using the sys_regs[] directly we store registers in a structure in
the vcpu. The new kvm_arm_reset_debug_ptr() sets the debug ptr to the
guest context.
This also entails updating the sys_regs code to access this new
structure. New access function have been added for each set of debug
registers. The generic functions are still used for the few registers
stored in the main context.
New access function pointers have been added to the sys_reg_desc
structure to support the GET/SET_ONE_REG ioctl operations.
Why is this needed?
Previously I had a hacky:
if (r-access == trap_debug64)
return debug_get64(vcpu, r, reg, uaddr);
Which used the same offset information. Now we have a cleaner:
if (r-set)
return (r-set)(vcpu, r, reg, uaddr);
Which accesses the structure directly, as the trap functions do:
__u64 *r = vcpu-arch.vcpu_debug_state.dbg_bvr[rd-reg];
if (copy_from_user(uaddr, r, KVM_REG_SIZE(reg-id)) != 0)
return -EFAULT;
return 0;
I get it now, had to take another look at sys_regs.c.
I think this commit message needs a littel tweaking saying Because we
no longer give the sys_regs offset for the sys_reg_desc-reg field, but
instead the index into a debug-specific struct, the generic user-space
access code no longer works, and we are therefore forced to add specific
user_set/get functions for these registers.
At least it was hard for me to understand the rationale without this,
and I think it would be good to have for someone doing git blame later.
snip
+#if 0
+static int debug_set64(struct kvm_vcpu *vcpu, const struct sys_reg_desc
*rd,
+ const struct kvm_one_reg *reg, void __user *uaddr)
+{
+ __u64 *r = (__u64 *) ((void * )vcpu-arch.vcpu_debug_state + rd-reg);
+ if (copy_from_user(uaddr, r, KVM_REG_SIZE(reg-id)) != 0)
+ return -EFAULT;
+ return 0;
+}
+
+static int debug_get64(struct kvm_vcpu *vcpu, const struct sys_reg_desc
*rd,
+ const struct kvm_one_reg *reg, void __user *uaddr)
+{
+ __u64 *r = (__u64 *) ((void * )vcpu-arch.vcpu_debug_state + rd-reg);
+ if (copy_to_user(uaddr, r, KVM_REG_SIZE(reg-id)) != 0)
+ return -EFAULT;
+ return 0;
+}
+#endif
+
what is this ifdef'ed block of code doing here?
Oops. Yeah looks like I missed removing that after I finished the
re-factor. These where the old get/set functions I used.
int kvm_arm_sys_reg_get_reg(struct kvm_vcpu *vcpu, const struct
kvm_one_reg *reg)
{
const struct sys_reg_desc *r;
@@ -1303,6 +1530,9 @@ int kvm_arm_sys_reg_get_reg(struct kvm_vcpu *vcpu,
const struct kvm_one_reg *reg
if (!r)
return get_invariant_sys_reg(reg-id, uaddr);
+ if (r-get)
+ return (r-get)(vcpu, r, reg, uaddr);
+
return reg_to_user(uaddr, vcpu_sys_reg(vcpu, r-reg), reg-id);
}
@@ -1321,6 +1551,9 @@ int kvm_arm_sys_reg_set_reg(struct kvm_vcpu *vcpu,
const struct kvm_one_reg *reg
if (!r)
return set_invariant_sys_reg(reg-id, uaddr);
+ if (r-set)
+ return (r-set)(vcpu, r, reg, uaddr);
+
return reg_from_user(vcpu_sys_reg(vcpu, r-reg), uaddr, reg-id);
}
diff --git a/arch/arm64/kvm/sys_regs.h b/arch/arm64/kvm/sys_regs.h
index d411e25..9265e7d 100644
--- a/arch/arm64/kvm/sys_regs.h
+++ b/arch/arm64/kvm/sys_regs.h
@@ -55,6 +55,12 @@ struct sys_reg_desc {
/* Value (usually reset value) */
u64 val;
+
+ /* Get/Set functions, fallback if NULL */
Is this only meant for usersapce access or when should one use these?
Yes for GET/SET
ok, see other mail for potential rename to get_user / set_user if you
like the idea.
Thanks,
-Christoffer
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 12/17] irq: bypass: Extend skeleton for ARM forwarding control
On 03/07/2015 09:00, Wu, Feng wrote:
struct irq_bypass_consumer {
struct list_head node;
void *token;
+ unsigned irq;/*got from producer when registered*/
void (*add_producer)(struct irq_bypass_producer *,
struct irq_bypass_consumer *);
void (*del_producer)(struct irq_bypass_producer *,
struct irq_bypass_consumer *);
+ void (*update)(struct irq_bypass_consumer *);
};
'update' is used to update the IRTE, while irq is initialized when
registered, which is used to find the right IRTE.
Feel free to add update in your PI patches. I am not sure if irq
belongs here or in the containing struct. You can play with both and
submit the version that looks better to you.
Thanks for your review, Paolo. In my understanding, irq comes from
the producer side, while gsi belongs to the consumer, so we need
to get the irq from the producer somewhere. I am not sure adding
irq here is the good way, but what I need is in the 'update' function,
I have irq, gsi in hand. :)
It's difficult to say without seeing the patches... The IRQ is stored
in the producer already with Eric's changes. If you need to store the
old IRQ value, because update needs to do something with it, then I
think irq belongs in the container struct.
Perhaps update needs to have a producer argument as well?
Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 08/11] KVM: arm64: introduce vcpu-arch.debug_ptr
Christoffer Dall christoffer.d...@linaro.org writes:
On Wed, Jul 01, 2015 at 07:29:00PM +0100, Alex Bennée wrote:
This introduces a level of indirection for the debug registers. Instead
of using the sys_regs[] directly we store registers in a structure in
the vcpu. The new kvm_arm_reset_debug_ptr() sets the debug ptr to the
guest context.
This also entails updating the sys_regs code to access this new
structure. New access function have been added for each set of debug
registers. The generic functions are still used for the few registers
stored in the main context.
New access function pointers have been added to the sys_reg_desc
structure to support the GET/SET_ONE_REG ioctl operations.
Why is this needed?
Previously I had a hacky:
if (r-access == trap_debug64)
return debug_get64(vcpu, r, reg, uaddr);
Which used the same offset information. Now we have a cleaner:
if (r-set)
return (r-set)(vcpu, r, reg, uaddr);
Which accesses the structure directly, as the trap functions do:
__u64 *r = vcpu-arch.vcpu_debug_state.dbg_bvr[rd-reg];
if (copy_from_user(uaddr, r, KVM_REG_SIZE(reg-id)) != 0)
return -EFAULT;
return 0;
snip
+#if 0
+static int debug_set64(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd,
+const struct kvm_one_reg *reg, void __user *uaddr)
+{
+__u64 *r = (__u64 *) ((void * )vcpu-arch.vcpu_debug_state + rd-reg);
+if (copy_from_user(uaddr, r, KVM_REG_SIZE(reg-id)) != 0)
+return -EFAULT;
+return 0;
+}
+
+static int debug_get64(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd,
+const struct kvm_one_reg *reg, void __user *uaddr)
+{
+__u64 *r = (__u64 *) ((void * )vcpu-arch.vcpu_debug_state + rd-reg);
+if (copy_to_user(uaddr, r, KVM_REG_SIZE(reg-id)) != 0)
+return -EFAULT;
+return 0;
+}
+#endif
+
what is this ifdef'ed block of code doing here?
Oops. Yeah looks like I missed removing that after I finished the
re-factor. These where the old get/set functions I used.
int kvm_arm_sys_reg_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg
*reg)
{
const struct sys_reg_desc *r;
@@ -1303,6 +1530,9 @@ int kvm_arm_sys_reg_get_reg(struct kvm_vcpu *vcpu,
const struct kvm_one_reg *reg
if (!r)
return get_invariant_sys_reg(reg-id, uaddr);
+if (r-get)
+return (r-get)(vcpu, r, reg, uaddr);
+
return reg_to_user(uaddr, vcpu_sys_reg(vcpu, r-reg), reg-id);
}
@@ -1321,6 +1551,9 @@ int kvm_arm_sys_reg_set_reg(struct kvm_vcpu *vcpu,
const struct kvm_one_reg *reg
if (!r)
return set_invariant_sys_reg(reg-id, uaddr);
+if (r-set)
+return (r-set)(vcpu, r, reg, uaddr);
+
return reg_from_user(vcpu_sys_reg(vcpu, r-reg), uaddr, reg-id);
}
diff --git a/arch/arm64/kvm/sys_regs.h b/arch/arm64/kvm/sys_regs.h
index d411e25..9265e7d 100644
--- a/arch/arm64/kvm/sys_regs.h
+++ b/arch/arm64/kvm/sys_regs.h
@@ -55,6 +55,12 @@ struct sys_reg_desc {
/* Value (usually reset value) */
u64 val;
+
+/* Get/Set functions, fallback if NULL */
Is this only meant for usersapce access or when should one use these?
Yes for GET/SET
+int (*get)(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd,
+ const struct kvm_one_reg *reg, void __user *uaddr);
+int (*set)(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd,
+ const struct kvm_one_reg *reg, void __user *uaddr);
};
static inline void print_sys_reg_instr(const struct sys_reg_params *p)
--
2.4.5
--
Alex Bennée
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC 12/17] irq: bypass: Extend skeleton for ARM forwarding control
-Original Message-
From: Paolo Bonzini [mailto:pbonz...@redhat.com]
Sent: Friday, July 03, 2015 3:06 PM
To: Wu, Feng; Eric Auger; eric.au...@st.com;
linux-arm-ker...@lists.infradead.org; kvm...@lists.cs.columbia.edu;
kvm@vger.kernel.org; christoffer.d...@linaro.org; marc.zyng...@arm.com;
alex.william...@redhat.com; avi.kiv...@gmail.com; mtosa...@redhat.com;
j...@8bytes.org; b.rey...@virtualopensystems.com
Cc: linux-ker...@vger.kernel.org; patc...@linaro.org
Subject: Re: [RFC 12/17] irq: bypass: Extend skeleton for ARM forwarding
control
On 03/07/2015 09:00, Wu, Feng wrote:
struct irq_bypass_consumer {
struct list_head node;
void *token;
+ unsigned irq; /*got from producer when registered*/
void (*add_producer)(struct irq_bypass_producer *,
struct irq_bypass_consumer *);
void (*del_producer)(struct irq_bypass_producer *,
struct irq_bypass_consumer *);
+ void (*update)(struct irq_bypass_consumer *);
};
'update' is used to update the IRTE, while irq is initialized when
registered, which is used to find the right IRTE.
Feel free to add update in your PI patches. I am not sure if irq
belongs here or in the containing struct. You can play with both and
submit the version that looks better to you.
Thanks for your review, Paolo. In my understanding, irq comes from
the producer side, while gsi belongs to the consumer, so we need
to get the irq from the producer somewhere. I am not sure adding
irq here is the good way, but what I need is in the 'update' function,
I have irq, gsi in hand. :)
It's difficult to say without seeing the patches... The IRQ is stored
in the producer already with Eric's changes. If you need to store the
old IRQ value, because update needs to do something with it, then I
think irq belongs in the container struct.
Perhaps update needs to have a producer argument as well?
I also consider this method, basically, I will call 'update' in irqfd_update(),
but seems I need do extra things to get the producer structure (such as,
iterate the producer list to find the one with the same 'token') before
calling 'update' from consumer side. I am not sure it is worth doing
that way.
Thanks,
Feng
Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64/kvm: Add generic v8 KVM target
On 02/07/15 21:29, Chalamarla, Tirumalesh wrote: is there a chance that this get merged in to 4.2? if not is it possible to accept the other patches like adding implementations explicitly(like Thunder). We first need to reach a conclusion on this. Until then, I don't plan to get anything in. As for 4.2, it feels way too late (the merge window is almost closed now). Thanks, M. Thanks, Tirumalesh. On Jun 29, 2015, at 11:39 AM, Chalamarla, Tirumalesh tirumalesh.chalama...@caviumnetworks.com mailto:tirumalesh.chalama...@caviumnetworks.com wrote: On Jun 29, 2015, at 10:52 AM, Marc Zyngier marc.zyng...@arm.com mailto:marc.zyng...@arm.com wrote: On 29/06/15 18:38, Peter Maydell wrote: On 29 June 2015 at 18:30, Marc Zyngier marc.zyng...@arm.com mailto:marc.zyng...@arm.com wrote: On 29/06/15 18:13, Chalamarla, Tirumalesh wrote: Will this also prevents migrating between same implementations, if no how is this identified. This shouldn't. It is pretty easy to look at the incoming guest's MIDR, and verify that it matches the default MIDR on the receiving system. Any difference, and the migration should abort. Do you really want to forbid migration between (say) Cortex-A57 r3p0 and Cortex-A57 r3p1 ? That seems pretty harsh. I think we may need to allow for some flexibility (same major version only, or +/- 1 minor version...). The idea I'm trying to convey is that with generic CPI, migration is not guaranteed unless we're on extremely similar hardware. yes, this is the point i am trying to make, we need some flexibility. so that it works with same chips with different passes may be. if we are allowing this, then we are not putting emulation as a requirement. Thanks, Tirumalesh. M. -- Jazz is not dead. It just smells funny... -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64/kvm: Add generic v8 KVM target
On 03/07/15 09:12, Peter Maydell wrote: On 3 July 2015 at 09:08, Marc Zyngier marc.zyng...@arm.com wrote: On 02/07/15 21:29, Chalamarla, Tirumalesh wrote: is there a chance that this get merged in to 4.2? if not is it possible to accept the other patches like adding implementations explicitly(like Thunder). We first need to reach a conclusion on this. Until then, I don't plan to get anything in. As for 4.2, it feels way too late (the merge window is almost closed now). I would still like to see the proponents of this patch say what their model is for userspace support of cross-host migration, if we're abandoning the model the current API envisages. I thought we had discussed this above, and don't really see this as a departure from the current model: - -cpu host results in GENERIC being used: VM can only be migrated to the exact same HW (no cross-host migration). MIDR should probably become RO. - -cpu host results in A57 (for example): VM can be migrated to a variety of A57 platforms, and allow for some fuzzing on the revision (or accept any revision). - -cpu a57 forces an A57 model to be emulated, always. It is always possible to migrate such a VM on any host. I think only the first point is new, but the last two are what we have (or what we should have). Does it answer your concerns, or did you have something else in mind? M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] virtio/vhost: cross endian support
On Thu, Jul 02, 2015 at 08:01:28AM +0200, Michael S. Tsirkin wrote: On Wed, Jul 01, 2015 at 12:02:50PM -0700, Linus Torvalds wrote: On Wed, Jul 1, 2015 at 2:31 AM, Michael S. Tsirkin m...@redhat.com wrote: virtio/vhost: cross endian support Ugh. Does this really have to be dynamic? Can't virtio do the sane thing, and just use a _fixed_ endianness? Doing a unconditional byte swap is faster and simpler than the crazy conditionals. That's true regardless of endianness, but gets to be even more so if the fixed endianness is little-endian, since BE is not-so-slowly fading from the world. Linus Yea, well - support for legacy BE guests on the new LE hosts is exactly the motivation for this. I dislike it too, but there are two redeeming properties that made me merge this: 1. It's a trivial amount of code: since we wrap host/guest accesses anyway, almost all of it is well hidden from drivers. 2. Sane platforms would never set flags like VHOST_CROSS_ENDIAN_LEGACY - and when it's clear, there's zero overhead (as some point it was tested by compiling with and without the patches, got the same stripped binary). Maybe we could create a Kconfig symbol to enforce point (2): prevent people from enabling it e.g. on x86. I will look into this - but it can be done by a patch on top, so I think this can be merged as is. Linus, could you please clarify whether making the feature depend on the cross-endian guest support would address your comment, and whether you think this can be merged as is, and the dependency added after -rc1? Or do you know of someone using kernel with all config options enabled undiscriminately? Thanks, -- MST -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64/kvm: Add generic v8 KVM target
On 3 July 2015 at 09:08, Marc Zyngier marc.zyng...@arm.com wrote: On 02/07/15 21:29, Chalamarla, Tirumalesh wrote: is there a chance that this get merged in to 4.2? if not is it possible to accept the other patches like adding implementations explicitly(like Thunder). We first need to reach a conclusion on this. Until then, I don't plan to get anything in. As for 4.2, it feels way too late (the merge window is almost closed now). I would still like to see the proponents of this patch say what their model is for userspace support of cross-host migration, if we're abandoning the model the current API envisages. thanks -- PMM -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 6/6] powerpc/kvm: change the condition of identifying hugetlb vm
Hi Scott Thank you for your comments. Kernel already has that function: is_vm_hugetlb_page() , but the original code didn't use it, in order to keep the coding style of the original code, I didn't use it either. For the sentence like: vma-vm_flags VM_HUGETLB , hiding it behind 'is_vm_hugetlb_page()' is ok, but the sentence like: vma-vm_flags (VM_LOCKED|VM_HUGETLB|VM_PFNMAP) appears in the patch 2/6, is it better to hide the bit combinations behind the is_vm_hugetlb_page() ? In my patch I just replaced it with vma-vm_flags (VM_LOCKED|VM_PFNMAP) || (vma-vm_flags (VM_HUGETLB|VM_MERGEABLE)) == VM_HUGETLB. I am a newbie to Linux kernel, do you have any good suggestions on this situation? Thank you Wenwei 2015-07-03 5:49 GMT+08:00 Scott Wood scottw...@freescale.com: On Wed, 2015-06-10 at 14:27 +0800, Wenwei Tao wrote: Hugetlb VMAs are not mergeable, that means a VMA couldn't have VM_HUGETLB and VM_MERGEABLE been set in the same time. So we use VM_HUGETLB to indicate new mergeable VMAs. Because of that a VMA which has VM_HUGETLB been set is a hugetlb VMA only if it doesn't have VM_MERGEABLE been set in the same time. Eww. If you must overload such bit combinations, please hide it behind a vm_is_hugetlb() function. -Scott -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 6/6] powerpc/kvm: change the condition of identifying hugetlb vm
Hi Scott Thank you for your comments. Kernel already has that function: is_vm_hugetlb_page() , but the original code didn't use it, in order to keep the coding style of the original code, I didn't use it either. For the sentence like: vma-vm_flags VM_HUGETLB , hiding it behind 'is_vm_hugetlb_page()' is ok, but the sentence like: vma-vm_flags (VM_LOCKED|VM_HUGETLB|VM_PFNMAP) appears in the patch 2/6, is it better to hide the bit combinations behind the is_vm_hugetlb_page() ? In my patch I just replaced it with vma-vm_flags (VM_LOCKED|VM_PFNMAP) || (vma-vm_flags (VM_HUGETLB|VM_MERGEABLE)) == VM_HUGETLB. I am a newbie to Linux kernel, do you have any good suggestions on this situation? Thank you Wenwei 2015-07-03 5:49 GMT+08:00 Scott Wood scottw...@freescale.com: On Wed, 2015-06-10 at 14:27 +0800, Wenwei Tao wrote: Hugetlb VMAs are not mergeable, that means a VMA couldn't have VM_HUGETLB and VM_MERGEABLE been set in the same time. So we use VM_HUGETLB to indicate new mergeable VMAs. Because of that a VMA which has VM_HUGETLB been set is a hugetlb VMA only if it doesn't have VM_MERGEABLE been set in the same time. Eww. If you must overload such bit combinations, please hide it behind a vm_is_hugetlb() function. -Scott -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 12/17] irq: bypass: Extend skeleton for ARM forwarding control
On 03/07/2015 08:54, Eric Auger wrote: Oh... we can get gsi from irq_bypass_consumer - _irqfd - gsi, so it is not needed in irq_bypass_consumer. Got it! :) The issue I have is that struct _irqfd is local to eventfd.c so it cannot be used in archi specific code. Is it acceptable to move it to kvm_host.h, naming it something like kvm_kernel_irqfd (as done for kvm_kernel_irq_routing_entry)? Would also need to move _irqfd_resampler there (kvm_kernel_irqfd_resampler). Yes, that's okay. Can you put it in a new header file kvm_irqfd.h though? Paolo irqfd user struct cannot be used in a standalone manner since we miss the kvm handle. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 12/17] irq: bypass: Extend skeleton for ARM forwarding control
On 02/07/2015 15:17, Eric Auger wrote:
+ void (*stop_producer)(struct irq_bypass_producer *);
+ void (*resume_producer)(struct irq_bypass_producer *);
Also, can you call these just stop/resume ...
+ void (*add_consumer)(struct irq_bypass_producer *,
+ struct irq_bypass_consumer *);
+ void (*del_consumer)(struct irq_bypass_producer *,
+ struct irq_bypass_consumer *);
};
struct irq_bypass_consumer {
struct list_head node;
void *token;
- void (*add_producer)(struct irq_bypass_producer *);
- void (*del_producer)(struct irq_bypass_producer *);
+ unsigned int gsi; /* the guest gsi */
+ struct kvm *kvm;
+ void (*stop_consumer)(struct irq_bypass_consumer *);
+ void (*resume_consumer)(struct irq_bypass_consumer *);
... and same here? The KVM functions could be named
- kvm_arch_irq_bypass_add_producer
- kvm_arch_irq_bypass_del_producer
- kvm_arch_irq_bypass_stop
- kvm_arch_irq_bypass_resume
Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC 12/17] irq: bypass: Extend skeleton for ARM forwarding control
-Original Message-
From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
Bonzini
Sent: Friday, July 03, 2015 2:52 PM
To: Wu, Feng; Eric Auger; eric.au...@st.com;
linux-arm-ker...@lists.infradead.org; kvm...@lists.cs.columbia.edu;
kvm@vger.kernel.org; christoffer.d...@linaro.org; marc.zyng...@arm.com;
alex.william...@redhat.com; avi.kiv...@gmail.com; mtosa...@redhat.com;
j...@8bytes.org; b.rey...@virtualopensystems.com
Cc: linux-ker...@vger.kernel.org; patc...@linaro.org
Subject: Re: [RFC 12/17] irq: bypass: Extend skeleton for ARM forwarding
control
On 03/07/2015 04:43, Wu, Feng wrote:
struct irq_bypass_consumer {
struct list_head node;
void *token;
+ unsigned irq;/*got from producer when registered*/
void (*add_producer)(struct irq_bypass_producer *,
struct irq_bypass_consumer *);
void (*del_producer)(struct irq_bypass_producer *,
struct irq_bypass_consumer *);
+ void (*update)(struct irq_bypass_consumer *);
};
'update' is used to update the IRTE, while irq is initialized when
registered, which is used to find the right IRTE.
Feel free to add update in your PI patches. I am not sure if irq
belongs here or in the containing struct. You can play with both and
submit the version that looks better to you.
Thanks for your review, Paolo. In my understanding, irq comes from
the producer side, while gsi belongs to the consumer, so we need
to get the irq from the producer somewhere. I am not sure adding
irq here is the good way, but what I need is in the 'update' function,
I have irq, gsi in hand. :)
Thanks,
Feng
Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 12/17] irq: bypass: Extend skeleton for ARM forwarding control
On 03/07/2015 04:43, Wu, Feng wrote:
struct irq_bypass_consumer {
struct list_head node;
void *token;
+ unsigned irq; /*got from producer when registered*/
void (*add_producer)(struct irq_bypass_producer *,
struct irq_bypass_consumer *);
void (*del_producer)(struct irq_bypass_producer *,
struct irq_bypass_consumer *);
+ void (*update)(struct irq_bypass_consumer *);
};
'update' is used to update the IRTE, while irq is initialized when
registered, which is used to find the right IRTE.
Feel free to add update in your PI patches. I am not sure if irq
belongs here or in the containing struct. You can play with both and
submit the version that looks better to you.
Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 12/17] irq: bypass: Extend skeleton for ARM forwarding control
Paolo, On 07/03/2015 04:24 AM, Wu, Feng wrote: -Original Message- From: Wu, Feng Sent: Friday, July 03, 2015 10:20 AM To: Paolo Bonzini; Eric Auger; eric.au...@st.com; linux-arm-ker...@lists.infradead.org; kvm...@lists.cs.columbia.edu; kvm@vger.kernel.org; christoffer.d...@linaro.org; marc.zyng...@arm.com; alex.william...@redhat.com; avi.kiv...@gmail.com; mtosa...@redhat.com; j...@8bytes.org; b.rey...@virtualopensystems.com Cc: linux-ker...@vger.kernel.org; patc...@linaro.org; Wu, Feng Subject: RE: [RFC 12/17] irq: bypass: Extend skeleton for ARM forwarding control -Original Message- From: Paolo Bonzini [mailto:pbonz...@redhat.com] Sent: Thursday, July 02, 2015 9:41 PM To: Eric Auger; eric.au...@st.com; linux-arm-ker...@lists.infradead.org; kvm...@lists.cs.columbia.edu; kvm@vger.kernel.org; christoffer.d...@linaro.org; marc.zyng...@arm.com; alex.william...@redhat.com; avi.kiv...@gmail.com; mtosa...@redhat.com; Wu, Feng; j...@8bytes.org; b.rey...@virtualopensystems.com Cc: linux-ker...@vger.kernel.org; patc...@linaro.org Subject: Re: [RFC 12/17] irq: bypass: Extend skeleton for ARM forwarding control On 02/07/2015 15:17, Eric Auger wrote: - new fields are added on producer side: linux irq, vfio_device handle, active which reflects whether the source is active (at interrupt controller level or at VFIO level - automasked -) and finally an opaque pointer which will be used to point to the vfio_platform_device in this series. Linux IRQ and active should be okay. As to the vfio_device handle, you should link it from the vfio_platform_device instead. And for the vfio_platform_device, you can link it from the vfio_platform_irq instead. Once you've done this, embed the irq_bypass_producer struct in the vfio_platform_irq struct; in the new kvm_arch_* functions, go back to the vfio_platform_irq struct via container_of. From there you can retrieve pointers to the vfio_platform_device and the vfio_device. - new fields on consumer side: the kvm handle, the gsi You do not need to add these. Instead, add the kvm handle to irqfd only. Like above, embed the irq_bypass_consumer struct in the irqfd struct; in the new kvm_arch_* functions, go back to the vfio_platform_irq struct via container_of. I also need the gsi field here, for posted-interrupts, I need 'gsi', 'irq' to update the IRTE. Oh... we can get gsi from irq_bypass_consumer - _irqfd - gsi, so it is not needed in irq_bypass_consumer. Got it! :) The issue I have is that struct _irqfd is local to eventfd.c so it cannot be used in archi specific code. Is it acceptable to move it to kvm_host.h, naming it something like kvm_kernel_irqfd (as done for kvm_kernel_irq_routing_entry)? Would also need to move _irqfd_resampler there (kvm_kernel_irqfd_resampler). irqfd user struct cannot be used in a standalone manner since we miss the kvm handle. Thanks Eric Thanks, Feng Thanks, Feng Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi
Hi Pavel,
On 02/07/15 08:26, Pavel Fedin wrote:
Hello!
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf
Of Eric Auger
Sent: Monday, June 29, 2015 6:37 PM
To: eric.au...@st.com; eric.au...@linaro.org;
linux-arm-ker...@lists.infradead.org;
marc.zyng...@arm.com; christoffer.d...@linaro.org; andre.przyw...@arm.com;
kvm...@lists.cs.columbia.edu; kvm@vger.kernel.org
Cc: linux-ker...@vger.kernel.org; patc...@linaro.org; p.fe...@samsung.com;
pbonz...@redhat.com
Subject: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi
On ARM, the MSI msg (address and data) comes along with
out-of-band device ID information. The device ID encodes the device
that composes the MSI msg. Let's create a new routing entry type,
dubbed KVM_IRQ_ROUTING_EXTENDED_MSI and use the __u32 pad space
to convey the device ID.
Signed-off-by: Eric Auger eric.au...@linaro.org
---
RFC - PATCH
- remove kvm_irq_routing_extended_msi and use union instead
---
Documentation/virtual/kvm/api.txt | 9 -
include/uapi/linux/kvm.h | 6 +-
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index d20fd94..6426ae9 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1414,7 +1414,10 @@ struct kvm_irq_routing_entry {
__u32 gsi;
__u32 type;
__u32 flags;
-__u32 pad;
+union {
+__u32 pad;
+__u32 devid;
+};
union {
struct kvm_irq_routing_irqchip irqchip;
struct kvm_irq_routing_msi msi;
devid is actually a part of MSI bunch. Shouldn't it be a part of struct
kvm_irq_routing_msi then?
It also has reserved pad.
@@ -1427,6 +1430,10 @@ struct kvm_irq_routing_entry {
#define KVM_IRQ_ROUTING_IRQCHIP 1
#define KVM_IRQ_ROUTING_MSI 2
#define KVM_IRQ_ROUTING_S390_ADAPTER 3
+#define KVM_IRQ_ROUTING_EXTENDED_MSI 4
+
+In case of KVM_IRQ_ROUTING_EXTENDED_MSI routing type, devid is used to
convey
+the device ID.
No flags are specified so far, the corresponding field must be set to zero.
What if we use KVM_MSI_VALID_DEVID flag instead of new
KVM_IRQ_ROUTING_EXTENDED_MSI definition? I
believe this would make an API more consistent and introduce less new
definitions.
I like this approach, but it runs into problems:
As you read above the current documentation says that the flags field
must be zero and the current KVM_SET_GSI_ROUTING handler bails out if it
isn't. So userland would need to know whether it's safe to set that
field. Introducing a new KVM_CAP_... value seems overkill if we could
just have a new routing entry type. So we could still reuse the existing
struct kvm_irq_routing_msi (and extend that with the devid field), but
we would have to add a new routing type number.
Maybe we could collapse this into the existing MSI type + flag when
handing it further down the kernel?
Cheers,
Andre.
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 2a23705..8484681 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -841,12 +841,16 @@ struct kvm_irq_routing_s390_adapter {
#define KVM_IRQ_ROUTING_IRQCHIP 1
#define KVM_IRQ_ROUTING_MSI 2
#define KVM_IRQ_ROUTING_S390_ADAPTER 3
+#define KVM_IRQ_ROUTING_EXTENDED_MSI 4
struct kvm_irq_routing_entry {
__u32 gsi;
__u32 type;
__u32 flags;
-__u32 pad;
+union {
+__u32 pad;
+__u32 devid;
+};
union {
struct kvm_irq_routing_irqchip irqchip;
struct kvm_irq_routing_msi msi;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64/kvm: Add generic v8 KVM target
On 3 July 2015 at 09:28, Marc Zyngier marc.zyng...@arm.com wrote: On 03/07/15 09:12, Peter Maydell wrote: I would still like to see the proponents of this patch say what their model is for userspace support of cross-host migration, if we're abandoning the model the current API envisages. I thought we had discussed this above, and don't really see this as a departure from the current model: - -cpu host results in GENERIC being used: VM can only be migrated to the exact same HW (no cross-host migration). MIDR should probably become RO. - -cpu host results in A57 (for example): VM can be migrated to a variety of A57 platforms, and allow for some fuzzing on the revision (or accept any revision). - -cpu a57 forces an A57 model to be emulated, always. It is always possible to migrate such a VM on any host. I think only the first point is new, but the last two are what we have (or what we should have). Right, but the implicit idea of this GENERIC patch seems to be that new host CPU types don't get their own KVM_ARM_TARGET_* constant, and are thus forever unable to do cross-host migration. It's not clear to me why we'd want to have new CPUs be second class citizens like that. -- PMM -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64/kvm: Add generic v8 KVM target
On 03/07/15 10:34, Peter Maydell wrote: On 3 July 2015 at 09:28, Marc Zyngier marc.zyng...@arm.com wrote: On 03/07/15 09:12, Peter Maydell wrote: I would still like to see the proponents of this patch say what their model is for userspace support of cross-host migration, if we're abandoning the model the current API envisages. I thought we had discussed this above, and don't really see this as a departure from the current model: - -cpu host results in GENERIC being used: VM can only be migrated to the exact same HW (no cross-host migration). MIDR should probably become RO. - -cpu host results in A57 (for example): VM can be migrated to a variety of A57 platforms, and allow for some fuzzing on the revision (or accept any revision). - -cpu a57 forces an A57 model to be emulated, always. It is always possible to migrate such a VM on any host. I think only the first point is new, but the last two are what we have (or what we should have). Right, but the implicit idea of this GENERIC patch seems to be that new host CPU types don't get their own KVM_ARM_TARGET_* constant, and are thus forever unable to do cross-host migration. It's not clear to me why we'd want to have new CPUs be second class citizens like that. I certainly don't want to see *any* CPU be a second class citizen. But let's face it, we're adding more and more targets that don't implement anything new, and just satisfy themselves with the generic implementation. I see it as an incentive to provide something useful (tables of all the registers with default values?) so that cross-host migration becomes a reality instead of the figment of our imagination (as it is now). If it wasn't already ABI, I'd have removed the existing targets until we have something meaningful to put there. Now, I also have my own doubts about cross-host migration (timers anyone?). But I don't see the above as a change in policy. More as a way to outline the fact that we currently don't have the right level of information/infrastructure to support it at all. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[[PATCH 2/2] kvm: enable preemption to register/unregister preempt notifier
After commit 1cde2930e154 (sched/preempt: Add static_key() to
preempt_notifiers) is introduced, preempt_notifier_{register, unregister}
always hold a mutex, jump_label_mutex. So in current case this shouldn't
work further under the circumstance of disabled preemption, and its also
safe since we're just handling a per-vcpu stuff with holding vcpu-mutex.
Otherwise, some warning messages are posted like this,
BUG: scheduling while atomic: qemu-system-x86/17177/0x0002
2 locks held by qemu-system-x86/17177:
#0: (vcpu-mutex){+.+.+.}, at: [a035fb48] vcpu_load+0x28/0xf0 [kvm]
#1: (jump_label_mutex){+.+.+.}, at: [81244b54]
static_key_slow_inc+0xc4/0x140
Modules linked in: x86_pkg_temp_thermal kvm_intel kvm
Preemption disabled at:[a035fd3e] kvm_vcpu_ioctl+0x7e/0xeb0 [kvm]
CPU: 2 PID: 17177 Comm: qemu-system-x86 Tainted: GW 4.1.0+ #30
Hardware name: Dell Inc. OptiPlex 9020/0DNKMN, BIOS A05 12/05/2013
00200206 8801c584bc38 81f974ab 0003
880211289a80 8801c584bc58 81f8fd3e 0001
8802161d5d00 8801c584bcb8 81fa43dc 8801c584bd68
Call Trace:
[81f974ab] dump_stack+0x95/0xf2
[81f8fd3e] __schedule_bug+0x108/0x126
[81fa43dc] __schedule+0x12dc/0x1590
[81fa4965] schedule+0x75/0x150
[81fa7683] ? mutex_lock_nested+0x393/0x780
[81fa4db0] schedule_preempt_disabled+0x30/0x60
[81fa753a] mutex_lock_nested+0x24a/0x780
[81244b54] ? static_key_slow_inc+0xc4/0x140
[81244b54] ? static_key_slow_inc+0xc4/0x140
[a035fb48] ? vcpu_load+0x28/0xf0 [kvm]
[81244b54] static_key_slow_inc+0xc4/0x140
[810d36a5] preempt_notifier_register+0x25/0x70
[a035fb96] vcpu_load+0x76/0xf0 [kvm]
[a035fd3e] kvm_vcpu_ioctl+0x7e/0xeb0 [kvm]
[8110bc40] ? __lock_is_held+0x70/0xa0
[810dde79] ? get_parent_ip+0x19/0x90
[8130e4b4] do_vfs_ioctl+0x3c4/0x910
[81320a01] ? expand_files+0x311/0x360
[815370af] ? selinux_file_ioctl+0x6f/0x150
[8130eaad] SyS_ioctl+0xad/0xe0
[81faf857] entry_SYSCALL_64_fastpath+0x12/0x6f
CC: Gleb Natapov g...@kernel.org
CC: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
---
virt/kvm/kvm_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 848af90..bde5f66f 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -127,8 +127,8 @@ int vcpu_load(struct kvm_vcpu *vcpu)
if (mutex_lock_killable(vcpu-mutex))
return -EINTR;
- cpu = get_cpu();
preempt_notifier_register(vcpu-preempt_notifier);
+ cpu = get_cpu();
kvm_arch_vcpu_load(vcpu, cpu);
put_cpu();
return 0;
@@ -138,8 +138,8 @@ void vcpu_put(struct kvm_vcpu *vcpu)
{
preempt_disable();
kvm_arch_vcpu_put(vcpu);
- preempt_notifier_unregister(vcpu-preempt_notifier);
preempt_enable();
+ preempt_notifier_unregister(vcpu-preempt_notifier);
mutex_unlock(vcpu-mutex);
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[[PATCH 1/2] kvm: make preempt_notifier free out CONFIG_PREEMPT_NOTIFIERS
In any cases CONFIG_KVM always means CONFIG_PREEMPT_NOTIFIERS
is enabled unconditionally so its really pointless.
CC: Gleb Natapov g...@kernel.org
CC: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
---
include/linux/kvm_host.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 9564fd7..695f4f3 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -220,9 +220,7 @@ struct kvm_mmio_fragment {
struct kvm_vcpu {
struct kvm *kvm;
-#ifdef CONFIG_PREEMPT_NOTIFIERS
struct preempt_notifier preempt_notifier;
-#endif
int cpu;
int vcpu_id;
int srcu_idx;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 09/11] KVM: arm64: guest debug, HW assisted debug support
Hi Alex,
On Thu, Jul 02, 2015 at 02:50:33PM +0100, Alex Bennée wrote:
Are you happy with this?:
[...]
+/**
+ * kvm_arch_dev_ioctl_check_extension
+ *
+ * We currently assume that the number of HW registers is uniform
+ * across all CPUs (see cpuinfo_sanity_check).
+ */
int kvm_arch_dev_ioctl_check_extension(long ext)
{
int r;
@@ -64,6 +71,12 @@ int kvm_arch_dev_ioctl_check_extension(long ext)
case KVM_CAP_ARM_EL1_32BIT:
r = cpu_has_32bit_el1();
break;
+ case KVM_CAP_GUEST_DEBUG_HW_BPS:
+ r = hw_breakpoint_slots(TYPE_INST);
+ break;
+ case KVM_CAP_GUEST_DEBUG_HW_WPS:
+ r = hw_breakpoint_slots(TYPE_DATA);
+ break;
Whilst I much prefer this code, it actually adds an unwanted dependency
on PERF_EVENTS that I didn't think about to start with. Sorry to keep
messing you about -- I guess your original patch is the best thing after
all.
Will
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/10] KVM: arm/arm64: vgic: Relax vgic_can_sample_irq for edge IRQs
On 02/07/15 17:23, Christoffer Dall wrote: On Wed, Jul 01, 2015 at 07:18:40PM +0100, Marc Zyngier wrote: On 01/07/15 12:58, Christoffer Dall wrote: On Wed, Jul 01, 2015 at 10:17:52AM +0100, Marc Zyngier wrote: On 30/06/15 21:19, Christoffer Dall wrote: On Mon, Jun 08, 2015 at 06:04:00PM +0100, Marc Zyngier wrote: We only set the irq_queued flag for level interrupts, meaning that !vgic_irq_is_queued(vcpu, irq) is a good enough predicate for all interrupts. This will allow us to inject edge HW interrupts, for which the state ACTIVE+PENDING is not allowed. I don't understand this; ACTIVE+PENDING is allowed for edge interrupts. Do you mean that if we set the HW bit in the LR, then we are linking to an HW interrupt where we don't allow that to be ACTIVE+PENDING on the HW GIC side? Why is this relevant here? I feel like I'm missing context. I've probably taken a shortcut here - bear with me while I'm trying to explain the issue. For HW interrupts, we shouldn't even try to use the state bits in the LR, because that state is contained in the physical distributor. Setting the HW bit really means there is something going on at the distributor level, just go there. ok, so by HW interrupts you mean virtual interrupts with the HW bit in the LR set, correct? Yes, sorry. If we were to inject a ACTIVE+PENDING interrupt at the LR level, we'd basically loose the second interrupt because that state is simply not considered. Huh? Which second interrupt. I looked at the spec and it says don't use the state bits for HW interrupts, so isn't it simply not supported to set these bits at all and that's it? I managed to confuse myself reading the same bit. It says (GICv3 spec): A hypervisor must only use the pending and active state for software originated interrupts, which are typically associated with virtual devices, or SGIs. That's the PENDING+ACTIVE state, and not the pending and active bits like I read it initially. Now consider the following scenario: - We inject a virtual edge interrupt - We mark the corresponding physical interrupt as active. - Queue interrupt in an LR - Resume vcpu Now, we inject another edge interrupt, the vcpu exits for whatever reason, and the previously injected interrupt is still active. The normal vGIC flow would be to mark the interrupt as ACTIVE+PENDING in the LR, and resume the vcpu. But the above states that this is invalid for HW generated interrupts. Right, ok, so we must resample the pending state even for an edge-triggered interrupt once it's EOIed, because we cannot put it in the LR despite it being pending on the physical distributor? Incidentally, we do not need to set the EOI_INT bit, becuase when the guest EOIs the interrupt, it will also deactivate it on the physical distributor and the hardware will then take the pending physical interrupt, we will handle it in the host, etc. etc. If we had a different *shared* device than the timer which is edge-triggered, don't we then also need to capture the physical distributor's pending state along with the state of the device unless we assume that upon restoring the state for the device count on the device to have another rising/falling edge to trigger the interrupt again? (I assume the line would always go high for a level-triggered interrupt in this case). I'd definitely assume that restoring the state of the device would make it generate an interrupt. This has to be a property of the device, otherwise it is not really shareable between vcpus. Time will tell - we still have to see one of these. So the trick we're using is to only inject the active interrupt, and prevent anything else from being injected until we can confirm that the active state has been cleared at the physical level. Does it make any sense? Sort of, but what I don't understand now is how the guest ever sees the interrupt then. If we always inject the virtual interrupt by setting the active state on the physical distributor, and we can't inject this as active+pending, and the guest doesn't see the state in the LR, then how does this ever raise a virtual interrupt and how does the guest see an interrupt which is only PENDING so that it can ack it etc. etc.? Maybe I don't fully understand how the HW bit works after all... The way the spec is written is slightly misleading. But the gist of it is that we still signal the guest using the PENDING bit in the LR, and switch the LR as usual. it is just that we can't use the PENDING+ACTIVE state (apparently, this can lead to a double deactivation). Not sure the above makes sense. Beer time, I suppose. It does make sense, I just had to sleep on it and see the code as a whole instead of trying to understand it by just looking at this patch individually. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to
Re: [PATCH v3 08/11] KVM: arm: implement dirty bit mechanism for debug registers
On June 30, 2015 5:20:20 PM GMT+08:00, Christoffer Dall
christoffer.d...@linaro.org wrote:
On Mon, Jun 22, 2015 at 06:41:31PM +0800, Zhichao Huang wrote:
The trapping code keeps track of the state of the debug registers,
allowing for the switch code to implement a lazy switching strategy.
Signed-off-by: Zhichao Huang zhichao.hu...@linaro.org
---
arch/arm/include/asm/kvm_asm.h | 3 +++
arch/arm/include/asm/kvm_host.h | 3 +++
arch/arm/kernel/asm-offsets.c | 1 +
arch/arm/kvm/coproc.c | 39 --
arch/arm/kvm/interrupts_head.S | 42
+
5 files changed, 86 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/kvm_asm.h b/arch/arm/include/asm/kvm_asm.h
index ba65e05..4fb64cf 100644
--- a/arch/arm/include/asm/kvm_asm.h
+++ b/arch/arm/include/asm/kvm_asm.h
@@ -64,6 +64,9 @@
#define cp14_DBGDSCRext 65 /* Debug Status and Control external */
#define NR_CP14_REGS66 /* Number of regs (incl. invalid) */
+#define KVM_ARM_DEBUG_DIRTY_SHIFT 0
+#define KVM_ARM_DEBUG_DIRTY (1 KVM_ARM_DEBUG_DIRTY_SHIFT)
+
#define ARM_EXCEPTION_RESET 0
#define ARM_EXCEPTION_UNDEFINED 1
#define ARM_EXCEPTION_SOFTWARE2
diff --git a/arch/arm/include/asm/kvm_host.h
b/arch/arm/include/asm/kvm_host.h
index 3d16820..09b54bf 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -127,6 +127,9 @@ struct kvm_vcpu_arch {
/* System control coprocessor (cp14) */
u32 cp14[NR_CP14_REGS];
+/* Debug state */
+u32 debug_flags;
+
/*
* Anything that is not used directly from assembly code goes
* here.
diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
index 9158de0..e876109 100644
--- a/arch/arm/kernel/asm-offsets.c
+++ b/arch/arm/kernel/asm-offsets.c
@@ -185,6 +185,7 @@ int main(void)
DEFINE(VCPU_FIQ_REGS, offsetof(struct kvm_vcpu,
arch.regs.fiq_regs));
DEFINE(VCPU_PC, offsetof(struct kvm_vcpu,
arch.regs.usr_regs.ARM_pc));
DEFINE(VCPU_CPSR, offsetof(struct kvm_vcpu,
arch.regs.usr_regs.ARM_cpsr));
+ DEFINE(VCPU_DEBUG_FLAGS, offsetof(struct kvm_vcpu,
arch.debug_flags));
DEFINE(VCPU_HCR, offsetof(struct kvm_vcpu, arch.hcr));
DEFINE(VCPU_IRQ_LINES,offsetof(struct kvm_vcpu, arch.irq_lines));
DEFINE(VCPU_HSR, offsetof(struct kvm_vcpu, arch.fault.hsr));
diff --git a/arch/arm/kvm/coproc.c b/arch/arm/kvm/coproc.c
index 648..fc0c2ef 100644
--- a/arch/arm/kvm/coproc.c
+++ b/arch/arm/kvm/coproc.c
@@ -220,14 +220,49 @@ bool access_vm_reg(struct kvm_vcpu *vcpu,
return true;
}
+/*
+ * We want to avoid world-switching all the DBG registers all the
+ * time:
+ *
+ * - If we've touched any debug register, it is likely that we're
+ * going to touch more of them. It then makes sense to disable the
+ * traps and start doing the save/restore dance
+ * - If debug is active (ARM_DSCR_MDBGEN set), it is then mandatory
+ * to save/restore the registers, as the guest depends on them.
+ *
+ * For this, we use a DIRTY bit, indicating the guest has modified
the
+ * debug registers, used as follow:
+ *
+ * On guest entry:
+ * - If the dirty bit is set (because we're coming back from
trapping),
+ * disable the traps, save host registers, restore guest
registers.
+ * - If debug is actively in use (ARM_DSCR_MDBGEN set),
+ * set the dirty bit, disable the traps, save host registers,
+ * restore guest registers.
+ * - Otherwise, enable the traps
+ *
+ * On guest exit:
+ * - If the dirty bit is set, save guest registers, restore host
+ * registers and clear the dirty bit. This ensure that the host can
+ * now use the debug registers.
+ *
+ * Notice:
+ * - For ARMv7, if the CONFIG_HAVE_HW_BREAKPOINT is set in the guest,
+ * debug is always actively in use (ARM_DSCR_MDBGEN set).
+ * We have to do the save/restore dance in this case, because the
+ * host and the guest might use their respective debug registers
+ * at any moment.
so doesn't this pretty much invalidate the whole saving/dirty effort?
Guests configured from for example multi_v7_defconfig will then act
like
this and you will save/restore all these registers always.
Wouldn't a better approach be to enable trapping to hyp mode most of
the
time, and simply clear the enabled bit of any host-used break- or
wathcpoints upon guest entry, perhaps maintaining a bitmap of which
ones
must be re-set when exiting the guest, and thereby drastically reducing
the amount of save/restore code you'd have to perform.
Of course, you'd also have to keep track of whether the guest has any
breakpoints or watchpoints enabled for when you do the full
save/restore
dance.
That would also avoid all issues surrounding accesses to DBGDSCRext
register I think.
I have thought about it, which means to say, Since we can't
Re: [PATCH 05/10] KVM: arm/arm64: vgic: Relax vgic_can_sample_irq for edge IRQs
On 3 July 2015 at 10:50, Marc Zyngier marc.zyng...@arm.com wrote: On 02/07/15 17:23, Christoffer Dall wrote: If we had a different *shared* device than the timer which is edge-triggered, don't we then also need to capture the physical distributor's pending state along with the state of the device unless we assume that upon restoring the state for the device count on the device to have another rising/falling edge to trigger the interrupt again? (I assume the line would always go high for a level-triggered interrupt in this case). I'd definitely assume that restoring the state of the device would make it generate an interrupt. This has to be a property of the device, otherwise it is not really shareable between vcpus. FWIW, QEMU's modelling approach to this is to say that devices do *not* generate interrupts on restore. If the device had previously generated an interrupt then this should be captured by the state of the interrupt controller (or whatever else it is connected to) and dealt with when the GIC state is restored. If you say that restoring the device state is supposed to generate an interrupt, you introduce an ordering requirement that the state of the interrupt controller is restored first and the device second (otherwise the incoming GIC state will overwrite the interrupt that the device just generated), which isn't ideal (especially since QEMU makes no guarantees about restore order between devices). thanks -- PMM -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 02/10] AArch{32,64}: use KVM_CREATE_DEVICE co to instanciate the GIC
From: Marc Zyngier marc.zyng...@arm.com
As of 3.14, KVM/arm supports the creation/configuration of the GIC through
a more generic device API, which is now the preferred way to do so.
Plumb the new API in, and allow the old code to be used as a fallback.
[Andre: Rename some functions on the way to differentiate between
creation and initialisation more clearly and fix error path.]
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
Signed-off-by: Andre Przywara andre.przyw...@arm.com
---
arm/gic.c| 69 +++-
arm/include/arm-common/gic.h | 2 +-
arm/kvm.c| 6 ++--
3 files changed, 66 insertions(+), 11 deletions(-)
diff --git a/arm/gic.c b/arm/gic.c
index 5d8cbe6..1ff3663 100644
--- a/arm/gic.c
+++ b/arm/gic.c
@@ -7,7 +7,50 @@
#include linux/byteorder.h
#include linux/kvm.h
-int gic__init_irqchip(struct kvm *kvm)
+static int gic_fd = -1;
+
+static int gic__create_device(struct kvm *kvm)
+{
+ int err;
+ u64 cpu_if_addr = ARM_GIC_CPUI_BASE;
+ u64 dist_addr = ARM_GIC_DIST_BASE;
+ struct kvm_create_device gic_device = {
+ .type = KVM_DEV_TYPE_ARM_VGIC_V2,
+ };
+ struct kvm_device_attr cpu_if_attr = {
+ .group = KVM_DEV_ARM_VGIC_GRP_ADDR,
+ .attr = KVM_VGIC_V2_ADDR_TYPE_CPU,
+ .addr = (u64)(unsigned long)cpu_if_addr,
+ };
+ struct kvm_device_attr dist_attr = {
+ .group = KVM_DEV_ARM_VGIC_GRP_ADDR,
+ .attr = KVM_VGIC_V2_ADDR_TYPE_DIST,
+ .addr = (u64)(unsigned long)dist_addr,
+ };
+
+ err = ioctl(kvm-vm_fd, KVM_CREATE_DEVICE, gic_device);
+ if (err)
+ return err;
+
+ gic_fd = gic_device.fd;
+
+ err = ioctl(gic_fd, KVM_SET_DEVICE_ATTR, cpu_if_attr);
+ if (err)
+ goto out_err;
+
+ err = ioctl(gic_fd, KVM_SET_DEVICE_ATTR, dist_attr);
+ if (err)
+ goto out_err;
+
+ return 0;
+
+out_err:
+ close(gic_fd);
+ gic_fd = -1;
+ return err;
+}
+
+static int gic__create_irqchip(struct kvm *kvm)
{
int err;
struct kvm_arm_device_addr gic_addr[] = {
@@ -23,12 +66,6 @@ int gic__init_irqchip(struct kvm *kvm)
}
};
- if (kvm-nrcpus GIC_MAX_CPUS) {
- pr_warning(%d CPUS greater than maximum of %d -- truncating\n,
- kvm-nrcpus, GIC_MAX_CPUS);
- kvm-nrcpus = GIC_MAX_CPUS;
- }
-
err = ioctl(kvm-vm_fd, KVM_CREATE_IRQCHIP);
if (err)
return err;
@@ -41,6 +78,24 @@ int gic__init_irqchip(struct kvm *kvm)
return err;
}
+int gic__create(struct kvm *kvm)
+{
+ int err;
+
+ if (kvm-nrcpus GIC_MAX_CPUS) {
+ pr_warning(%d CPUS greater than maximum of %d -- truncating\n,
+ kvm-nrcpus, GIC_MAX_CPUS);
+ kvm-nrcpus = GIC_MAX_CPUS;
+ }
+
+ /* Try the new way first, and fallback on legacy method otherwise */
+ err = gic__create_device(kvm);
+ if (err)
+ err = gic__create_irqchip(kvm);
+
+ return err;
+}
+
void gic__generate_fdt_nodes(void *fdt, u32 phandle)
{
u64 reg_prop[] = {
diff --git a/arm/include/arm-common/gic.h b/arm/include/arm-common/gic.h
index 5a36f2c..44859f7 100644
--- a/arm/include/arm-common/gic.h
+++ b/arm/include/arm-common/gic.h
@@ -24,7 +24,7 @@
struct kvm;
int gic__alloc_irqnum(void);
-int gic__init_irqchip(struct kvm *kvm);
+int gic__create(struct kvm *kvm);
void gic__generate_fdt_nodes(void *fdt, u32 phandle);
#endif /* ARM_COMMON__GIC_H */
diff --git a/arm/kvm.c b/arm/kvm.c
index 58ad9fa..bcd2533 100644
--- a/arm/kvm.c
+++ b/arm/kvm.c
@@ -81,7 +81,7 @@ void kvm__arch_init(struct kvm *kvm, const char
*hugetlbfs_path, u64 ram_size)
madvise(kvm-arch.ram_alloc_start, kvm-arch.ram_alloc_size,
MADV_MERGEABLE | MADV_HUGEPAGE);
- /* Initialise the virtual GIC. */
- if (gic__init_irqchip(kvm))
- die(Failed to initialise virtual GIC);
+ /* Create the virtual GIC. */
+ if (gic__create(kvm))
+ die(Failed to create virtual GIC);
}
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 03/10] irq: add irq__get_nr_allocated_lines
From: Marc Zyngier marc.zyng...@arm.com
The ARM GIC emulation needs to be told the number of interrupts
it has to support. As commit 1c262fa1dc7bc (kvm tools: irq: make
irq__alloc_line generic) made the interrupt counter private,
add a new accessor returning the number of interrupt lines we've
allocated so far.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
Signed-off-by: Andre Przywara andre.przyw...@arm.com
---
include/kvm/irq.h | 1 +
irq.c | 5 +
2 files changed, 6 insertions(+)
diff --git a/include/kvm/irq.h b/include/kvm/irq.h
index 4cec6f0..8a78e43 100644
--- a/include/kvm/irq.h
+++ b/include/kvm/irq.h
@@ -11,6 +11,7 @@
struct kvm;
int irq__alloc_line(void);
+int irq__get_nr_allocated_lines(void);
int irq__init(struct kvm *kvm);
int irq__exit(struct kvm *kvm);
diff --git a/irq.c b/irq.c
index 33ea8d2..71eaa05 100644
--- a/irq.c
+++ b/irq.c
@@ -7,3 +7,8 @@ int irq__alloc_line(void)
{
return next_line++;
}
+
+int irq__get_nr_allocated_lines(void)
+{
+ return next_line - KVM_IRQ_OFFSET;
+}
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 00/10] kvmtool: arm64: GICv3 guest support
Hi,
only very minor changes (patch 7 and 10) compared to v4:
Any failure in instantiating a VCPU now makes kvmtool abort, so
requesting more VCPUs than the selected kernel's VGIC emulation
can handle will let the user know immediately ;-)
Also I removed the unneeded initialization of the irqchip type
to GICv2.
Will, can you apply this series?
Cheers,
Andre.
-
Since Linux 3.19 the kernel can emulate a GICv3 for KVM guests.
This allows more than 8 VCPUs in a guest and enables in-kernel irqchip
for non-backwards-compatible GICv3 implementations.
This series updates kvmtool to support this feature.
The first half of the series is mostly from Marc and supports some
newer features of the virtual GIC which we later depend on. The second
part enables support for a guest GICv3 by adding a new command line
parameter (--irqchip=).
We now use the KVM_CREATE_DEVICE interface to create a virtual GIC
and only fall back to the now legacy KVM_CREATE_IRQCHIP call if the
former is not supported by the kernel.
Also we use two new features the KVM_CREATE_DEVICE interface
introduces:
* We now set the number of actually used interrupts to avoid
allocating too many of them without ever using them.
* We tell the kernel explicitly that we are finished with the GIC
initialisation. This is a requirement for future VGIC versions.
The final three patches introduce virtual GICv3 support, so on
supported hardware (and given kernel support) the user can ask KVM to
emulate a GICv3, lifting the 8 VCPU limit of KVM. This is done by
specifying --irqchip=gicv3 on the command line.
For the time being the kernel only supports a virtual GICv3 on ARM64,
but as the GIC is shared in kvmtool, I had to add the macro
definitions to not break the build on ARM.
This series goes on top of the new official stand-alone repo hosted
on Will's kernel.org git [1].
Find a branch with those patches included at my repo [2].
[1] git://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git
[2] git://linux-arm.org/kvmtool.git (branch gicv3/v5)
http://www.linux-arm.org/git?p=kvmtool.git;a=log;h=refs/heads/gicv3/v5
Andre Przywara (6):
arm: finish VGIC initialisation explicitly
arm: simplify MMIO dispatching
limit number of VCPUs on demand
arm: prepare for instantiating different IRQ chip devices
arm: add support for supplying GICv3 redistributor addresses
arm: use new irqchip parameter to create different vGIC types
Marc Zyngier (4):
AArch64: Reserve two 64k pages for GIC CPU interface
AArch{32,64}: use KVM_CREATE_DEVICE co to instanciate the GIC
irq: add irq__get_nr_allocated_lines
AArch{32,64}: dynamically configure the number of GIC interrupts
arm/aarch32/arm-cpu.c| 2 +-
arm/aarch64/arm-cpu.c| 2 +-
arm/aarch64/include/kvm/kvm-arch.h | 2 +-
arm/gic.c| 189 +--
arm/include/arm-common/gic.h | 9 +-
arm/include/arm-common/kvm-arch.h| 19 ++--
arm/include/arm-common/kvm-config-arch.h | 9 +-
arm/include/arm-common/kvm-cpu-arch.h| 14 ++-
arm/kvm-cpu.c| 16 ---
arm/kvm.c| 6 +-
include/kvm/irq.h| 1 +
irq.c| 5 +
12 files changed, 225 insertions(+), 49 deletions(-)
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 01/10] AArch64: Reserve two 64k pages for GIC CPU interface
From: Marc Zyngier marc.zyng...@arm.com On AArch64 system with a GICv2, the GICC range can be aligned to the last 4k block of a 64k page, ending up straddling two 64k pages. In order not to conflict with the distributor mapping, allocate two 64k pages to the CPU interface. Signed-off-by: Marc Zyngier marc.zyng...@arm.com Signed-off-by: Andre Przywara andre.przyw...@arm.com --- arm/aarch64/include/kvm/kvm-arch.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arm/aarch64/include/kvm/kvm-arch.h b/arm/aarch64/include/kvm/kvm-arch.h index 2f08a26..4925736 100644 --- a/arm/aarch64/include/kvm/kvm-arch.h +++ b/arm/aarch64/include/kvm/kvm-arch.h @@ -2,7 +2,7 @@ #define KVM__KVM_ARCH_H #define ARM_GIC_DIST_SIZE 0x1 -#define ARM_GIC_CPUI_SIZE 0x1 +#define ARM_GIC_CPUI_SIZE 0x2 #define ARM_KERN_OFFSET(kvm) ((kvm)-cfg.arch.aarch32_guest ? \ 0x8000 : \ -- 2.3.5 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 09/10] arm: add support for supplying GICv3 redistributor addresses
Instead of the GIC virtual CPU interface an emulated GICv3 needs to
have accesses to its emulated redistributors trapped in the guest.
Add code to tell the kernel about the mapping if a GICv3 emulation was
requested by the user.
This contains some defines which are not (yet) in the (32 bit) header
files to allow compilation for ARM.
Signed-off-by: Andre Przywara andre.przyw...@arm.com
Reviewed-by: Marc Zyngier marc.zyng...@arm.com
---
arm/gic.c | 36 +++-
arm/include/arm-common/gic.h | 1 +
arm/include/arm-common/kvm-arch.h | 7 +++
3 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/arm/gic.c b/arm/gic.c
index b6c5868..efe4b42 100644
--- a/arm/gic.c
+++ b/arm/gic.c
@@ -9,7 +9,18 @@
#include linux/kernel.h
#include linux/kvm.h
+/* Those names are not defined for ARM (yet) */
+#ifndef KVM_VGIC_V3_ADDR_TYPE_DIST
+#define KVM_VGIC_V3_ADDR_TYPE_DIST 2
+#endif
+
+#ifndef KVM_VGIC_V3_ADDR_TYPE_REDIST
+#define KVM_VGIC_V3_ADDR_TYPE_REDIST 3
+#endif
+
static int gic_fd = -1;
+static u64 gic_redists_base;
+static u64 gic_redists_size;
static int gic__create_device(struct kvm *kvm, enum irqchip_type type)
{
@@ -28,12 +39,21 @@ static int gic__create_device(struct kvm *kvm, enum
irqchip_type type)
.group = KVM_DEV_ARM_VGIC_GRP_ADDR,
.addr = (u64)(unsigned long)dist_addr,
};
+ struct kvm_device_attr redist_attr = {
+ .group = KVM_DEV_ARM_VGIC_GRP_ADDR,
+ .attr = KVM_VGIC_V3_ADDR_TYPE_REDIST,
+ .addr = (u64)(unsigned long)gic_redists_base,
+ };
switch (type) {
case IRQCHIP_GICV2:
gic_device.type = KVM_DEV_TYPE_ARM_VGIC_V2;
dist_attr.attr = KVM_VGIC_V2_ADDR_TYPE_DIST;
break;
+ case IRQCHIP_GICV3:
+ gic_device.type = KVM_DEV_TYPE_ARM_VGIC_V3;
+ dist_attr.attr = KVM_VGIC_V3_ADDR_TYPE_DIST;
+ break;
}
err = ioctl(kvm-vm_fd, KVM_CREATE_DEVICE, gic_device);
@@ -46,6 +66,9 @@ static int gic__create_device(struct kvm *kvm, enum
irqchip_type type)
case IRQCHIP_GICV2:
err = ioctl(gic_fd, KVM_SET_DEVICE_ATTR, cpu_if_attr);
break;
+ case IRQCHIP_GICV3:
+ err = ioctl(gic_fd, KVM_SET_DEVICE_ATTR, redist_attr);
+ break;
}
if (err)
goto out_err;
@@ -97,6 +120,10 @@ int gic__create(struct kvm *kvm, enum irqchip_type type)
switch (type) {
case IRQCHIP_GICV2:
break;
+ case IRQCHIP_GICV3:
+ gic_redists_size = kvm-cfg.nrcpus * ARM_GIC_REDIST_SIZE;
+ gic_redists_base = ARM_GIC_DIST_BASE - gic_redists_size;
+ break;
default:
return -ENODEV;
}
@@ -156,12 +183,19 @@ void gic__generate_fdt_nodes(void *fdt, u32 phandle, enum
irqchip_type type)
const char *compatible;
u64 reg_prop[] = {
cpu_to_fdt64(ARM_GIC_DIST_BASE),
cpu_to_fdt64(ARM_GIC_DIST_SIZE),
- cpu_to_fdt64(ARM_GIC_CPUI_BASE),
cpu_to_fdt64(ARM_GIC_CPUI_SIZE),
+ 0, 0, /* to be filled */
};
switch (type) {
case IRQCHIP_GICV2:
compatible = arm,cortex-a15-gic;
+ reg_prop[2] = cpu_to_fdt64(ARM_GIC_CPUI_BASE);
+ reg_prop[3] = cpu_to_fdt64(ARM_GIC_CPUI_SIZE);
+ break;
+ case IRQCHIP_GICV3:
+ compatible = arm,gic-v3;
+ reg_prop[2] = cpu_to_fdt64(gic_redists_base);
+ reg_prop[3] = cpu_to_fdt64(gic_redists_size);
break;
default:
return;
diff --git a/arm/include/arm-common/gic.h b/arm/include/arm-common/gic.h
index d524f55..4fde5ac 100644
--- a/arm/include/arm-common/gic.h
+++ b/arm/include/arm-common/gic.h
@@ -23,6 +23,7 @@
enum irqchip_type {
IRQCHIP_GICV2,
+ IRQCHIP_GICV3,
};
struct kvm;
diff --git a/arm/include/arm-common/kvm-arch.h
b/arm/include/arm-common/kvm-arch.h
index 90d6733..0f5fb7f 100644
--- a/arm/include/arm-common/kvm-arch.h
+++ b/arm/include/arm-common/kvm-arch.h
@@ -30,6 +30,13 @@
#define KVM_PCI_MMIO_AREA (KVM_PCI_CFG_AREA + ARM_PCI_CFG_SIZE)
#define KVM_VIRTIO_MMIO_AREA ARM_MMIO_AREA
+/*
+ * On a GICv3 there must be one redistributor per vCPU.
+ * The value here is the size for one, we multiply this at runtime with
+ * the number of requested vCPUs to get the actual size.
+ */
+#define ARM_GIC_REDIST_SIZE0x2
+
#define KVM_IRQ_OFFSET GIC_SPI_IRQ_BASE
#define KVM_VM_TYPE0
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 04/10] AArch{32,64}: dynamically configure the number of GIC interrupts
From: Marc Zyngier marc.zyng...@arm.com
In order to reduce the memory usage of large guests (as well
as improve performance), tell KVM about the number of interrupts
we require.
To avoid synchronization with the various device creation,
use a late_init callback to compute the GIC configuration.
[Andre: rename to gic__init_gic() to ease future expansion]
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
Signed-off-by: Andre Przywara andre.przyw...@arm.com
---
arm/gic.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/arm/gic.c b/arm/gic.c
index 1ff3663..8560c9b 100644
--- a/arm/gic.c
+++ b/arm/gic.c
@@ -1,10 +1,12 @@
#include kvm/fdt.h
+#include kvm/irq.h
#include kvm/kvm.h
#include kvm/virtio.h
#include arm-common/gic.h
#include linux/byteorder.h
+#include linux/kernel.h
#include linux/kvm.h
static int gic_fd = -1;
@@ -96,6 +98,29 @@ int gic__create(struct kvm *kvm)
return err;
}
+static int gic__init_gic(struct kvm *kvm)
+{
+ int lines = irq__get_nr_allocated_lines();
+ u32 nr_irqs = ALIGN(lines, 32) + GIC_SPI_IRQ_BASE;
+ struct kvm_device_attr nr_irqs_attr = {
+ .group = KVM_DEV_ARM_VGIC_GRP_NR_IRQS,
+ .addr = (u64)(unsigned long)nr_irqs,
+ };
+
+ /*
+* If we didn't use the KVM_CREATE_DEVICE method, KVM will
+* give us some default number of interrupts.
+*/
+ if (gic_fd 0)
+ return 0;
+
+ if (!ioctl(gic_fd, KVM_HAS_DEVICE_ATTR, nr_irqs_attr))
+ return ioctl(gic_fd, KVM_SET_DEVICE_ATTR, nr_irqs_attr);
+
+ return 0;
+}
+late_init(gic__init_gic)
+
void gic__generate_fdt_nodes(void *fdt, u32 phandle)
{
u64 reg_prop[] = {
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 06/10] arm: simplify MMIO dispatching
Currently we separate any incoming MMIO request into one of the ARM
memory map regions and take care to spare the GIC.
It turns out that this is unnecessary, as we only have one special
region (the IO port area in the first 64 KByte). The MMIO rbtree
takes care about unhandled MMIO ranges, so we can simply drop all the
special range checking (except that for the IO range) in
kvm_cpu__emulate_mmio().
As the GIC is handled in the kernel, a GIC MMIO access should never
reach userland (and we don't know what to do with it anyway).
This lets us delete some more code and simplifies future extensions
(like expanding the GIC regions).
To be in line with the other architectures, move the now simpler
code into a header file.
Signed-off-by: Andre Przywara andre.przyw...@arm.com
Reviewed-by: Marc Zyngier marc.zyng...@arm.com
---
arm/include/arm-common/kvm-arch.h | 12
arm/include/arm-common/kvm-cpu-arch.h | 14 --
arm/kvm-cpu.c | 16
3 files changed, 12 insertions(+), 30 deletions(-)
diff --git a/arm/include/arm-common/kvm-arch.h
b/arm/include/arm-common/kvm-arch.h
index 082131d..90d6733 100644
--- a/arm/include/arm-common/kvm-arch.h
+++ b/arm/include/arm-common/kvm-arch.h
@@ -45,18 +45,6 @@ static inline bool arm_addr_in_ioport_region(u64 phys_addr)
return phys_addr = KVM_IOPORT_AREA phys_addr limit;
}
-static inline bool arm_addr_in_virtio_mmio_region(u64 phys_addr)
-{
- u64 limit = KVM_VIRTIO_MMIO_AREA + ARM_VIRTIO_MMIO_SIZE;
- return phys_addr = KVM_VIRTIO_MMIO_AREA phys_addr limit;
-}
-
-static inline bool arm_addr_in_pci_region(u64 phys_addr)
-{
- u64 limit = KVM_PCI_CFG_AREA + ARM_PCI_CFG_SIZE + ARM_PCI_MMIO_SIZE;
- return phys_addr = KVM_PCI_CFG_AREA phys_addr limit;
-}
-
struct kvm_arch {
/*
* We may have to align the guest memory for virtio, so keep the
diff --git a/arm/include/arm-common/kvm-cpu-arch.h
b/arm/include/arm-common/kvm-cpu-arch.h
index 36c7872..329979a 100644
--- a/arm/include/arm-common/kvm-cpu-arch.h
+++ b/arm/include/arm-common/kvm-cpu-arch.h
@@ -44,8 +44,18 @@ static inline bool kvm_cpu__emulate_io(struct kvm_cpu *vcpu,
u16 port, void *dat
return false;
}
-bool kvm_cpu__emulate_mmio(struct kvm_cpu *vcpu, u64 phys_addr, u8 *data,
- u32 len, u8 is_write);
+static inline bool kvm_cpu__emulate_mmio(struct kvm_cpu *vcpu, u64 phys_addr,
+u8 *data, u32 len, u8 is_write)
+{
+ if (arm_addr_in_ioport_region(phys_addr)) {
+ int direction = is_write ? KVM_EXIT_IO_OUT : KVM_EXIT_IO_IN;
+ u16 port = (phys_addr - KVM_IOPORT_AREA) USHRT_MAX;
+
+ return kvm__emulate_io(vcpu, port, data, direction, len, 1);
+ }
+
+ return kvm__emulate_mmio(vcpu, phys_addr, data, len, is_write);
+}
unsigned long kvm_cpu__get_vcpu_mpidr(struct kvm_cpu *vcpu);
diff --git a/arm/kvm-cpu.c b/arm/kvm-cpu.c
index ab08815..7780251 100644
--- a/arm/kvm-cpu.c
+++ b/arm/kvm-cpu.c
@@ -139,22 +139,6 @@ bool kvm_cpu__handle_exit(struct kvm_cpu *vcpu)
return false;
}
-bool kvm_cpu__emulate_mmio(struct kvm_cpu *vcpu, u64 phys_addr, u8 *data,
- u32 len, u8 is_write)
-{
- if (arm_addr_in_virtio_mmio_region(phys_addr)) {
- return kvm__emulate_mmio(vcpu, phys_addr, data, len, is_write);
- } else if (arm_addr_in_ioport_region(phys_addr)) {
- int direction = is_write ? KVM_EXIT_IO_OUT : KVM_EXIT_IO_IN;
- u16 port = (phys_addr - KVM_IOPORT_AREA) USHRT_MAX;
- return kvm__emulate_io(vcpu, port, data, direction, len, 1);
- } else if (arm_addr_in_pci_region(phys_addr)) {
- return kvm__emulate_mmio(vcpu, phys_addr, data, len, is_write);
- }
-
- return false;
-}
-
void kvm_cpu__show_page_tables(struct kvm_cpu *vcpu)
{
}
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 10/10] arm: use new irqchip parameter to create different vGIC types
Currently we unconditionally create a virtual GICv2 in the guest.
Add a --irqchip= parameter to let the user specify a different GIC
type for the guest, when omitting this parameter it still defaults to
--irqchip=gicv2.
For now the only other supported type is --irqchip=gicv3
Signed-off-by: Andre Przywara andre.przyw...@arm.com
---
arm/aarch64/arm-cpu.c| 2 +-
arm/gic.c| 16
arm/include/arm-common/kvm-config-arch.h | 9 -
arm/kvm.c| 2 +-
4 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/arm/aarch64/arm-cpu.c b/arm/aarch64/arm-cpu.c
index f702b9e..3dc8ea3 100644
--- a/arm/aarch64/arm-cpu.c
+++ b/arm/aarch64/arm-cpu.c
@@ -12,7 +12,7 @@
static void generate_fdt_nodes(void *fdt, struct kvm *kvm, u32 gic_phandle)
{
int timer_interrupts[4] = {13, 14, 11, 10};
- gic__generate_fdt_nodes(fdt, gic_phandle, IRQCHIP_GICV2);
+ gic__generate_fdt_nodes(fdt, gic_phandle, kvm-cfg.arch.irqchip);
timer__generate_fdt_nodes(fdt, kvm, timer_interrupts);
}
diff --git a/arm/gic.c b/arm/gic.c
index efe4b42..1b63074 100644
--- a/arm/gic.c
+++ b/arm/gic.c
@@ -22,6 +22,22 @@ static int gic_fd = -1;
static u64 gic_redists_base;
static u64 gic_redists_size;
+int irqchip_parser(const struct option *opt, const char *arg, int unset)
+{
+ enum irqchip_type *type = opt-value;
+
+ if (!strcmp(arg, gicv2)) {
+ *type = IRQCHIP_GICV2;
+ } else if (!strcmp(arg, gicv3)) {
+ *type = IRQCHIP_GICV3;
+ } else {
+ fprintf(stderr, irqchip: unknown type \%s\\n, arg);
+ return -1;
+ }
+
+ return 0;
+}
+
static int gic__create_device(struct kvm *kvm, enum irqchip_type type)
{
int err;
diff --git a/arm/include/arm-common/kvm-config-arch.h
b/arm/include/arm-common/kvm-config-arch.h
index a8ebd94..9529881 100644
--- a/arm/include/arm-common/kvm-config-arch.h
+++ b/arm/include/arm-common/kvm-config-arch.h
@@ -8,8 +8,11 @@ struct kvm_config_arch {
unsigned intforce_cntfrq;
boolvirtio_trans_pci;
boolaarch32_guest;
+ enum irqchip_type irqchip;
};
+int irqchip_parser(const struct option *opt, const char *arg, int unset);
+
#define OPT_ARCH_RUN(pfx, cfg)
\
pfx,
\
ARM_OPT_ARCH_RUN(cfg)
\
@@ -21,6 +24,10 @@ struct kvm_config_arch {
updated to program CNTFRQ correctly*),
\
OPT_BOOLEAN('\0', force-pci, (cfg)-virtio_trans_pci,
\
Force virtio devices to use PCI as their default
\
- transport),
+ transport),
\
+OPT_CALLBACK('\0', irqchip, (cfg)-irqchip,
\
+[gicv2|gicv3], \
+type of interrupt controller to emulate in the guest,
\
+irqchip_parser, NULL),
#endif /* ARM_COMMON__KVM_CONFIG_ARCH_H */
diff --git a/arm/kvm.c b/arm/kvm.c
index f9685c2..d0e4a20 100644
--- a/arm/kvm.c
+++ b/arm/kvm.c
@@ -82,6 +82,6 @@ void kvm__arch_init(struct kvm *kvm, const char
*hugetlbfs_path, u64 ram_size)
MADV_MERGEABLE | MADV_HUGEPAGE);
/* Create the virtual GIC. */
- if (gic__create(kvm, IRQCHIP_GICV2))
+ if (gic__create(kvm, kvm-cfg.arch.irqchip))
die(Failed to create virtual GIC);
}
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 07/10] limit number of VCPUs on demand
Currently the ARM GIC checks the number of VCPUs against a fixed
limit, which is GICv2 specific. Don't pretend we know better than the
kernel and let's get rid of that explicit check.
We now fail if the number of requested VCPUs could not be
instantiated instead of limiting the number of VCPUs.
Signed-off-by: Andre Przywara andre.przyw...@arm.com
---
arm/gic.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/arm/gic.c b/arm/gic.c
index 99f0d2b..05f85a2 100644
--- a/arm/gic.c
+++ b/arm/gic.c
@@ -84,12 +84,6 @@ int gic__create(struct kvm *kvm)
{
int err;
- if (kvm-nrcpus GIC_MAX_CPUS) {
- pr_warning(%d CPUS greater than maximum of %d -- truncating\n,
- kvm-nrcpus, GIC_MAX_CPUS);
- kvm-nrcpus = GIC_MAX_CPUS;
- }
-
/* Try the new way first, and fallback on legacy method otherwise */
err = gic__create_device(kvm);
if (err)
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 08/10] arm: prepare for instantiating different IRQ chip devices
Extend the vGIC handling code to potentially deal with different IRQ
chip devices instead of hard-coding the GICv2 in.
We extend most vGIC functions to take a type parameter, but still put
GICv2 in at the top for the time being.
Signed-off-by: Andre Przywara andre.przyw...@arm.com
Reviewed-by: Marc Zyngier marc.zyng...@arm.com
---
arm/aarch32/arm-cpu.c| 2 +-
arm/aarch64/arm-cpu.c| 2 +-
arm/gic.c| 44 +++-
arm/include/arm-common/gic.h | 8 ++--
arm/kvm.c| 2 +-
5 files changed, 44 insertions(+), 14 deletions(-)
diff --git a/arm/aarch32/arm-cpu.c b/arm/aarch32/arm-cpu.c
index 946e443..d8d6293 100644
--- a/arm/aarch32/arm-cpu.c
+++ b/arm/aarch32/arm-cpu.c
@@ -12,7 +12,7 @@ static void generate_fdt_nodes(void *fdt, struct kvm *kvm,
u32 gic_phandle)
{
int timer_interrupts[4] = {13, 14, 11, 10};
- gic__generate_fdt_nodes(fdt, gic_phandle);
+ gic__generate_fdt_nodes(fdt, gic_phandle, IRQCHIP_GICV2);
timer__generate_fdt_nodes(fdt, kvm, timer_interrupts);
}
diff --git a/arm/aarch64/arm-cpu.c b/arm/aarch64/arm-cpu.c
index 8efe877..f702b9e 100644
--- a/arm/aarch64/arm-cpu.c
+++ b/arm/aarch64/arm-cpu.c
@@ -12,7 +12,7 @@
static void generate_fdt_nodes(void *fdt, struct kvm *kvm, u32 gic_phandle)
{
int timer_interrupts[4] = {13, 14, 11, 10};
- gic__generate_fdt_nodes(fdt, gic_phandle);
+ gic__generate_fdt_nodes(fdt, gic_phandle, IRQCHIP_GICV2);
timer__generate_fdt_nodes(fdt, kvm, timer_interrupts);
}
diff --git a/arm/gic.c b/arm/gic.c
index 05f85a2..b6c5868 100644
--- a/arm/gic.c
+++ b/arm/gic.c
@@ -11,13 +11,13 @@
static int gic_fd = -1;
-static int gic__create_device(struct kvm *kvm)
+static int gic__create_device(struct kvm *kvm, enum irqchip_type type)
{
int err;
u64 cpu_if_addr = ARM_GIC_CPUI_BASE;
u64 dist_addr = ARM_GIC_DIST_BASE;
struct kvm_create_device gic_device = {
- .type = KVM_DEV_TYPE_ARM_VGIC_V2,
+ .flags = 0,
};
struct kvm_device_attr cpu_if_attr = {
.group = KVM_DEV_ARM_VGIC_GRP_ADDR,
@@ -26,17 +26,27 @@ static int gic__create_device(struct kvm *kvm)
};
struct kvm_device_attr dist_attr = {
.group = KVM_DEV_ARM_VGIC_GRP_ADDR,
- .attr = KVM_VGIC_V2_ADDR_TYPE_DIST,
.addr = (u64)(unsigned long)dist_addr,
};
+ switch (type) {
+ case IRQCHIP_GICV2:
+ gic_device.type = KVM_DEV_TYPE_ARM_VGIC_V2;
+ dist_attr.attr = KVM_VGIC_V2_ADDR_TYPE_DIST;
+ break;
+ }
+
err = ioctl(kvm-vm_fd, KVM_CREATE_DEVICE, gic_device);
if (err)
return err;
gic_fd = gic_device.fd;
- err = ioctl(gic_fd, KVM_SET_DEVICE_ATTR, cpu_if_attr);
+ switch (type) {
+ case IRQCHIP_GICV2:
+ err = ioctl(gic_fd, KVM_SET_DEVICE_ATTR, cpu_if_attr);
+ break;
+ }
if (err)
goto out_err;
@@ -80,13 +90,20 @@ static int gic__create_irqchip(struct kvm *kvm)
return err;
}
-int gic__create(struct kvm *kvm)
+int gic__create(struct kvm *kvm, enum irqchip_type type)
{
int err;
+ switch (type) {
+ case IRQCHIP_GICV2:
+ break;
+ default:
+ return -ENODEV;
+ }
+
/* Try the new way first, and fallback on legacy method otherwise */
- err = gic__create_device(kvm);
- if (err)
+ err = gic__create_device(kvm, type);
+ if (err type == IRQCHIP_GICV2)
err = gic__create_irqchip(kvm);
return err;
@@ -134,15 +151,24 @@ static int gic__init_gic(struct kvm *kvm)
}
late_init(gic__init_gic)
-void gic__generate_fdt_nodes(void *fdt, u32 phandle)
+void gic__generate_fdt_nodes(void *fdt, u32 phandle, enum irqchip_type type)
{
+ const char *compatible;
u64 reg_prop[] = {
cpu_to_fdt64(ARM_GIC_DIST_BASE),
cpu_to_fdt64(ARM_GIC_DIST_SIZE),
cpu_to_fdt64(ARM_GIC_CPUI_BASE),
cpu_to_fdt64(ARM_GIC_CPUI_SIZE),
};
+ switch (type) {
+ case IRQCHIP_GICV2:
+ compatible = arm,cortex-a15-gic;
+ break;
+ default:
+ return;
+ }
+
_FDT(fdt_begin_node(fdt, intc));
- _FDT(fdt_property_string(fdt, compatible, arm,cortex-a15-gic));
+ _FDT(fdt_property_string(fdt, compatible, compatible));
_FDT(fdt_property_cell(fdt, #interrupt-cells, GIC_FDT_IRQ_NUM_CELLS));
_FDT(fdt_property(fdt, interrupt-controller, NULL, 0));
_FDT(fdt_property(fdt, reg, reg_prop, sizeof(reg_prop)));
diff --git a/arm/include/arm-common/gic.h b/arm/include/arm-common/gic.h
index 44859f7..d524f55 100644
--- a/arm/include/arm-common/gic.h
+++ b/arm/include/arm-common/gic.h
@@ -21,10 +21,14 @@
#define GIC_MAX_CPUS
[PATCH v5 05/10] arm: finish VGIC initialisation explicitly
Since Linux 3.19-rc1 there is a new API to explicitly initialise
the in-kernel GIC emulation by a userland KVM device call.
Use that to tell the kernel we are finished with the GIC
initialisation, since the automatic GIC init will only be provided
as a legacy functionality in the future.
Signed-off-by: Andre Przywara andre.przyw...@arm.com
Reviewed-by: Marc Zyngier marc.zyng...@arm.com
---
arm/gic.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/arm/gic.c b/arm/gic.c
index 8560c9b..99f0d2b 100644
--- a/arm/gic.c
+++ b/arm/gic.c
@@ -98,24 +98,43 @@ int gic__create(struct kvm *kvm)
return err;
}
+/*
+ * Sets the number of used interrupts and finalizes the GIC init explicitly.
+ */
static int gic__init_gic(struct kvm *kvm)
{
+ int ret;
+
int lines = irq__get_nr_allocated_lines();
u32 nr_irqs = ALIGN(lines, 32) + GIC_SPI_IRQ_BASE;
struct kvm_device_attr nr_irqs_attr = {
.group = KVM_DEV_ARM_VGIC_GRP_NR_IRQS,
.addr = (u64)(unsigned long)nr_irqs,
};
+ struct kvm_device_attr vgic_init_attr = {
+ .group = KVM_DEV_ARM_VGIC_GRP_CTRL,
+ .attr = KVM_DEV_ARM_VGIC_CTRL_INIT,
+ };
/*
* If we didn't use the KVM_CREATE_DEVICE method, KVM will
-* give us some default number of interrupts.
+* give us some default number of interrupts. The GIC initialization
+* will be done automatically in this case.
*/
if (gic_fd 0)
return 0;
- if (!ioctl(gic_fd, KVM_HAS_DEVICE_ATTR, nr_irqs_attr))
- return ioctl(gic_fd, KVM_SET_DEVICE_ATTR, nr_irqs_attr);
+ if (!ioctl(gic_fd, KVM_HAS_DEVICE_ATTR, nr_irqs_attr)) {
+ ret = ioctl(gic_fd, KVM_SET_DEVICE_ATTR, nr_irqs_attr);
+ if (ret)
+ return ret;
+ }
+
+ if (!ioctl(gic_fd, KVM_HAS_DEVICE_ATTR, vgic_init_attr)) {
+ ret = ioctl(gic_fd, KVM_SET_DEVICE_ATTR, vgic_init_attr);
+ if (ret)
+ return ret;
+ }
return 0;
}
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 09/11] KVM: arm: implement lazy world switch for debug registers
On June 30, 2015 9:15:22 PM GMT+08:00, Christoffer Dall
christoffer.d...@linaro.org wrote:
On Mon, Jun 22, 2015 at 06:41:32PM +0800, Zhichao Huang wrote:
Implement switching of the debug registers. While the number
of registers is massive, CPUs usually don't implement them all
(A15 has 6 breakpoints and 4 watchpoints, which gives us a total
of 22 registers only).
Notice that, for ARMv7, if the CONFIG_HAVE_HW_BREAKPOINT is set in
the guest, debug is always actively in use (ARM_DSCR_MDBGEN set).
We have to do the save/restore dance in this case, because the host
and the guest might use their respective debug registers at any moment.
this sounds expensive, and I suggested an alternative approach in the
previsou patch. In any case, measuring the impact on this on hardware
would be a great idea...
If the CONFIG_HAVE_HW_BREAKPOINT is not set, and if no one flagged
the debug registers as dirty, we only save/resotre DBGDSCR.
restore
Signed-off-by: Zhichao Huang zhichao.hu...@linaro.org
---
arch/arm/kvm/interrupts.S | 16 +++
arch/arm/kvm/interrupts_head.S | 249
-
2 files changed, 263 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S
index 79caf79..d626275 100644
--- a/arch/arm/kvm/interrupts.S
+++ b/arch/arm/kvm/interrupts.S
@@ -116,6 +116,12 @@ ENTRY(__kvm_vcpu_run)
read_cp15_state store_to_vcpu = 0
write_cp15_state read_from_vcpu = 1
+@ Store hardware CP14 state and load guest state
+compute_debug_state 1f
+bl __save_host_debug_regs
+bl __restore_guest_debug_regs
+
+1:
@ If the host kernel has not been configured with VFPv3 support,
@ then it is safer if we deny guests from using it as well.
#ifdef CONFIG_VFPv3
@@ -201,6 +207,16 @@ after_vfp_restore:
mrc p15, 0, r2, c0, c0, 5
mcr p15, 4, r2, c0, c0, 5
+@ Store guest CP14 state and restore host state
+skip_debug_state 1f
+bl __save_guest_debug_regs
+bl __restore_host_debug_regs
+/* Clear the dirty flag for the next run, as all the state has
+ * already been saved. Note that we nuke the whole 32bit word.
+ * If we ever add more flags, we'll have to be more careful...
+ */
+clear_debug_dirty_bit
+1:
@ Store guest CP15 state and restore host state
read_cp15_state store_to_vcpu = 1
write_cp15_state read_from_vcpu = 0
diff --git a/arch/arm/kvm/interrupts_head.S b/arch/arm/kvm/interrupts_head.S
index 5662c39..ed406be 100644
--- a/arch/arm/kvm/interrupts_head.S
+++ b/arch/arm/kvm/interrupts_head.S
@@ -7,6 +7,7 @@
#define VCPU_USR_SP (VCPU_USR_REG(13))
#define VCPU_USR_LR (VCPU_USR_REG(14))
#define CP15_OFFSET(_cp15_reg_idx) (VCPU_CP15 + (_cp15_reg_idx * 4))
+#define CP14_OFFSET(_cp14_reg_idx) (VCPU_CP14 + ((_cp14_reg_idx) *
4))
/*
* Many of these macros need to access the VCPU structure, which is
always
@@ -168,8 +169,7 @@ vcpu .reqr0 @ vcpu pointer always
in r0
* Clobbers *all* registers.
*/
.macro restore_guest_regs
-/* reset DBGDSCR to disable debug mode */
-mov r2, #0
+ldr r2, [vcpu, #CP14_OFFSET(cp14_DBGDSCRext)]
mcr p14, 0, r2, c0, c2, 2
restore_guest_regs_mode svc, #VCPU_SVC_REGS
@@ -250,6 +250,10 @@ vcpu.reqr0 @ vcpu pointer always
in r0
save_guest_regs_mode abt, #VCPU_ABT_REGS
save_guest_regs_mode und, #VCPU_UND_REGS
save_guest_regs_mode irq, #VCPU_IRQ_REGS
+
+/* DBGDSCR reg */
+mrc p14, 0, r2, c0, c1, 0
+str r2, [vcpu, #CP14_OFFSET(cp14_DBGDSCRext)]
.endm
/* Reads cp15 registers from hardware and stores them in memory
@@ -449,6 +453,231 @@ vcpu .reqr0 @ vcpu pointer always
in r0
str r5, [vcpu, #VCPU_DEBUG_FLAGS]
.endm
+/* Assume r11/r12 in used, clobbers r2-r10 */
+.macro cp14_read_and_push Op2 skip_num
+cmp \skip_num, #8
+// if (skip_num = 8) then skip c8-c15 directly
+bge 1f
+adr r2, 9998f
+add r2, r2, \skip_num, lsl #2
+bx r2
+1:
+adr r2, f
+sub r3, \skip_num, #8
+add r2, r2, r3, lsl #2
+bx r2
+9998:
+mrc p14, 0, r10, c0, c15, \Op2
+mrc p14, 0, r9, c0, c14, \Op2
+mrc p14, 0, r8, c0, c13, \Op2
+mrc p14, 0, r7, c0, c12, \Op2
+mrc p14, 0, r6, c0, c11, \Op2
+mrc p14, 0, r5, c0, c10, \Op2
+mrc p14, 0, r4, c0, c9, \Op2
+mrc p14, 0, r3, c0, c8, \Op2
+push{r3-r10}
you probably don't want to do more stores to memory than required
Yeah, there is no need to push some registers, but I can't find a better
way to optimize it, is there any precedents that I can refer to?
Imaging that there are only 2 hwbrpts available, BCR0/BCR1, and we
can code like this:
Save:
jump to 1
save BCR2 to r5
Re: [[PATCH 2/2] kvm: enable preemption to register/unregister preempt notifier
On 03/07/2015 10:56, Tiejun Chen wrote:
After commit 1cde2930e154 (sched/preempt: Add static_key() to
preempt_notifiers) is introduced, preempt_notifier_{register, unregister}
always hold a mutex, jump_label_mutex. So in current case this shouldn't
work further under the circumstance of disabled preemption, and its also
safe since we're just handling a per-vcpu stuff with holding vcpu-mutex.
Otherwise, some warning messages are posted like this,
BUG: scheduling while atomic: qemu-system-x86/17177/0x0002
2 locks held by qemu-system-x86/17177:
#0: (vcpu-mutex){+.+.+.}, at: [a035fb48] vcpu_load+0x28/0xf0
[kvm]
#1: (jump_label_mutex){+.+.+.}, at: [81244b54]
static_key_slow_inc+0xc4/0x140
Modules linked in: x86_pkg_temp_thermal kvm_intel kvm
Preemption disabled at:[a035fd3e] kvm_vcpu_ioctl+0x7e/0xeb0 [kvm]
Thanks for your work Tiejun. However, the original patch is crap. I've
asked to revert it.
Paolo
CPU: 2 PID: 17177 Comm: qemu-system-x86 Tainted: GW 4.1.0+ #30
Hardware name: Dell Inc. OptiPlex 9020/0DNKMN, BIOS A05 12/05/2013
00200206 8801c584bc38 81f974ab 0003
880211289a80 8801c584bc58 81f8fd3e 0001
8802161d5d00 8801c584bcb8 81fa43dc 8801c584bd68
Call Trace:
[81f974ab] dump_stack+0x95/0xf2
[81f8fd3e] __schedule_bug+0x108/0x126
[81fa43dc] __schedule+0x12dc/0x1590
[81fa4965] schedule+0x75/0x150
[81fa7683] ? mutex_lock_nested+0x393/0x780
[81fa4db0] schedule_preempt_disabled+0x30/0x60
[81fa753a] mutex_lock_nested+0x24a/0x780
[81244b54] ? static_key_slow_inc+0xc4/0x140
[81244b54] ? static_key_slow_inc+0xc4/0x140
[a035fb48] ? vcpu_load+0x28/0xf0 [kvm]
[81244b54] static_key_slow_inc+0xc4/0x140
[810d36a5] preempt_notifier_register+0x25/0x70
[a035fb96] vcpu_load+0x76/0xf0 [kvm]
[a035fd3e] kvm_vcpu_ioctl+0x7e/0xeb0 [kvm]
[8110bc40] ? __lock_is_held+0x70/0xa0
[810dde79] ? get_parent_ip+0x19/0x90
[8130e4b4] do_vfs_ioctl+0x3c4/0x910
[81320a01] ? expand_files+0x311/0x360
[815370af] ? selinux_file_ioctl+0x6f/0x150
[8130eaad] SyS_ioctl+0xad/0xe0
[81faf857] entry_SYSCALL_64_fastpath+0x12/0x6f
CC: Gleb Natapov g...@kernel.org
CC: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
---
virt/kvm/kvm_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 848af90..bde5f66f 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -127,8 +127,8 @@ int vcpu_load(struct kvm_vcpu *vcpu)
if (mutex_lock_killable(vcpu-mutex))
return -EINTR;
- cpu = get_cpu();
preempt_notifier_register(vcpu-preempt_notifier);
+ cpu = get_cpu();
kvm_arch_vcpu_load(vcpu, cpu);
put_cpu();
return 0;
@@ -138,8 +138,8 @@ void vcpu_put(struct kvm_vcpu *vcpu)
{
preempt_disable();
kvm_arch_vcpu_put(vcpu);
- preempt_notifier_unregister(vcpu-preempt_notifier);
preempt_enable();
+ preempt_notifier_unregister(vcpu-preempt_notifier);
mutex_unlock(vcpu-mutex);
}
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] arm64: KVM: Optimize arm64 skip 30-50% vfp/simd save/restore on exits
On Thu, Jul 02, 2015 at 02:51:57PM -0700, Mario Smarduch wrote: On 07/01/2015 06:46 AM, Christoffer Dall wrote: On Wed, Jun 24, 2015 at 05:04:11PM -0700, Mario Smarduch wrote: This patch only saves and restores FP/SIMD registers on Guest access. To do this cptr_el2 FP/SIMD trap is set on Guest entry and later checked on exit. lmbench, hackbench show significant improvements, for 30-50% exits FP/SIMD context is not saved/restored Signed-off-by: Mario Smarduch m.smard...@samsung.com --- arch/arm64/include/asm/kvm_arm.h |5 - arch/arm64/kvm/hyp.S | 46 +++--- 2 files changed, 47 insertions(+), 4 deletions(-) diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h index ac6fafb..7605e09 100644 --- a/arch/arm64/include/asm/kvm_arm.h +++ b/arch/arm64/include/asm/kvm_arm.h @@ -171,10 +171,13 @@ #define HSTR_EL2_TTEE (1 16) #define HSTR_EL2_T(x) (1 x) +/* Hyp Coproccessor Trap Register Shifts */ +#define CPTR_EL2_TFP_SHIFT 10 + /* Hyp Coprocessor Trap Register */ #define CPTR_EL2_TCPAC(1 31) #define CPTR_EL2_TTA (1 20) -#define CPTR_EL2_TFP (1 10) +#define CPTR_EL2_TFP (1 CPTR_EL2_TFP_SHIFT) /* Hyp Debug Configuration Register bits */ #define MDCR_EL2_TDRA (1 11) diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S index 5befd01..de0788f 100644 --- a/arch/arm64/kvm/hyp.S +++ b/arch/arm64/kvm/hyp.S @@ -673,6 +673,15 @@ tbz \tmp, #KVM_ARM64_DEBUG_DIRTY_SHIFT, \target .endm +/* + * Check cptr VFP/SIMD accessed bit, if set VFP/SIMD not accessed by guest. This comment doesn't really help me understand the function, may I suggest: Branch to target if CPTR_EL2.TFP bit is set (VFP/SIMD trapping enabled) Yes actually describes what it does. + */ +.macro skip_fpsimd_state tmp, target + mrs \tmp, cptr_el2 + tbnz\tmp, #CPTR_EL2_TFP_SHIFT, \target +.endm + + .macro compute_debug_state target // Compute debug state: If any of KDE, MDE or KVM_ARM64_DEBUG_DIRTY // is set, we do a full save/restore cycle and disable trapping. @@ -763,6 +772,7 @@ ldr x2, [x0, #VCPU_HCR_EL2] msr hcr_el2, x2 mov x2, #CPTR_EL2_TTA + orr x2, x2, #CPTR_EL2_TFP msr cptr_el2, x2 mov x2, #(1 15) // Trap CP15 Cr=15 @@ -785,7 +795,6 @@ .macro deactivate_traps mov x2, #HCR_RW msr hcr_el2, x2 - msr cptr_el2, xzr msr hstr_el2, xzr mrs x2, mdcr_el2 @@ -912,6 +921,28 @@ __restore_fpsimd: restore_fpsimd ret +switch_to_guest_fpsimd: + pushx4, lr + + mrs x2, cptr_el2 + bic x2, x2, #CPTR_EL2_TFP + msr cptr_el2, x2 + + mrs x0, tpidr_el2 + + ldr x2, [x0, #VCPU_HOST_CONTEXT] + kern_hyp_va x2 + bl __save_fpsimd + + add x2, x0, #VCPU_CONTEXT + bl __restore_fpsimd + + pop x4, lr + pop x2, x3 + pop x0, x1 + + eret + /* * u64 __kvm_vcpu_run(struct kvm_vcpu *vcpu); * @@ -932,7 +963,6 @@ ENTRY(__kvm_vcpu_run) kern_hyp_va x2 save_host_regs - bl __save_fpsimd bl __save_sysregs compute_debug_state 1f @@ -948,7 +978,6 @@ ENTRY(__kvm_vcpu_run) add x2, x0, #VCPU_CONTEXT bl __restore_sysregs - bl __restore_fpsimd skip_debug_state x3, 1f bl __restore_debug @@ -967,7 +996,9 @@ __kvm_vcpu_return: add x2, x0, #VCPU_CONTEXT save_guest_regs + skip_fpsimd_state x3, 1f bl __save_fpsimd +1: bl __save_sysregs skip_debug_state x3, 1f @@ -986,7 +1017,11 @@ __kvm_vcpu_return: kern_hyp_va x2 bl __restore_sysregs + skip_fpsimd_state x3, 1f bl __restore_fpsimd +1: + /* Clear FPSIMD and Trace trapping */ + msr cptr_el2, xzr why not simply move the deactivate_traps down here instead? Putting deactivate_traps there trashes x2, setup earlier to restore debug, host registers from host context Do we want deactivate_traps to use another register and move the macro there? Or leave as is? There was some clean symmetry in the code by using deactivate traps, but given this, I don't care strongly which way we end up doing it. Thanks, -Christoffer -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 08/17] kvm: arm/arm64: implement kvm_arm_[halt,resume]_guest
Christoffer, Marc,
On 07/02/2015 03:17 PM, Eric Auger wrote:
On halt, the guest is forced to exit and prevented from being
re-entered. This is synchronous.
Those two operations will be needed for IRQ forwarding setting.
Signed-off-by: Eric Auger eric.au...@linaro.org
would you agree to handle this ARM functionality separately from the
forwarding series?
This includes 2 patch files, that one +
https://lkml.org/lkml/2015/7/2/288. This functionality is needed for
forwarding control since when changing the forwarding state we need to
freeze the state of the physical/virtual IRQ to undertake proper
actions. Stopping the guest makes sure it won't deactivate the virtual
IRQ while we are doing state change actions.
The forwarding series is quite heterogeneous (VFIO platform driver,
vgic, irq bypass manager) and I think it would simplify the review process.
Please let me know if you agree. If yes, I will post a separate series.
Best Regards
Eric
---
RFC:
- rename the function and this latter becomes static
- remove __KVM_HAVE_ARCH_HALT_GUEST
v4 - v5: add arm64 support
- also defines __KVM_HAVE_ARCH_HALT_GUEST for arm64
- add pause field
---
arch/arm/include/asm/kvm_host.h | 3 +++
arch/arm/kvm/arm.c| 32 +---
arch/arm64/include/asm/kvm_host.h | 3 +++
3 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 304004d..899ae27 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -132,6 +132,9 @@ struct kvm_vcpu_arch {
/* vcpu power-off state */
bool power_off;
+ /* Don't run the guest */
+ bool pause;
+
/* IO related fields */
struct kvm_decode mmio_decode;
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 7537e68..4be6715 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -471,11 +471,36 @@ bool kvm_arch_intc_initialized(struct kvm *kvm)
return vgic_initialized(kvm);
}
+static void kvm_arm_halt_guest(struct kvm *kvm)
+{
+ int i;
+ struct kvm_vcpu *vcpu;
+
+ kvm_for_each_vcpu(i, vcpu, kvm)
+ vcpu-arch.pause = true;
+ force_vm_exit(cpu_all_mask);
+}
+
+static void kvm_arm_resume_guest(struct kvm *kvm)
+{
+ int i;
+ struct kvm_vcpu *vcpu;
+
+ kvm_for_each_vcpu(i, vcpu, kvm) {
+ wait_queue_head_t *wq = kvm_arch_vcpu_wq(vcpu);
+
+ vcpu-arch.pause = false;
+ wake_up_interruptible(wq);
+ }
+}
+
+
static void vcpu_pause(struct kvm_vcpu *vcpu)
{
wait_queue_head_t *wq = kvm_arch_vcpu_wq(vcpu);
- wait_event_interruptible(*wq, !vcpu-arch.power_off);
+ wait_event_interruptible(*wq, ((!vcpu-arch.power_off)
+(!vcpu-arch.pause)));
}
static int kvm_vcpu_initialized(struct kvm_vcpu *vcpu)
@@ -525,7 +550,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct
kvm_run *run)
update_vttbr(vcpu-kvm);
- if (vcpu-arch.power_off)
+ if (vcpu-arch.power_off || vcpu-arch.pause)
vcpu_pause(vcpu);
/*
@@ -551,7 +576,8 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct
kvm_run *run)
run-exit_reason = KVM_EXIT_INTR;
}
- if (ret = 0 || need_new_vmid_gen(vcpu-kvm)) {
+ if (ret = 0 || need_new_vmid_gen(vcpu-kvm) ||
+ vcpu-arch.pause) {
local_irq_enable();
preempt_enable();
kvm_vgic_sync_hwstate(vcpu);
diff --git a/arch/arm64/include/asm/kvm_host.h
b/arch/arm64/include/asm/kvm_host.h
index 009da6b..69e3785 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -125,6 +125,9 @@ struct kvm_vcpu_arch {
/* vcpu power-off state */
bool power_off;
+ /* Don't run the guest */
+ bool pause;
+
/* IO related fields */
struct kvm_decode mmio_decode;
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 08/11] KVM: arm: implement dirty bit mechanism for debug registers
On Fri, Jul 03, 2015 at 05:54:47PM +0800, Zhichao Huang wrote:
On June 30, 2015 5:20:20 PM GMT+08:00, Christoffer Dall
christoffer.d...@linaro.org wrote:
On Mon, Jun 22, 2015 at 06:41:31PM +0800, Zhichao Huang wrote:
The trapping code keeps track of the state of the debug registers,
allowing for the switch code to implement a lazy switching strategy.
Signed-off-by: Zhichao Huang zhichao.hu...@linaro.org
---
arch/arm/include/asm/kvm_asm.h | 3 +++
arch/arm/include/asm/kvm_host.h | 3 +++
arch/arm/kernel/asm-offsets.c | 1 +
arch/arm/kvm/coproc.c | 39
--
arch/arm/kvm/interrupts_head.S | 42
+
5 files changed, 86 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/kvm_asm.h
b/arch/arm/include/asm/kvm_asm.h
index ba65e05..4fb64cf 100644
--- a/arch/arm/include/asm/kvm_asm.h
+++ b/arch/arm/include/asm/kvm_asm.h
@@ -64,6 +64,9 @@
#define cp14_DBGDSCRext 65 /* Debug Status and Control external */
#define NR_CP14_REGS 66 /* Number of regs (incl. invalid) */
+#define KVM_ARM_DEBUG_DIRTY_SHIFT 0
+#define KVM_ARM_DEBUG_DIRTY (1 KVM_ARM_DEBUG_DIRTY_SHIFT)
+
#define ARM_EXCEPTION_RESET 0
#define ARM_EXCEPTION_UNDEFINED 1
#define ARM_EXCEPTION_SOFTWARE2
diff --git a/arch/arm/include/asm/kvm_host.h
b/arch/arm/include/asm/kvm_host.h
index 3d16820..09b54bf 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -127,6 +127,9 @@ struct kvm_vcpu_arch {
/* System control coprocessor (cp14) */
u32 cp14[NR_CP14_REGS];
+ /* Debug state */
+ u32 debug_flags;
+
/*
* Anything that is not used directly from assembly code goes
* here.
diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
index 9158de0..e876109 100644
--- a/arch/arm/kernel/asm-offsets.c
+++ b/arch/arm/kernel/asm-offsets.c
@@ -185,6 +185,7 @@ int main(void)
DEFINE(VCPU_FIQ_REGS, offsetof(struct kvm_vcpu,
arch.regs.fiq_regs));
DEFINE(VCPU_PC, offsetof(struct kvm_vcpu,
arch.regs.usr_regs.ARM_pc));
DEFINE(VCPU_CPSR, offsetof(struct kvm_vcpu,
arch.regs.usr_regs.ARM_cpsr));
+ DEFINE(VCPU_DEBUG_FLAGS,offsetof(struct kvm_vcpu,
arch.debug_flags));
DEFINE(VCPU_HCR,offsetof(struct kvm_vcpu, arch.hcr));
DEFINE(VCPU_IRQ_LINES, offsetof(struct kvm_vcpu, arch.irq_lines));
DEFINE(VCPU_HSR,offsetof(struct kvm_vcpu,
arch.fault.hsr));
diff --git a/arch/arm/kvm/coproc.c b/arch/arm/kvm/coproc.c
index 648..fc0c2ef 100644
--- a/arch/arm/kvm/coproc.c
+++ b/arch/arm/kvm/coproc.c
@@ -220,14 +220,49 @@ bool access_vm_reg(struct kvm_vcpu *vcpu,
return true;
}
+/*
+ * We want to avoid world-switching all the DBG registers all the
+ * time:
+ *
+ * - If we've touched any debug register, it is likely that we're
+ * going to touch more of them. It then makes sense to disable the
+ * traps and start doing the save/restore dance
+ * - If debug is active (ARM_DSCR_MDBGEN set), it is then mandatory
+ * to save/restore the registers, as the guest depends on them.
+ *
+ * For this, we use a DIRTY bit, indicating the guest has modified
the
+ * debug registers, used as follow:
+ *
+ * On guest entry:
+ * - If the dirty bit is set (because we're coming back from
trapping),
+ * disable the traps, save host registers, restore guest
registers.
+ * - If debug is actively in use (ARM_DSCR_MDBGEN set),
+ * set the dirty bit, disable the traps, save host registers,
+ * restore guest registers.
+ * - Otherwise, enable the traps
+ *
+ * On guest exit:
+ * - If the dirty bit is set, save guest registers, restore host
+ * registers and clear the dirty bit. This ensure that the host can
+ * now use the debug registers.
+ *
+ * Notice:
+ * - For ARMv7, if the CONFIG_HAVE_HW_BREAKPOINT is set in the guest,
+ * debug is always actively in use (ARM_DSCR_MDBGEN set).
+ * We have to do the save/restore dance in this case, because the
+ * host and the guest might use their respective debug registers
+ * at any moment.
so doesn't this pretty much invalidate the whole saving/dirty effort?
Guests configured from for example multi_v7_defconfig will then act
like
this and you will save/restore all these registers always.
Wouldn't a better approach be to enable trapping to hyp mode most of
the
time, and simply clear the enabled bit of any host-used break- or
wathcpoints upon guest entry, perhaps maintaining a bitmap of which
ones
must be re-set when exiting the guest, and thereby drastically reducing
the amount of save/restore code you'd have to perform.
Of course, you'd also have to keep track of whether the guest has any
breakpoints or watchpoints
[PATCH 5/12] kvm: added KVM_REQ_HV_CRASH value to notify qemu about hyper-v crash
From: Andrey Smetanin asmeta...@virtuozzo.com Added KVM_REQ_HV_CRASH - vcpu request used for notify user space(QEMU) about Hyper-V crash. Signed-off-by: Andrey Smetanin asmeta...@virtuozzo.com Signed-off-by: Denis V. Lunev d...@openvz.org Reviewed-by: Peter Hornyack peterhorny...@google.com CC: Paolo Bonzini pbonz...@redhat.com CC: Gleb Natapov g...@kernel.org --- include/linux/kvm_host.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 2b2edf1..a377e00 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -139,6 +139,7 @@ static inline bool is_error_page(struct page *page) #define KVM_REQ_DISABLE_IBS 24 #define KVM_REQ_APIC_PAGE_RELOAD 25 #define KVM_REQ_SMI 26 +#define KVM_REQ_HV_CRASH 27 #define KVM_USERSPACE_IRQ_SOURCE_ID0 #define KVM_IRQFD_RESAMPLE_IRQ_SOURCE_ID 1 -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 0/12] HyperV equivalent of pvpanic driver
Windows 2012 guests can notify hypervisor about occurred guest crash (Windows bugcheck(BSOD)) by writing specific Hyper-V msrs. This patch does handling of this MSR's by KVM and sending notification to user space that allows to gather Windows guest crash dump by QEMU/LIBVIRT. The idea is to provide functionality equal to pvpanic device without QEMU guest agent for Windows. The idea is borrowed from Linux HyperV bus driver and validated against Windows 2k12. Changes from v5: * added hyperv crash msrs into supported/emulated list * qemu: reset CPUState::crash_occurred at cpu reset * qemu: userspace checks kernel support of hyperv crash msrs by kvm_get_supported_msrs Changes from v4: * fixed typo in email of Andreas Färber afaer...@suse.de my vim strangely behaves on lines with extended Deutch chars Changes from v3: * remove unused HV_X64_MSR_CRASH_CTL_NOTIFY * added documentation section about KVM_SYSTEM_EVENT_CRASH * allow only supported values inside crash ctl msr * qemu: split patch into generic crash handling patches and hyperv specific * qemu: skip migration of crash ctl msr value Changes from v2: * forbid modification crash ctl msr by guest * qemu_system_guest_panicked usage in pvpanic and s390x * hyper-v crash handler move from generic kvm to i386 * hyper-v crash handler: skip fetching crash msrs just mark crash occurred * sync with linux-next 20150629 * patch 11 squashed to patch 10 * patch 9 squashed to patch 7 Changes from v1: * hyperv code move to hyperv.c * added read handlers of crash data msrs * added per vm and per cpu hyperv context structures * added saving crash msrs inside qemu cpu state * added qemu fetch and update of crash msrs * added qemu crash msrs store in cpu state and it's migration Signed-off-by: Andrey Smetanin asmeta...@virtuozzo.com Signed-off-by: Denis V. Lunev d...@openvz.org CC: Gleb Natapov g...@kernel.org CC: Paolo Bonzini pbonz...@redhat.com -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/12] kvm/x86: move Hyper-V MSR's/hypercall code into hyperv.c file
From: Andrey Smetanin asmeta...@virtuozzo.com
This patch introduce Hyper-V related source code file - hyperv.c and
per vm and per vcpu hyperv context structures.
All Hyper-V MSR's and hypercall code moved into hyperv.c.
All Hyper-V kvm/vcpu fields moved into appropriate hyperv context
structures. Copyrights and authors information copied from x86.c
to hyperv.c.
Signed-off-by: Andrey Smetanin asmeta...@virtuozzo.com
Signed-off-by: Denis V. Lunev d...@openvz.org
Reviewed-by: Peter Hornyack peterhorny...@google.com
CC: Paolo Bonzini pbonz...@redhat.com
CC: Gleb Natapov g...@kernel.org
---
arch/x86/include/asm/kvm_host.h | 20 ++-
arch/x86/kvm/Makefile | 4 +-
arch/x86/kvm/hyperv.c | 307
arch/x86/kvm/hyperv.h | 32 +
arch/x86/kvm/lapic.h| 2 +-
arch/x86/kvm/x86.c | 265 +-
arch/x86/kvm/x86.h | 5 +
7 files changed, 366 insertions(+), 269 deletions(-)
create mode 100644 arch/x86/kvm/hyperv.c
create mode 100644 arch/x86/kvm/hyperv.h
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index c7fa57b..78616aa 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -358,6 +358,11 @@ struct kvm_mtrr {
struct list_head head;
};
+/* Hyper-V per vcpu emulation context */
+struct kvm_vcpu_hv {
+ u64 hv_vapic;
+};
+
struct kvm_vcpu_arch {
/*
* rip and regs accesses must go through
@@ -514,8 +519,7 @@ struct kvm_vcpu_arch {
/* used for guest single stepping over the given code position */
unsigned long singlestep_rip;
- /* fields used by HYPER-V emulation */
- u64 hv_vapic;
+ struct kvm_vcpu_hv hyperv;
cpumask_var_t wbinvd_dirty_mask;
@@ -586,6 +590,13 @@ struct kvm_apic_map {
struct kvm_lapic *logical_map[16][16];
};
+/* Hyper-V emulation context */
+struct kvm_hv {
+ u64 hv_guest_os_id;
+ u64 hv_hypercall;
+ u64 hv_tsc_page;
+};
+
struct kvm_arch {
unsigned int n_used_mmu_pages;
unsigned int n_requested_mmu_pages;
@@ -643,10 +654,7 @@ struct kvm_arch {
/* reads protected by irq_srcu, writes by irq_lock */
struct hlist_head mask_notifier_list;
- /* fields used by HYPER-V emulation */
- u64 hv_guest_os_id;
- u64 hv_hypercall;
- u64 hv_tsc_page;
+ struct kvm_hv hyperv;
#ifdef CONFIG_KVM_MMU_AUDIT
int audit_point;
diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile
index 67d215c..a1ff508 100644
--- a/arch/x86/kvm/Makefile
+++ b/arch/x86/kvm/Makefile
@@ -12,7 +12,9 @@ kvm-y += $(KVM)/kvm_main.o
$(KVM)/coalesced_mmio.o \
kvm-$(CONFIG_KVM_ASYNC_PF) += $(KVM)/async_pf.o
kvm-y += x86.o mmu.o emulate.o i8259.o irq.o lapic.o \
- i8254.o ioapic.o irq_comm.o cpuid.o pmu.o mtrr.o
+ i8254.o ioapic.o irq_comm.o cpuid.o pmu.o mtrr.o \
+ hyperv.o
+
kvm-$(CONFIG_KVM_DEVICE_ASSIGNMENT)+= assigned-dev.o iommu.o
kvm-intel-y+= vmx.o pmu_intel.o
kvm-amd-y += svm.o pmu_amd.o
diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
new file mode 100644
index 000..2b49f10
--- /dev/null
+++ b/arch/x86/kvm/hyperv.c
@@ -0,0 +1,307 @@
+/*
+ * KVM Microsoft Hyper-V emulation
+ *
+ * derived from arch/x86/kvm/x86.c
+ *
+ * Copyright (C) 2006 Qumranet, Inc.
+ * Copyright (C) 2008 Qumranet, Inc.
+ * Copyright IBM Corporation, 2008
+ * Copyright 2010 Red Hat, Inc. and/or its affiliates.
+ * Copyright (C) 2015 Andrey Smetanin asmeta...@virtuozzo.com
+ *
+ * Authors:
+ * Avi Kivity a...@qumranet.com
+ * Yaniv Kamay ya...@qumranet.com
+ * Amit Shahamit.s...@qumranet.com
+ * Ben-Ami Yassour ben...@il.ibm.com
+ * Andrey Smetanin asmeta...@virtuozzo.com
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include x86.h
+#include lapic.h
+#include hyperv.h
+
+#include linux/kvm_host.h
+#include trace/events/kvm.h
+
+#include trace.h
+
+static bool kvm_hv_msr_partition_wide(u32 msr)
+{
+ bool r = false;
+
+ switch (msr) {
+ case HV_X64_MSR_GUEST_OS_ID:
+ case HV_X64_MSR_HYPERCALL:
+ case HV_X64_MSR_REFERENCE_TSC:
+ case HV_X64_MSR_TIME_REF_COUNT:
+ r = true;
+ break;
+ }
+
+ return r;
+}
+
+static int kvm_hv_set_msr_pw(struct kvm_vcpu *vcpu, u32 msr, u64 data)
+{
+ struct kvm *kvm = vcpu-kvm;
+ struct kvm_hv *hv = kvm-arch.hyperv;
+
+ switch (msr) {
+ case HV_X64_MSR_GUEST_OS_ID:
+ hv-hv_guest_os_id = data;
+ /* setting guest os id to zero disables hypercall page */
+ if (!hv-hv_guest_os_id)
+ hv-hv_hypercall =
[PATCH 10/12] kvm: Add kvm system event crash handler
From: Andrey Smetanin asmeta...@virtuozzo.com
KVM kernel can send guest crash events into userspace.
Appropriate guest crash handler is called when kernel guest
crash event received. Guest crash event recognized by a
KVM_SYSTEM_EVENT_CRASH type of system event.
Signed-off-by: Andrey Smetanin asmeta...@virtuozzo.com
Signed-off-by: Denis V. Lunev d...@openvz.org
CC: Paolo Bonzini pbonz...@redhat.com
CC: Andreas Färber afaer...@suse.de
---
kvm-all.c | 4
linux-headers/linux/kvm.h | 1 +
2 files changed, 5 insertions(+)
diff --git a/kvm-all.c b/kvm-all.c
index 53e01d4..7a959b6 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -1844,6 +1844,10 @@ int kvm_cpu_exec(CPUState *cpu)
qemu_system_reset_request();
ret = EXCP_INTERRUPT;
break;
+case KVM_SYSTEM_EVENT_CRASH:
+qemu_system_guest_panicked();
+ret = 0;
+break;
default:
DPRINTF(kvm_arch_handle_exit\n);
ret = kvm_arch_handle_exit(cpu, run);
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index fad9e5c..409be37 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -317,6 +317,7 @@ struct kvm_run {
struct {
#define KVM_SYSTEM_EVENT_SHUTDOWN 1
#define KVM_SYSTEM_EVENT_RESET 2
+#define KVM_SYSTEM_EVENT_CRASH 3
__u32 type;
__u64 flags;
} system_event;
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/12] kvm: add hyper-v crash msrs values
From: Andrey Smetanin asmeta...@virtuozzo.com Added Hyper-V crash msrs values - HV_X64_MSR_CRASH*. Signed-off-by: Andrey Smetanin asmeta...@virtuozzo.com Signed-off-by: Denis V. Lunev d...@openvz.org Reviewed-by: Peter Hornyack peterhorny...@google.com CC: Paolo Bonzini pbonz...@redhat.com CC: Gleb Natapov g...@kernel.org --- arch/x86/include/uapi/asm/hyperv.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/x86/include/uapi/asm/hyperv.h b/arch/x86/include/uapi/asm/hyperv.h index ce6068d..8fba544 100644 --- a/arch/x86/include/uapi/asm/hyperv.h +++ b/arch/x86/include/uapi/asm/hyperv.h @@ -199,6 +199,17 @@ #define HV_X64_MSR_STIMER3_CONFIG 0x40B6 #define HV_X64_MSR_STIMER3_COUNT 0x40B7 +/* Hyper-V guest crash notification MSR's */ +#define HV_X64_MSR_CRASH_P00x4100 +#define HV_X64_MSR_CRASH_P10x4101 +#define HV_X64_MSR_CRASH_P20x4102 +#define HV_X64_MSR_CRASH_P30x4103 +#define HV_X64_MSR_CRASH_P40x4104 +#define HV_X64_MSR_CRASH_CTL 0x4105 +#define HV_X64_MSR_CRASH_CTL_NOTIFY(1ULL 63) +#define HV_X64_MSR_CRASH_PARAMS\ + (1 + (HV_X64_MSR_CRASH_P4 - HV_X64_MSR_CRASH_P0)) + #define HV_X64_MSR_HYPERCALL_ENABLE0x0001 #define HV_X64_MSR_HYPERCALL_PAGE_ADDRESS_SHIFT12 #define HV_X64_MSR_HYPERCALL_PAGE_ADDRESS_MASK \ -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/12] Added generic panic handler qemu_system_guest_panicked()
From: Andrey Smetanin asmeta...@virtuozzo.com
There are pieces of guest panic handling code
that can be shared in one generic function.
These code replaced by call qemu_system_guest_panicked().
Signed-off-by: Andrey Smetanin asmeta...@virtuozzo.com
Signed-off-by: Denis V. Lunev d...@openvz.org
CC: Paolo Bonzini pbonz...@redhat.com
CC: Andreas Färber afaer...@suse.de
---
hw/misc/pvpanic.c | 3 +--
include/sysemu/sysemu.h | 1 +
target-s390x/kvm.c | 11 ++-
vl.c| 6 ++
4 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/hw/misc/pvpanic.c b/hw/misc/pvpanic.c
index 994f8af..3709488 100644
--- a/hw/misc/pvpanic.c
+++ b/hw/misc/pvpanic.c
@@ -41,8 +41,7 @@ static void handle_event(int event)
}
if (event PVPANIC_PANICKED) {
-qapi_event_send_guest_panicked(GUEST_PANIC_ACTION_PAUSE, error_abort);
-vm_stop(RUN_STATE_GUEST_PANICKED);
+qemu_system_guest_panicked();
return;
}
}
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index df80951..70164c9 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -68,6 +68,7 @@ int qemu_reset_requested_get(void);
void qemu_system_killed(int signal, pid_t pid);
void qemu_devices_reset(void);
void qemu_system_reset(bool report);
+void qemu_system_guest_panicked(void);
void qemu_add_exit_notifier(Notifier *notify);
void qemu_remove_exit_notifier(Notifier *notify);
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index 135111a..e5bd3ef 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -1796,13 +1796,6 @@ static bool is_special_wait_psw(CPUState *cs)
return cs-kvm_run-psw_addr == 0xfffUL;
}
-static void guest_panicked(void)
-{
-qapi_event_send_guest_panicked(GUEST_PANIC_ACTION_PAUSE,
- error_abort);
-vm_stop(RUN_STATE_GUEST_PANICKED);
-}
-
static void unmanageable_intercept(S390CPU *cpu, const char *str, int
pswoffset)
{
CPUState *cs = CPU(cpu);
@@ -1811,7 +1804,7 @@ static void unmanageable_intercept(S390CPU *cpu, const
char *str, int pswoffset)
str, cs-cpu_index, ldq_phys(cs-as, cpu-env.psa +
pswoffset),
ldq_phys(cs-as, cpu-env.psa + pswoffset + 8));
s390_cpu_halt(cpu);
-guest_panicked();
+qemu_system_guest_panicked();
}
static int handle_intercept(S390CPU *cpu)
@@ -1844,7 +1837,7 @@ static int handle_intercept(S390CPU *cpu)
if (is_special_wait_psw(cs)) {
qemu_system_shutdown_request();
} else {
-guest_panicked();
+qemu_system_guest_panicked();
}
}
r = EXCP_HALTED;
diff --git a/vl.c b/vl.c
index 69ad90c..38eee1f 100644
--- a/vl.c
+++ b/vl.c
@@ -1721,6 +1721,12 @@ void qemu_system_reset(bool report)
cpu_synchronize_all_post_reset();
}
+void qemu_system_guest_panicked(void)
+{
+qapi_event_send_guest_panicked(GUEST_PANIC_ACTION_PAUSE, error_abort);
+vm_stop(RUN_STATE_GUEST_PANICKED);
+}
+
void qemu_system_reset_request(void)
{
if (no_reboot) {
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/12] i386/kvm: Hyper-v crash msrs set/get'ers and migration
From: Andrey Smetanin asmeta...@virtuozzo.com
KVM Hyper-V based guests can notify hypervisor about
occurred guest crash by writing into Hyper-V crash MSR's.
This patch does handling and migration of HV_X64_MSR_CRASH_P0-P4,
HV_X64_MSR_CRASH_CTL msrs. User can enable these MSR's by
'hv-crash' option.
Signed-off-by: Andrey Smetanin asmeta...@virtuozzo.com
Signed-off-by: Denis V. Lunev d...@openvz.org
CC: Paolo Bonzini pbonz...@redhat.com
CC: Andreas Färber afaer...@suse.de
---
linux-headers/asm-x86/hyperv.h | 13 +
target-i386/cpu-qom.h | 1 +
target-i386/cpu.c | 1 +
target-i386/cpu.h | 2 ++
target-i386/kvm.c | 32 +++-
target-i386/machine.c | 27 +++
6 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/linux-headers/asm-x86/hyperv.h b/linux-headers/asm-x86/hyperv.h
index ce6068d..5f88dc7 100644
--- a/linux-headers/asm-x86/hyperv.h
+++ b/linux-headers/asm-x86/hyperv.h
@@ -108,6 +108,8 @@
#define HV_X64_HYPERCALL_PARAMS_XMM_AVAILABLE (1 4)
/* Support for a virtual guest idle state is available */
#define HV_X64_GUEST_IDLE_STATE_AVAILABLE (1 5)
+/* Guest crash data handler available */
+#define HV_X64_GUEST_CRASH_MSR_AVAILABLE (1 10)
/*
* Implementation recommendations. Indicates which behaviors the hypervisor
@@ -199,6 +201,17 @@
#define HV_X64_MSR_STIMER3_CONFIG 0x40B6
#define HV_X64_MSR_STIMER3_COUNT 0x40B7
+/* Hypev-V guest crash notification MSR's */
+#define HV_X64_MSR_CRASH_P00x4100
+#define HV_X64_MSR_CRASH_P10x4101
+#define HV_X64_MSR_CRASH_P20x4102
+#define HV_X64_MSR_CRASH_P30x4103
+#define HV_X64_MSR_CRASH_P40x4104
+#define HV_X64_MSR_CRASH_CTL 0x4105
+#define HV_X64_MSR_CRASH_CTL_NOTIFY(1ULL 63)
+#define HV_X64_MSR_CRASH_PARAMS\
+ (1 + (HV_X64_MSR_CRASH_P4 - HV_X64_MSR_CRASH_P0))
+
#define HV_X64_MSR_HYPERCALL_ENABLE0x0001
#define HV_X64_MSR_HYPERCALL_PAGE_ADDRESS_SHIFT12
#define HV_X64_MSR_HYPERCALL_PAGE_ADDRESS_MASK \
diff --git a/target-i386/cpu-qom.h b/target-i386/cpu-qom.h
index 7a4fddd..c35b624 100644
--- a/target-i386/cpu-qom.h
+++ b/target-i386/cpu-qom.h
@@ -89,6 +89,7 @@ typedef struct X86CPU {
bool hyperv_relaxed_timing;
int hyperv_spinlock_attempts;
bool hyperv_time;
+bool hyperv_crash;
bool check_cpuid;
bool enforce_cpuid;
bool expose_kvm;
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 36b07f9..04a8408 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -3117,6 +3117,7 @@ static Property x86_cpu_properties[] = {
DEFINE_PROP_BOOL(hv-relaxed, X86CPU, hyperv_relaxed_timing, false),
DEFINE_PROP_BOOL(hv-vapic, X86CPU, hyperv_vapic, false),
DEFINE_PROP_BOOL(hv-time, X86CPU, hyperv_time, false),
+DEFINE_PROP_BOOL(hv-crash, X86CPU, hyperv_crash, false),
DEFINE_PROP_BOOL(check, X86CPU, check_cpuid, false),
DEFINE_PROP_BOOL(enforce, X86CPU, enforce_cpuid, false),
DEFINE_PROP_BOOL(kvm, X86CPU, expose_kvm, true),
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 603aaf0..6c2352a 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -21,6 +21,7 @@
#include config.h
#include qemu-common.h
+#include asm/hyperv.h
#ifdef TARGET_X86_64
#define TARGET_LONG_BITS 64
@@ -904,6 +905,7 @@ typedef struct CPUX86State {
uint64_t msr_hv_guest_os_id;
uint64_t msr_hv_vapic;
uint64_t msr_hv_tsc;
+uint64_t msr_hv_crash_prm[HV_X64_MSR_CRASH_PARAMS];
/* exception/interrupt handling */
int error_code;
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index daced5c..3d1fca5 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -79,6 +79,7 @@ static int lm_capable_kernel;
static bool has_msr_hv_hypercall;
static bool has_msr_hv_vapic;
static bool has_msr_hv_tsc;
+static bool has_msr_hv_crash;
static bool has_msr_mtrr;
static bool has_msr_xss;
@@ -449,7 +450,8 @@ static bool hyperv_enabled(X86CPU *cpu)
return kvm_check_extension(cs-kvm_state, KVM_CAP_HYPERV) 0
(hyperv_hypercall_available(cpu) ||
cpu-hyperv_time ||
-cpu-hyperv_relaxed_timing);
+cpu-hyperv_relaxed_timing ||
+cpu-hyperv_crash);
}
static Error *invtsc_mig_blocker;
@@ -515,6 +517,10 @@ int kvm_arch_init_vcpu(CPUState *cs)
c-eax |= 0x200;
has_msr_hv_tsc = true;
}
+if (cpu-hyperv_crash has_msr_hv_crash) {
+c-edx |= HV_X64_GUEST_CRASH_MSR_AVAILABLE;
+}
+
c = cpuid_data.entries[cpuid_i++];
c-function = HYPERV_CPUID_ENLIGHTMENT_INFO;
if (cpu-hyperv_relaxed_timing) {
@@ -831,6 +837,10 @@ static int kvm_get_supported_msrs(KVMState *s)
[PATCH 4/12] kvm/x86: added hyper-v crash msrs into kvm hyperv context
From: Andrey Smetanin asmeta...@virtuozzo.com
Added kvm Hyper-V context hv crash variables as storage
of Hyper-V crash msrs.
Signed-off-by: Andrey Smetanin asmeta...@virtuozzo.com
Signed-off-by: Denis V. Lunev d...@openvz.org
Reviewed-by: Peter Hornyack peterhorny...@google.com
CC: Paolo Bonzini pbonz...@redhat.com
CC: Gleb Natapov g...@kernel.org
---
arch/x86/include/asm/kvm_host.h | 4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 78616aa..697c1f3 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -595,6 +595,10 @@ struct kvm_hv {
u64 hv_guest_os_id;
u64 hv_hypercall;
u64 hv_tsc_page;
+
+ /* Hyper-v based guest crash (NT kernel bugcheck) parameters */
+ u64 hv_crash_param[HV_X64_MSR_CRASH_PARAMS];
+ u64 hv_crash_ctl;
};
struct kvm_arch {
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/12] cpu: Add crash_occurred flag into CPUState
From: Andrey Smetanin asmeta...@virtuozzo.com
CPUState::crash_occurred field inside CPUState marks
that guest crash occurred. This value is added into
cpu common migration subsection.
Signed-off-by: Andrey Smetanin asmeta...@virtuozzo.com
Signed-off-by: Denis V. Lunev d...@openvz.org
CC: Paolo Bonzini pbonz...@redhat.com
CC: Andreas Färber afaer...@suse.de
---
exec.c| 19 +++
include/qom/cpu.h | 1 +
qom/cpu.c | 1 +
vl.c | 3 +++
4 files changed, 24 insertions(+)
diff --git a/exec.c b/exec.c
index f7883d2..15c9a29 100644
--- a/exec.c
+++ b/exec.c
@@ -465,6 +465,24 @@ static const VMStateDescription
vmstate_cpu_common_exception_index = {
}
};
+static bool cpu_common_crash_occurred_needed(void *opaque)
+{
+CPUState *cpu = opaque;
+
+return cpu-crash_occurred;
+}
+
+static const VMStateDescription vmstate_cpu_common_crash_occurred = {
+.name = cpu_common/crash_occurred,
+.version_id = 1,
+.minimum_version_id = 1,
+.needed = cpu_common_crash_occurred_needed,
+.fields = (VMStateField[]) {
+VMSTATE_BOOL(crash_occurred, CPUState),
+VMSTATE_END_OF_LIST()
+}
+};
+
const VMStateDescription vmstate_cpu_common = {
.name = cpu_common,
.version_id = 1,
@@ -478,6 +496,7 @@ const VMStateDescription vmstate_cpu_common = {
},
.subsections = (const VMStateDescription*[]) {
vmstate_cpu_common_exception_index,
+vmstate_cpu_common_crash_occurred,
NULL
}
};
diff --git a/include/qom/cpu.h b/include/qom/cpu.h
index 39f0f19..aae05fd 100644
--- a/include/qom/cpu.h
+++ b/include/qom/cpu.h
@@ -263,6 +263,7 @@ struct CPUState {
bool created;
bool stop;
bool stopped;
+bool crash_occurred;
volatile sig_atomic_t exit_request;
uint32_t interrupt_request;
int singlestep_enabled;
diff --git a/qom/cpu.c b/qom/cpu.c
index 108bfa2..c3c4674 100644
--- a/qom/cpu.c
+++ b/qom/cpu.c
@@ -249,6 +249,7 @@ static void cpu_common_reset(CPUState *cpu)
cpu-icount_decr.u32 = 0;
cpu-can_do_io = 0;
cpu-exception_index = -1;
+cpu-crash_occurred = false;
memset(cpu-tb_jmp_cache, 0, TB_JMP_CACHE_SIZE * sizeof(void *));
}
diff --git a/vl.c b/vl.c
index 38eee1f..62bab42 100644
--- a/vl.c
+++ b/vl.c
@@ -1723,6 +1723,9 @@ void qemu_system_reset(bool report)
void qemu_system_guest_panicked(void)
{
+if (current_cpu) {
+current_cpu-crash_occurred = true;
+}
qapi_event_send_guest_panicked(GUEST_PANIC_ACTION_PAUSE, error_abort);
vm_stop(RUN_STATE_GUEST_PANICKED);
}
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/12] kvm/x86: mark hyper-v crash msrs as partition wide
From: Andrey Smetanin asmeta...@virtuozzo.com Hyper-V crash msr's are per vm, aren't per vcpu, so mark them as partition wide. Signed-off-by: Andrey Smetanin asmeta...@virtuozzo.com Signed-off-by: Denis V. Lunev d...@openvz.org Reviewed-by: Peter Hornyack peterhorny...@google.com CC: Paolo Bonzini pbonz...@redhat.com CC: Gleb Natapov g...@kernel.org --- arch/x86/kvm/hyperv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c index 2b49f10..af83c96 100644 --- a/arch/x86/kvm/hyperv.c +++ b/arch/x86/kvm/hyperv.c @@ -39,6 +39,8 @@ static bool kvm_hv_msr_partition_wide(u32 msr) case HV_X64_MSR_HYPERCALL: case HV_X64_MSR_REFERENCE_TSC: case HV_X64_MSR_TIME_REF_COUNT: + case HV_X64_MSR_CRASH_CTL: + case HV_X64_MSR_CRASH_P0 ... HV_X64_MSR_CRASH_P4: r = true; break; } -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/12] kvm: introduce vcpu_debug = kvm_debug + vcpu context
From: Andrey Smetanin asmeta...@virtuozzo.com
vcpu_debug is useful macro like kvm_debug but additionally
includes vcpu context inside output.
Signed-off-by: Andrey Smetanin asmeta...@virtuozzo.com
Signed-off-by: Denis V. Lunev d...@openvz.org
Reviewed-by: Peter Hornyack peterhorny...@google.com
CC: Paolo Bonzini pbonz...@redhat.com
CC: Gleb Natapov g...@kernel.org
---
include/linux/kvm_host.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 9564fd7..2b2edf1 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -424,6 +424,9 @@ struct kvm {
#define vcpu_unimpl(vcpu, fmt, ...)\
kvm_pr_unimpl(vcpu%i fmt, (vcpu)-vcpu_id, ## __VA_ARGS__)
+#define vcpu_debug(vcpu, fmt, ...) \
+ kvm_debug(vcpu%i fmt, (vcpu)-vcpu_id, ## __VA_ARGS__)
+
static inline struct kvm_vcpu *kvm_get_vcpu(struct kvm *kvm, int i)
{
smp_rmb();
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/12] kvm/x86: added hyper-v crash data and ctl msr's get/set'ers
From: Andrey Smetanin asmeta...@virtuozzo.com
Added hyper-v crash msr's(HV_X64_MSR_CRASH*) data and control
geters and setters. Userspace should check that such msr's
available by check of KVM_CAP_HYPERV_MSR_CRASH capability.
User space allowed to setup Hyper-V crash ctl msr.
This msr should be setup to HV_X64_MSR_CRASH_CTL_NOTIFY
value so Hyper-V guest knows it can send crash data to host.
But Hyper-V guest notifies about crash event by writing
the same HV_X64_MSR_CRASH_CTL_NOTIFY value into crash ctl msr.
So both user space and guest writes inside ctl msr the same value
and this patch distingiush the moment of actual guest crash
by checking host initiated value from msr info. Also patch
prevents modification of crash ctl msr by guest.
Signed-off-by: Andrey Smetanin asmeta...@virtuozzo.com
Signed-off-by: Denis V. Lunev d...@openvz.org
Reviewed-by: Peter Hornyack peterhorny...@google.com
CC: Paolo Bonzini pbonz...@redhat.com
CC: Gleb Natapov g...@kernel.org
---
arch/x86/kvm/hyperv.c | 74 ---
arch/x86/kvm/hyperv.h | 2 +-
arch/x86/kvm/x86.c| 9 ++-
3 files changed, 80 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
index af83c96..a8160d2 100644
--- a/arch/x86/kvm/hyperv.c
+++ b/arch/x86/kvm/hyperv.c
@@ -48,7 +48,63 @@ static bool kvm_hv_msr_partition_wide(u32 msr)
return r;
}
-static int kvm_hv_set_msr_pw(struct kvm_vcpu *vcpu, u32 msr, u64 data)
+static int kvm_hv_msr_get_crash_data(struct kvm_vcpu *vcpu,
+u32 index, u64 *pdata)
+{
+ struct kvm_hv *hv = vcpu-kvm-arch.hyperv;
+
+ if (WARN_ON_ONCE(index = ARRAY_SIZE(hv-hv_crash_param)))
+ return -EINVAL;
+
+ *pdata = hv-hv_crash_param[index];
+ return 0;
+}
+
+static int kvm_hv_msr_get_crash_ctl(struct kvm_vcpu *vcpu, u64 *pdata)
+{
+ struct kvm_hv *hv = vcpu-kvm-arch.hyperv;
+
+ *pdata = hv-hv_crash_ctl;
+ return 0;
+}
+
+static int kvm_hv_msr_set_crash_ctl(struct kvm_vcpu *vcpu, u64 data, bool host)
+{
+ struct kvm_hv *hv = vcpu-kvm-arch.hyperv;
+
+ if (host)
+ hv-hv_crash_ctl = data HV_X64_MSR_CRASH_CTL_NOTIFY;
+
+ if (!host (data HV_X64_MSR_CRASH_CTL_NOTIFY)) {
+
+ vcpu_debug(vcpu, hv crash (0x%llx 0x%llx 0x%llx 0x%llx
0x%llx)\n,
+ hv-hv_crash_param[0],
+ hv-hv_crash_param[1],
+ hv-hv_crash_param[2],
+ hv-hv_crash_param[3],
+ hv-hv_crash_param[4]);
+
+ /* Send notification about crash to user space */
+ kvm_make_request(KVM_REQ_HV_CRASH, vcpu);
+ }
+
+ return 0;
+}
+
+static int kvm_hv_msr_set_crash_data(struct kvm_vcpu *vcpu,
+u32 index, u64 data)
+{
+ struct kvm_hv *hv = vcpu-kvm-arch.hyperv;
+
+ if (WARN_ON_ONCE(index = ARRAY_SIZE(hv-hv_crash_param)))
+ return -EINVAL;
+
+ hv-hv_crash_param[index] = data;
+ return 0;
+}
+
+static int kvm_hv_set_msr_pw(struct kvm_vcpu *vcpu, u32 msr, u64 data,
+bool host)
{
struct kvm *kvm = vcpu-kvm;
struct kvm_hv *hv = kvm-arch.hyperv;
@@ -101,6 +157,12 @@ static int kvm_hv_set_msr_pw(struct kvm_vcpu *vcpu, u32
msr, u64 data)
mark_page_dirty(kvm, gfn);
break;
}
+ case HV_X64_MSR_CRASH_P0 ... HV_X64_MSR_CRASH_P4:
+ return kvm_hv_msr_set_crash_data(vcpu,
+msr - HV_X64_MSR_CRASH_P0,
+data);
+ case HV_X64_MSR_CRASH_CTL:
+ return kvm_hv_msr_set_crash_ctl(vcpu, data, host);
default:
vcpu_unimpl(vcpu, Hyper-V uhandled wrmsr: 0x%x data 0x%llx\n,
msr, data);
@@ -173,6 +235,12 @@ static int kvm_hv_get_msr_pw(struct kvm_vcpu *vcpu, u32
msr, u64 *pdata)
case HV_X64_MSR_REFERENCE_TSC:
data = hv-hv_tsc_page;
break;
+ case HV_X64_MSR_CRASH_P0 ... HV_X64_MSR_CRASH_P4:
+ return kvm_hv_msr_get_crash_data(vcpu,
+msr - HV_X64_MSR_CRASH_P0,
+pdata);
+ case HV_X64_MSR_CRASH_CTL:
+ return kvm_hv_msr_get_crash_ctl(vcpu, pdata);
default:
vcpu_unimpl(vcpu, Hyper-V unhandled rdmsr: 0x%x\n, msr);
return 1;
@@ -217,13 +285,13 @@ static int kvm_hv_get_msr(struct kvm_vcpu *vcpu, u32 msr,
u64 *pdata)
return 0;
}
-int kvm_hv_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data)
+int kvm_hv_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data, bool host)
{
if (kvm_hv_msr_partition_wide(msr)) {
int r;
[PATCH 8/12] kvm/x86: add sending hyper-v crash notification to user space
From: Andrey Smetanin asmeta...@virtuozzo.com
Sending of notification is done by exiting vcpu to user space
if KVM_REQ_HV_CRASH is enabled for vcpu. At exit to user space
the kvm_run structure contains system_event with type
KVM_SYSTEM_EVENT_CRASH to notify about guest crash occurred.
Signed-off-by: Andrey Smetanin asmeta...@virtuozzo.com
Signed-off-by: Denis V. Lunev d...@openvz.org
Reviewed-by: Peter Hornyack peterhorny...@google.com
CC: Paolo Bonzini pbonz...@redhat.com
CC: Gleb Natapov g...@kernel.org
---
Documentation/virtual/kvm/api.txt | 5 +
arch/x86/kvm/x86.c| 6 ++
include/uapi/linux/kvm.h | 1 +
3 files changed, 12 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index a7926a9..a4ebcb7 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -3277,6 +3277,7 @@ should put the acknowledged interrupt vector into the
'epr' field.
struct {
#define KVM_SYSTEM_EVENT_SHUTDOWN 1
#define KVM_SYSTEM_EVENT_RESET 2
+#define KVM_SYSTEM_EVENT_CRASH 3
__u32 type;
__u64 flags;
} system_event;
@@ -3296,6 +3297,10 @@ Valid values for 'type' are:
KVM_SYSTEM_EVENT_RESET -- the guest has requested a reset of the VM.
As with SHUTDOWN, userspace can choose to ignore the request, or
to schedule the reset to occur in the future and may call KVM_RUN again.
+ KVM_SYSTEM_EVENT_CRASH -- the guest crash occurred and the guest
+ has requested a crash condition maintenance. Userspace can choose
+ to ignore the request, or to gather VM memory core dump and/or
+ reset/shutdown of the VM.
/* Fix the size of the union. */
char padding[256];
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index ceec9bf..4d71b8f 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6266,6 +6266,12 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
vcpu_scan_ioapic(vcpu);
if (kvm_check_request(KVM_REQ_APIC_PAGE_RELOAD, vcpu))
kvm_vcpu_reload_apic_access_page(vcpu);
+ if (kvm_check_request(KVM_REQ_HV_CRASH, vcpu)) {
+ vcpu-run-exit_reason = KVM_EXIT_SYSTEM_EVENT;
+ vcpu-run-system_event.type = KVM_SYSTEM_EVENT_CRASH;
+ r = 0;
+ goto out;
+ }
}
if (kvm_check_request(KVM_REQ_EVENT, vcpu) || req_int_win) {
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 716ad4a..9ef19eb 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -317,6 +317,7 @@ struct kvm_run {
struct {
#define KVM_SYSTEM_EVENT_SHUTDOWN 1
#define KVM_SYSTEM_EVENT_RESET 2
+#define KVM_SYSTEM_EVENT_CRASH 3
__u32 type;
__u64 flags;
} system_event;
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 08/17] kvm: arm/arm64: implement kvm_arm_[halt,resume]_guest
On 03/07/15 12:55, Eric Auger wrote: Christoffer, Marc, On 07/02/2015 03:17 PM, Eric Auger wrote: On halt, the guest is forced to exit and prevented from being re-entered. This is synchronous. Those two operations will be needed for IRQ forwarding setting. Signed-off-by: Eric Auger eric.au...@linaro.org would you agree to handle this ARM functionality separately from the forwarding series? This includes 2 patch files, that one + https://lkml.org/lkml/2015/7/2/288. This functionality is needed for forwarding control since when changing the forwarding state we need to freeze the state of the physical/virtual IRQ to undertake proper actions. Stopping the guest makes sure it won't deactivate the virtual IRQ while we are doing state change actions. The forwarding series is quite heterogeneous (VFIO platform driver, vgic, irq bypass manager) and I think it would simplify the review process. Please let me know if you agree. If yes, I will post a separate series. I don't mind, I trust you to do what's best for these series to be easily reviewed (if that is at all possible). The only thing is that this patch implements a feature that will otherwise be unused, so annotating the functions with __maybe_unused would avoid warnings. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
