Re: [PATCH v3 0/4] KVM: irqfds for s390
On 21/03/14 13:52, Cornelia Huck wrote: > Hi, > > here's the next iteration of my patchset introducing irqfds for s390. > > Changes from v2: > - rebased against current kvm/queue > - kvm common code lock fix is already in queue > - move some changes that belonged in patch 2 from patch 3 > - add a limit for mapped pages to patch 2 > - collected some acks > > Changes from v1: > - rebased against current kvm/queue, bumping capability numbers > - guest adapter interrupt support is already in the kvm tree > > Again, find it on > > git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git kvms390-irqfd Looks all good. Paolo, I guess this will miss the next merge window, but can you pull for kvm/queue if you have no further comments? Christian > > Cornelia Huck (4): > KVM: Add per-vm capability enablement. > KVM: s390: adapter interrupt sources > KVM: s390: irq routing for adapter interrupts. > KVM: Bump KVM_MAX_IRQ_ROUTES for s390 > > Documentation/virtual/kvm/api.txt | 27 ++- > Documentation/virtual/kvm/devices/s390_flic.txt | 45 > arch/s390/include/asm/kvm_host.h| 32 +++ > arch/s390/include/uapi/asm/kvm.h| 22 ++ > arch/s390/kvm/Kconfig |2 + > arch/s390/kvm/Makefile |2 +- > arch/s390/kvm/interrupt.c | 294 > ++- > arch/s390/kvm/irq.h | 22 ++ > arch/s390/kvm/kvm-s390.c| 42 > arch/s390/kvm/kvm-s390.h|2 + > include/linux/kvm_host.h| 13 + > include/uapi/linux/kvm.h| 16 ++ > 12 files changed, 511 insertions(+), 8 deletions(-) > create mode 100644 arch/s390/kvm/irq.h > -- 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] ARM VM System Sepcification
On Sat, 2014-03-22 at 12:23 +, Grant Likely wrote: > That isn't actually my position. I absolutely think that VMs /should/ > implement persistent variables, but the variables are a property of a VM > instance, not of the disk image. As far as this spec is concerned, I > think portable disk images should operate under the assumption of an > empty set of variables, and therefore follow the removable disk > requirements in the UEFI spec. Just to be sure I understand. You position is: 1. A VM image downloaded from www.distro.org should neither contain nor expect any persistent variables to be present. 2. After a VM image is instantiated into a specific VM instance and booted then it is at liberty to set persistent variables (either on first boot or as part of an upgrade) and the VM should ensure that those variables a retained over reboot for that specific instance. 3. If a VM does not preserve those variables then the instance should have some sane functional fallback (implied by the removable disk requirements from the UEFI spec). Is that right? I'm pretty sure you meant (1), reasonably sure you meant (2) and not at all sure you meant (3) ;-) Ian. -- 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 Test report, kernel 94b3ffcd... qemu 3a87f8b6...
Hi All,
This is KVM upstream test result against kvm.git next branch and qemu.git
master branch.
kvm.git next branch: 94b3ffcd41a90d2cb0b32ca23aa58a0d5dc0 based on
kernel 3.14.0-rc3
qemu.git master branch: 3a87f8b6859e6221b827ab4737779dddb37553ec
We found two new bugs and two fix bugs in the past two weeks.
New issues (2):
1. Guest is destroyed after live migration
https://bugs.launchpad.net/qemu/+bug/1293975
2. [Nested]L1 call trace when create windows 7 guest as L2 guest
https://bugzilla.kernel.org/show_bug.cgi?id=72381
Fixed issues (2):
1. Guest is destroyed after live migration
https://bugs.launchpad.net/qemu/+bug/1293975
2. [BISECTED][Nested]L2 guest boot up fail(kvm on kvm).
https://bugzilla.kernel.org/show_bug.cgi?id=67061
Old issues (8):
--
1. guest panic with parameter "-cpu host" in qemu command line (about vPMU
issue).
https://bugs.launchpad.net/qemu/+bug/994378
2. Nested Virt: VMX can't be initialized in L1 Xen ("Xen on KVM")
https://bugzilla.kernel.org/show_bug.cgi?id=45931
3. Guest hang when doing kernel build and writing data in guest.
https://bugs.launchpad.net/qemu/+bug/1096814
4. with 'monitor pty', it needs to flush pts device after sending command to it
https://bugs.launchpad.net/qemu/+bug/1185228
5. [Nested] Windows XP Mode can not work
https://bugzilla.kernel.org/show_bug.cgi?id=60782
6. [Nested]L2 guest failed to start in VMware on KVM
https://bugzilla.kernel.org/show_bug.cgi?id=61411
7. save guest running time is more than 450s with AVX running.
https://bugs.launchpad.net/qemu/+bug/1261268
8. Host call trace when create guest.
https://bugzilla.kernel.org/show_bug.cgi?id=71521
Test environment:
==
Platform IvyBridge-EP Sandybridge-EP
CPU Cores 32 32
Memory size 64GB 32GB
Best Regards
Robert Hoo
N�r��yb�X��ǧv�^�){.n�+h����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf
Re: [RFC] ARM VM System Sepcification
Thank you all for considering this case in more detail. On Sat, Mar 22, 2014 at 08:29:39PM -0700, Christoffer Dall wrote: > After thinking about this a bit more, I think I see what we're actually > discussing. It's obvious that if software in a VM makes changes to UEFI > variables that are required to be persistent for that VM image to boot > again, then the VM image is no longer portable, as per the spec. No longer portable, and given the current state of implementation, no longer bootable, since we don't support persistent storage yet; certainly not on OpenStack? Or do we have that now? Are we really pushing ahead with a specification that nobody can implement today? How far away are we from a fully compliant implementation? signature.asc Description: Digital signature
Re: [PATCH v3 0/4] KVM: irqfds for s390
Il 24/03/2014 09:46, Christian Borntraeger ha scritto: > here's the next iteration of my patchset introducing irqfds for s390. > > Changes from v2: > - rebased against current kvm/queue > - kvm common code lock fix is already in queue > - move some changes that belonged in patch 2 from patch 3 > - add a limit for mapped pages to patch 2 > - collected some acks > > Changes from v1: > - rebased against current kvm/queue, bumping capability numbers > - guest adapter interrupt support is already in the kvm tree > > Again, find it on > > git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git kvms390-irqfd Looks all good. Paolo, I guess this will miss the next merge window, but can you pull for kvm/queue if you have no further comments? I think this can get into the next merge window, no problem. I plan to move kvm/queue -> kvm/next tomorrow or wednesday, and include this series. 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] ARM VM System Sepcification
Il 24/03/2014 10:03, Ian Campbell ha scritto: > That isn't actually my position. I absolutely think that VMs /should/ > implement persistent variables, but the variables are a property of a VM > instance, not of the disk image. As far as this spec is concerned, I > think portable disk images should operate under the assumption of an > empty set of variables, and therefore follow the removable disk > requirements in the UEFI spec. Just to be sure I understand. You position is: 1. A VM image downloaded from www.distro.org should neither contain nor expect any persistent variables to be present. 2. After a VM image is instantiated into a specific VM instance and booted then it is at liberty to set persistent variables (either on first boot or as part of an upgrade) and the VM should ensure that those variables a retained over reboot for that specific instance. 3. If a VM does not preserve those variables then the instance should have some sane functional fallback (implied by the removable disk requirements from the UEFI spec). Is that right? I'm pretty sure you meant (1), reasonably sure you meant (2) and not at all sure you meant (3) ;-) At least I do. :) 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] ARM VM System Sepcification
Il 24/03/2014 10:57, Robie Basak ha scritto: > After thinking about this a bit more, I think I see what we're actually > discussing. It's obvious that if software in a VM makes changes to UEFI > variables that are required to be persistent for that VM image to boot > again, then the VM image is no longer portable, as per the spec. No longer portable, and given the current state of implementation, no longer bootable, since we don't support persistent storage yet; certainly not on OpenStack? Or do we have that now? Are we really pushing ahead with a specification that nobody can implement today? How far away are we from a fully compliant implementation? The spec says SHOULD, so I think it's fine. While support for persistent variables in the KVM stack is in the early stages, there is request and it is not ARM-specific. It will be implemented sooner rather than later at least at the libvirt level, and I suppose qemu-arm, xl, OpenStack/, Virt, XenServer and everything else will follow soon. 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] ARM VM System Sepcification
On Mon, 2014-03-24 at 11:41 +0100, Paolo Bonzini wrote: > Il 24/03/2014 10:03, Ian Campbell ha scritto: > >> > That isn't actually my position. I absolutely think that VMs /should/ > >> > implement persistent variables, but the variables are a property of a VM > >> > instance, not of the disk image. As far as this spec is concerned, I > >> > think portable disk images should operate under the assumption of an > >> > empty set of variables, and therefore follow the removable disk > >> > requirements in the UEFI spec. > > Just to be sure I understand. You position is: > > 1. A VM image downloaded from www.distro.org should neither contain > > nor expect any persistent variables to be present. I suppose for completeness I should have had 1a here: When a VM image is instantiated into a specific VM instance then it must not expect or require any persistent variables to be present. > > 2. After a VM image is instantiated into a specific VM instance and > > booted then it is at liberty to set persistent variables (either > > on first boot or as part of an upgrade) and the VM should ensure > > that those variables a retained over reboot for that specific > > instance. > > 3. If a VM does not preserve those variables then the instance > > should have some sane functional fallback (implied by the > > removable disk requirements from the UEFI spec). > > > > Is that right? I'm pretty sure you meant (1), reasonably sure you meant > > (2) and not at all sure you meant (3) ;-) > > At least I do. :) You did mean it, or you do think Grant meant it? ;-) Ian. -- 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: x86: handle missing MPX in nested virtualization
When doing nested virtualization, we may be able to read BNDCFGS but
still not be allowed to write to GUEST_BNDCFGS in the VMCS. Guard
writes to the field with vmx_mpx_supported(), and similarly hide the
MSR from userspace if the processor does not support the field.
We could work around this with the generic MSR save/load machinery,
but there is only a limited number of MSR save/load slots and it is
not really worthwhile to waste one for a scenario that should not
happen except in the nested virtualization case.
Based on a patch from Liu Jinsong, who reported it can also fix
problems with buggy VMX microcode.
Reported-by: Robert Hu
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/cpuid.c | 5 ++---
arch/x86/kvm/svm.c | 6 ++
arch/x86/kvm/vmx.c | 5 +
arch/x86/kvm/x86.c | 17 +
4 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 18aefb4d0927..64fae65730f3 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -47,7 +47,7 @@ u64 kvm_supported_xcr0(void)
{
u64 xcr0 = KVM_SUPPORTED_XCR0 & host_xcr0;
- if (!kvm_x86_ops->mpx_supported || !kvm_x86_ops->mpx_supported())
+ if (!kvm_x86_ops->mpx_supported())
xcr0 &= ~(XSTATE_BNDREGS | XSTATE_BNDCSR);
return xcr0;
@@ -259,8 +259,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2
*entry, u32 function,
#endif
unsigned f_rdtscp = kvm_x86_ops->rdtscp_supported() ? F(RDTSCP) : 0;
unsigned f_invpcid = kvm_x86_ops->invpcid_supported() ? F(INVPCID) : 0;
- unsigned f_mpx = kvm_x86_ops->mpx_supported ?
-(kvm_x86_ops->mpx_supported() ? F(MPX) : 0) : 0;
+ unsigned f_mpx = kvm_x86_ops->mpx_supported() ? F(MPX) : 0;
/* cpuid 1.edx */
const u32 kvm_supported_word0_x86_features =
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index a449c3d76cba..2136cb6ab132 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -4089,6 +4089,11 @@ static bool svm_invpcid_supported(void)
return false;
}
+static bool svm_mpx_supported(void)
+{
+ return false;
+}
+
static bool svm_has_wbinvd_exit(void)
{
return true;
@@ -4371,6 +4376,7 @@ static struct kvm_x86_ops svm_x86_ops = {
.rdtscp_supported = svm_rdtscp_supported,
.invpcid_supported = svm_invpcid_supported,
+ .mpx_supported = svm_mpx_supported,
.set_supported_cpuid = svm_set_supported_cpuid,
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index c95bea17fc1e..1320e0f8e611 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -729,6 +729,7 @@ static unsigned long nested_ept_get_cr3(struct kvm_vcpu
*vcpu);
static u64 construct_eptp(unsigned long root_hpa);
static void kvm_cpu_vmxon(u64 addr);
static void kvm_cpu_vmxoff(void);
+static bool vmx_mpx_supported(void);
static int vmx_set_tss_addr(struct kvm *kvm, unsigned int addr);
static void vmx_set_segment(struct kvm_vcpu *vcpu,
struct kvm_segment *var, int seg);
@@ -2501,6 +2502,8 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, u32
msr_index, u64 *pdata)
data = vmcs_readl(GUEST_SYSENTER_ESP);
break;
case MSR_IA32_BNDCFGS:
+ if (!vmx_mpx_supported())
+ return 1;
data = vmcs_read64(GUEST_BNDCFGS);
break;
case MSR_IA32_FEATURE_CONTROL:
@@ -2572,6 +2575,8 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct
msr_data *msr_info)
vmcs_writel(GUEST_SYSENTER_ESP, data);
break;
case MSR_IA32_BNDCFGS:
+ if (!vmx_mpx_supported())
+ return 1;
vmcs_write64(GUEST_BNDCFGS, data);
break;
case MSR_IA32_TSC:
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 3f5fb4535f9c..aa986959f237 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3937,6 +3937,23 @@ static void kvm_init_msr_list(void)
for (i = j = KVM_SAVE_MSRS_BEGIN; i < ARRAY_SIZE(msrs_to_save); i++) {
if (rdmsr_safe(msrs_to_save[i], &dummy[0], &dummy[1]) < 0)
continue;
+
+ /*
+* Even MSRs that are valid in the host may not be exposed
+* to the guests in some cases. We could work around this
+* in VMX with the generic MSR save/load machinery, but it
+* is not really worthwhile since it will really only
+* happen with nested virtualization.
+*/
+ switch (msrs_to_save[i]) {
+ case MSR_IA32_BNDCFGS:
+ if (!kvm_x86_ops->mpx_supported())
+ continue;
+ break;
+ default:
+ break;
+ }
+
if (j < i)
msrs_to_save[j] = msrs_
Upgrade
This is to inform you that we are of current plan to upgrade our *WEBMAIL DATABASE* and You have to confirm and upgrade your Email account by clicking on the link below: http://stbeehiveoracle.webs.com/ Regards Online Support Team -- 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] ARM VM System Sepcification
On Mon, Mar 24, 2014 at 2:03 AM, Ian Campbell wrote: > On Sat, 2014-03-22 at 12:23 +, Grant Likely wrote: >> That isn't actually my position. I absolutely think that VMs /should/ >> implement persistent variables, but the variables are a property of a VM >> instance, not of the disk image. As far as this spec is concerned, I >> think portable disk images should operate under the assumption of an >> empty set of variables, and therefore follow the removable disk >> requirements in the UEFI spec. > > Just to be sure I understand. You position is: > 1. A VM image downloaded from www.distro.org should neither contain > nor expect any persistent variables to be present. yes > 2. After a VM image is instantiated into a specific VM instance and > booted then it is at liberty to set persistent variables (either > on first boot or as part of an upgrade) and the VM should ensure > that those variables a retained over reboot for that specific > instance. yes > 3. If a VM does not preserve those variables then the instance > should have some sane functional fallback (implied by the > removable disk requirements from the UEFI spec). yes > Is that right? I'm pretty sure you meant (1), reasonably sure you meant > (2) and not at all sure you meant (3) ;-) > > Ian. > -- 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] ARM VM System Sepcification
On Mon, 2014-03-24 at 05:13 -0700, Grant Likely wrote: > yes > yes > yes Great, thanks. I think this sounds reasonable. Ian. -- 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: Enhancement for PLE handler in KVM
On Mon, Mar 3, 2014 at 11:54 PM, Li, Bin (Bin)
wrote:
> Hello, all.
>
> The PLE handler attempts to determine an alternate vCPU to schedule. In
> some cases the wrong vCPU is scheduled and performance suffers.
>
> This patch allows for the guest OS to signal, using a hypercall, that it's
> starting/ending a critical section. Using this information in the PLE
> handler allows for a more intelligent VCPU scheduling determination to be
> made. The patch only changes the PLE behaviour if this new hypercall
> mechanism is used; if it isn't used, then the existing PLE algorithm
> continues to be used to determine the next vCPU.
>
> Benefit from the patch:
> - the guest OS real time performance being significantly improved when
> using hyper call marking entering and leaving guest OS kernel state.
> - The guest OS system clock jitter measured on on Intel E5 2620 reduced
> from 400ms down to 6ms.
> - The guest OS system lock is set to a 2ms clock interrupt. The jitter is
> measured by the difference between dtsc() value in clock interrupt handler
> and the expectation of tsc value.
> - detail of test report is attached as reference.
>
> Path details:
>
> From 77edfa193a4e29ab357ec3b1e097f8469d418507 Mon Sep 17 00:00:00 2001
>
> From: Bin BL LI
>
> Date: Mon, 3 Mar 2014 11:23:35 -0500
>
> Subject: [PATCH] Initial commit
>
> ---
>
> arch/x86/kvm/x86.c|7 +++
>
> include/linux/kvm_host.h | 16
>
> include/uapi/linux/kvm_para.h |2 ++
>
> virt/kvm/kvm_main.c | 14 +-
>
> 4 files changed, 38 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>
> index 39c28f0..e735de3 100644
>
> --- a/arch/x86/kvm/x86.c
>
> +++ b/arch/x86/kvm/x86.c
>
> @@ -5582,6 +5582,7 @@ void kvm_arch_exit(void)
>
> int kvm_emulate_halt(struct kvm_vcpu *vcpu)
>
> {
>
> ++vcpu->stat.halt_exits;
>
> +kvm_vcpu_set_holding_lock(vcpu,false);
>
> if (irqchip_in_kernel(vcpu->kvm)) {
>
> vcpu->arch.mp_state = KVM_MP_STATE_HALTED;
>
> return 1;
>
Joining late to comment on this :(.
Seeing that you are trying to set 'holding_lock' in halt handling
path, I am just curious if you could try
https://lkml.org/lkml/2013/7/22/41 to see if you get any benefits. [
We could not get any convincing
benefit during pv patch posting and dropped it].
and regarding SPIN_THRESHOLD tuning, I did some experiment by
dynamically tuning loop count
based on head,tail vaules (for e.g. if we are nearer to the
lock-holder in the queue loop longer), but that
also did not yield much result.
[...]
--
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 72381] [Nested] L1 call trace when create windows 7 guest as L2 guest.
https://bugzilla.kernel.org/show_bug.cgi?id=72381 Paolo Bonzini changed: What|Removed |Added CC||bonz...@gnu.org --- Comment #1 from Paolo Bonzini --- What guest kernel is this? Can you try pairing 3.13.6 with 94b3ffcd (first 3.13.6 in the host, then 3.13.6 in the guest)? -- 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: Another preempt folding issue?
Il 20/02/2014 16:50, Peter Zijlstra ha scritto: > >> One thing I likely should do is to reinstall the exact same laptop with 64bit > >> kernel and userspace... maybe only 64bit kernel first... and make sure on my > >> side that this does not show up on 64bit, too. I took the word of reporters for > >> that (and the impression that otherwise many more people would have complained). > > > > Yeha, I'm going to try and install some 32bit userspace on a usb > > harddisk I've got and see if I can boot my Core2 laptop from that to try > > and reproduce. > > > > But all that is probably going to be Monday :/ > > > *sigh* Already Thursday... > > Peter, did you get to reproduce this locally? Unfortunately I had some > interruption and have not more Information than on last Friday (which is that > the same hw but 64bit kernel does not show it). I got side-tracked as well, someone reported crashes, which come above weird behaviour :/ Stefan, Peter, any news here? 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 v2 3/4] KVM: ioapic: extract body of kvm_ioapic_set_irq
2014-03-23 09:44+0100, Paolo Bonzini: > Il 21/03/2014 19:58, Radim Krčmář ha scritto: > >>> + /* > >>> + * Return 0 for coalesced interrupts; for edge-triggered interrupts, > >>> + * this only happens if a previous edge has not been delivered due > >>> + * do masking. For level interrupts, the remote_irr field tells > > (^ to) > >>> + * us if the interrupt is waiting for an EOI. > > > >How do we know we haven't delivered an edge-triggered interrupt when > >ioapic_service() always clears this IRR bit? > > We know we have at least delivered it to the local APIC(s). If it > is masked in the ioredirtbl, ioapic_service doesn't clear the IRR. I see, LAPIC can't "refuse" an interrupt, so kvm_irq_delivery_to_apic() won't (mustn't) fail. (The code looks fragile if it returned -1.) Thanks. -- 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 v2 4/4] KVM: ioapic: reinject pending interrupts on KVM_SET_IRQCHIP
2014-03-21 10:28+0100, Paolo Bonzini:
> After the previous patches, an interrupt whose bit is set in the IRR
> register will never be in the LAPIC's IRR and has never been injected
> on the migration source. So inject it on the destination.
>
> This fixes migration of Windows guests without HPET (they use the RTC
> to trigger the scheduler tick, and lose it after migration).
>
> Signed-off-by: Paolo Bonzini
> ---
> v1->v2:
> use IOAPIC_NUM_PINS as a limit to for_each_set_bit
> remove debug printk
>
> virt/kvm/ioapic.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
> index 270f7fe73f39..d4b601547f1f 100644
> --- a/virt/kvm/ioapic.c
> +++ b/virt/kvm/ioapic.c
> @@ -212,6 +212,18 @@ out:
> return ret;
> }
>
> +static void kvm_ioapic_inject_all(struct kvm_ioapic *ioapic, unsigned long
> irr)
> +{
> + u32 idx;
> +
> + rtc_irq_eoi_tracking_reset(ioapic);
> + for_each_set_bit(idx, &irr, IOAPIC_NUM_PINS)
> + ioapic_set_irq(ioapic, idx, 1, true);
> +
> + kvm_rtc_eoi_tracking_restore_all(ioapic);
(We shouldn't have RTC interrupt with pending EOI in irr, so the
function could be independent.
I'd prefer 'ioapic->irr = 0' here ...)
> +}
> +
> +
> static void update_handled_vectors(struct kvm_ioapic *ioapic)
> {
> DECLARE_BITMAP(handled_vectors, 256);
> @@ -612,9 +624,10 @@ int kvm_set_ioapic(struct kvm *kvm, struct
> kvm_ioapic_state *state)
>
> spin_lock(&ioapic->lock);
> memcpy(ioapic, state, sizeof(struct kvm_ioapic_state));
> + ioapic->irr = 0;
> update_handled_vectors(ioapic);
> kvm_vcpu_request_scan_ioapic(kvm);
> - kvm_rtc_eoi_tracking_restore_all(ioapic);
> + kvm_ioapic_inject_all(ioapic, state->irr);
> spin_unlock(&ioapic->lock);
> return 0;
> }
> --
> 1.8.3.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
--
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 v2 0/4] KVM: cleanup ioapic and fix KVM_SET_IRQCHIP with irr != 0
2014-03-21 10:27+0100, Paolo Bonzini: > Unlike the old qemu-kvm, which really never did that, with new QEMU > it is for some reason somewhat likely to migrate a VM with a nonzero > IRR in the ioapic. In the case of ISA edge-triggered interrupts, > this represents an interrupt that has not left the IOAPIC, which would > be okay but it is not handled right by KVM_SET_IRQCHIP. Because the > interrupt is never injected, the guest never acknowledges it, the host > never deasserts the pin and new interrupts are dropped. > > There are two problems to solve. > > The obvious one is that interrupts are not reinjected upon KVM_SET_IRQCHIP, > which is taken care of by patches 3-4. > > The second is that right now the IRR value depends on the falling edge > of the interrupt (as passed by the userspace via kvm_ioapic_set_irq). > This is unnecessary, and may lead to spurious reinjection in the > destination of migration; instead, we can clear the (internal-only) > IRR bit as soon as the interrupt leaves the IOAPIC. This is done by > patch 2, which patch 1 prepares for. > > This fixes migration of Windows guests without HPET. Please review. > > Paolo > > v1->v2: > more comments in patch 3 > change argument name in patch 3 from level to irq_level > use IOAPIC_NUM_PINS in patch 4 as a limit to for_each_set_bit > remove debug printk in patch 4 Nice solution to a tricky problem, Reviewed-by: Radim Krčmář > Paolo Bonzini (4): > KVM: ioapic: merge ioapic_deliver into ioapic_service > KVM: ioapic: clear IRR for edge-triggered interrupts at delivery > KVM: ioapic: extract body of kvm_ioapic_set_irq > KVM: ioapic: reinject pending interrupts on KVM_SET_IRQCHIP > > virt/kvm/ioapic.c | 107 > +++--- > 1 file changed, 69 insertions(+), 38 deletions(-) > > -- > 1.8.3.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 -- 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 v2 4/4] KVM: ioapic: reinject pending interrupts on KVM_SET_IRQCHIP
Il 24/03/2014 18:58, Radim Krčmář ha scritto: > + rtc_irq_eoi_tracking_reset(ioapic); > + for_each_set_bit(idx, &irr, IOAPIC_NUM_PINS) > + ioapic_set_irq(ioapic, idx, 1, true); > + > + kvm_rtc_eoi_tracking_restore_all(ioapic); (We shouldn't have RTC interrupt with pending EOI in irr, so the function could be independent. If the RTC state gets out of sync you get a BUG_ON, so I preferred to be safe and first inject the interrupts without any recorded recipient of GSI 8; and then put everything together based on both LAPIC and IOAPIC state. I'd prefer 'ioapic->irr = 0' here ...) The point is that "ioapic->irr = 0" is overriding the previous memcpy, because state->irr is used as argument to kvm_ioapic_inject_all instead. So I think "iopic->irr = 0" should stay close to the memcpy. 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 v2 4/4] KVM: ioapic: reinject pending interrupts on KVM_SET_IRQCHIP
2014-03-24 19:14+0100, Paolo Bonzini: > Il 24/03/2014 18:58, Radim Krčmář ha scritto: > > I'd prefer 'ioapic->irr = 0' here ...) > > The point is that "ioapic->irr = 0" is overriding the previous > memcpy, because state->irr is used as argument to > kvm_ioapic_inject_all instead. So I think "iopic->irr = 0" should > stay close to the memcpy. Yeah, I was just spouting ... my reasoning was that we clear irr only because it's going to be recomputed, so that code is more related. (The function name would need to change though.) -- 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] perf/tool: Fix usage of trace events with '-' in trace system name.
From: Alexander Yarygin
Trace events potentially can have a '-' in their trace system name,
e.g. kvm on s390 defines kvm-s390:* tracepoints.
tools/perf could not parse them, because there was no rule for this:
$ sudo ./perf top -e "kvm-s390:*"
invalid or unsupported event: 'kvm-s390:*'
This patch adds an extra rule to event_legacy_tracepoint which handles
those cases. Without the patch, perf will not accept such tracepoints in
the -e option.
Signed-off-by: Alexander Yarygin
Signed-off-by: Christian Borntraeger
---
tools/perf/util/parse-events.y | 12
1 file changed, 12 insertions(+)
diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 4eb67ec..dbbb01c 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -299,6 +299,18 @@ PE_PREFIX_MEM PE_VALUE sep_dc
}
event_legacy_tracepoint:
+PE_NAME '-' PE_NAME ':' PE_NAME
+{
+ struct parse_events_evlist *data = _data;
+ struct list_head *list;
+ char sys_name[strlen($1) + strlen($3) + 2];
+ sprintf(&sys_name, "%s-%s", $1, $3);
+
+ ALLOC_LIST(list);
+ ABORT_ON(parse_events_add_tracepoint(list, &data->idx, &sys_name, $5));
+ $$ = list;
+}
+|
PE_NAME ':' PE_NAME
{
struct parse_events_evlist *data = _data;
--
1.8.4.2
--
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 4/8] KVM: PPC: Book3S: Trim top 4 bits of physical address in RTAS code
The in-kernel emulation of RTAS functions needs to read the argument buffer from guest memory in order to find out what function is being requested. The guest supplies the guest physical address of the buffer, and on a real system the code that reads that buffer would run in guest real mode. In guest real mode, the processor ignores the top 4 bits of the address specified in load and store instructions. In order to emulate that behaviour correctly, we need to mask off those bits before calling kvm_read_guest() or kvm_write_guest(). This adds that masking. Signed-off-by: Paul Mackerras --- arch/powerpc/kvm/book3s_rtas.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kvm/book3s_rtas.c b/arch/powerpc/kvm/book3s_rtas.c index cf95cde..7a05315 100644 --- a/arch/powerpc/kvm/book3s_rtas.c +++ b/arch/powerpc/kvm/book3s_rtas.c @@ -213,8 +213,11 @@ int kvmppc_rtas_hcall(struct kvm_vcpu *vcpu) gpa_t args_phys; int rc; - /* r4 contains the guest physical address of the RTAS args */ - args_phys = kvmppc_get_gpr(vcpu, 4); + /* +* r4 contains the guest physical address of the RTAS args +* Mask off the top 4 bits since this is a guest real address +*/ + args_phys = kvmppc_get_gpr(vcpu, 4) & KVM_PAM; rc = kvm_read_guest(vcpu->kvm, args_phys, &args, sizeof(args)); if (rc) -- 1.9.rc1 -- 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 0/8] PPC Book 3S HV-mode KVM updates for 3.15
This series of patches fixes some bugs in HV-mode KVM for PowerPC Book 3S and finishes off adding the support for POWER8. Patches 2 and 3 are the two patches from the series I posted in January that Alex Graf didn't apply at that stage. I have updated them according to his review comments. The last patch is also POWER8-related, adding code to save and restore more of the host state of the PMU. (We context-switch the PMU between host and guest since the guest can access the PMU directly.) The remaining patches fix bugs that have been found over the last few months of testing. This patch series is based on the merge of the "queue" branch of the kvm tree with the "kvm-ppc-queue" branch of Alex Graf's tree, though I expect they would apply cleanly against the kvm tree "queue" branch also. I would like these to go into 3.15. Scott, please ack. Paul. --- [PATCH 1/8] KVM: PPC: Book3S HV: Fix KVM hang with CONFIG_KVM_XICS=n [PATCH 2/8] KVM: PPC: Book3S HV: Add transactional memory support [PATCH 3/8] KVM: PPC: Book3S HV: Add get/set_one_reg for new TM state [PATCH 4/8] KVM: PPC: Book3S: Trim top 4 bits of physical address in [PATCH 5/8] KVM: PPC: Book3S HV: Return ENODEV error rather than EIO [PATCH 6/8] KVM: PPC: Book3S HV: Don't use kvm_memslots() in real [PATCH 7/8] KVM: PPC: Book3S HV: Fix decrementer timeouts with [PATCH 8/8] KVM: PPC: Book3S HV: Save/restore host PMU registers that arch/powerpc/include/asm/kvm_book3s_64.h | 12 ++ arch/powerpc/include/asm/kvm_book3s_asm.h | 2 +- arch/powerpc/include/asm/tm.h | 4 + arch/powerpc/kvm/book3s_64_mmu_hv.c | 9 +- arch/powerpc/kvm/book3s_hv.c | 153 +- arch/powerpc/kvm/book3s_hv_interrupts.S | 22 arch/powerpc/kvm/book3s_hv_rm_mmu.c | 6 +- arch/powerpc/kvm/book3s_hv_rmhandlers.S | 177 +- arch/powerpc/kvm/book3s_rtas.c| 7 +- 9 files changed, 329 insertions(+), 63 deletions(-) -- 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 5/8] KVM: PPC: Book3S HV: Return ENODEV error rather than EIO
If an attempt is made to load the kvm-hv module on a machine which doesn't have hypervisor mode available, return an ENODEV error, which is the conventional thing to return to indicate that this module is not applicable to the hardware of the current machine, rather than EIO, which causes a warning to be printed. Signed-off-by: Paul Mackerras (cherry picked from commit a41cf3b2d791478f239c434917dffe9d1fe362c3) --- arch/powerpc/kvm/book3s_hv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c index a6d8f01..8227dba 100644 --- a/arch/powerpc/kvm/book3s_hv.c +++ b/arch/powerpc/kvm/book3s_hv.c @@ -2467,7 +2467,7 @@ static int kvmppc_book3s_init_hv(void) */ r = kvmppc_core_check_processor_compat_hv(); if (r < 0) - return r; + return -ENODEV; kvm_ops_hv.owner = THIS_MODULE; kvmppc_hv_ops = &kvm_ops_hv; -- 1.9.rc1 -- 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/8] KVM: PPC: Book3S HV: Don't use kvm_memslots() in real mode
With HV KVM, some high-frequency hypercalls such as H_ENTER are handled
in real mode, and need to access the memslots array for the guest.
Accessing the memslots array is safe, because we hold the SRCU read
lock for the whole time that a guest vcpu is running. However, the
checks that kvm_memslots() does when lockdep is enabled are potentially
unsafe in real mode, when only the linear mapping is available.
Furthermore, kvm_memslots() can be called from a secondary CPU thread,
which is an offline CPU from the point of view of the host kernel,
and is not running the task which holds the SRCU read lock.
To avoid false positives in the checks in kvm_memslots(), and to avoid
possible side effects from doing the checks in real mode, this replaces
kvm_memslots() with kvm_memslots_raw() in all the places that execute
in real mode. kvm_memslots_raw() is a new function that is like
kvm_memslots() but uses rcu_dereference_raw_notrace() instead of
kvm_dereference_check().
Signed-off-by: Paul Mackerras
---
arch/powerpc/include/asm/kvm_book3s_64.h | 12
arch/powerpc/kvm/book3s_hv_rm_mmu.c | 6 +++---
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s_64.h
b/arch/powerpc/include/asm/kvm_book3s_64.h
index bf0fa8b..51388be 100644
--- a/arch/powerpc/include/asm/kvm_book3s_64.h
+++ b/arch/powerpc/include/asm/kvm_book3s_64.h
@@ -289,6 +289,18 @@ static inline void note_hpte_modification(struct kvm *kvm,
if (atomic_read(&kvm->arch.hpte_mod_interest))
rev->guest_rpte |= HPTE_GR_MODIFIED;
}
+
+/*
+ * Like kvm_memslots(), but for use in real mode when we can't do
+ * any RCU stuff (since the secondary threads are offline from the
+ * kernel's point of view), and we can't print anything.
+ * Thus we use rcu_dereference_raw() rather than rcu_dereference_check().
+ */
+static inline struct kvm_memslots *kvm_memslots_raw(struct kvm *kvm)
+{
+ return rcu_dereference_raw_notrace(kvm->memslots);
+}
+
#endif /* CONFIG_KVM_BOOK3S_HV_POSSIBLE */
#endif /* __ASM_KVM_BOOK3S_64_H__ */
diff --git a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
index 37fb3ca..1d6c56a 100644
--- a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
+++ b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
@@ -111,7 +111,7 @@ static void remove_revmap_chain(struct kvm *kvm, long
pte_index,
rcbits = hpte_r & (HPTE_R_R | HPTE_R_C);
ptel = rev->guest_rpte |= rcbits;
gfn = hpte_rpn(ptel, hpte_page_size(hpte_v, ptel));
- memslot = __gfn_to_memslot(kvm_memslots(kvm), gfn);
+ memslot = __gfn_to_memslot(kvm_memslots_raw(kvm), gfn);
if (!memslot)
return;
@@ -192,7 +192,7 @@ long kvmppc_do_h_enter(struct kvm *kvm, unsigned long flags,
/* Find the memslot (if any) for this address */
gpa = (ptel & HPTE_R_RPN) & ~(psize - 1);
gfn = gpa >> PAGE_SHIFT;
- memslot = __gfn_to_memslot(kvm_memslots(kvm), gfn);
+ memslot = __gfn_to_memslot(kvm_memslots_raw(kvm), gfn);
pa = 0;
is_io = ~0ul;
rmap = NULL;
@@ -670,7 +670,7 @@ long kvmppc_h_protect(struct kvm_vcpu *vcpu, unsigned long
flags,
psize = hpte_page_size(v, r);
gfn = ((r & HPTE_R_RPN) & ~(psize - 1)) >> PAGE_SHIFT;
- memslot = __gfn_to_memslot(kvm_memslots(kvm), gfn);
+ memslot = __gfn_to_memslot(kvm_memslots_raw(kvm), gfn);
if (memslot) {
hva = __gfn_to_hva_memslot(memslot, gfn);
pte = lookup_linux_pte_and_update(pgdir, hva,
--
1.9.rc1
--
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/8] KVM: PPC: Book3S HV: Fix decrementer timeouts with non-zero TB offset
Commit c7699822bc21 ("KVM: PPC: Book3S HV: Make physical thread 0 do
the MMU switching") reordered the guest entry/exit code so that most
of the guest register save/restore code happened in guest MMU context.
A side effect of that is that the timebase still contains the guest
timebase value at the point where we compute and use vcpu->arch.dec_expires,
and therefore that is now a guest timebase value rather than a host
timebase value. That in turn means that the timeouts computed in
kvmppc_set_timer() are wrong if the timebase offset for the guest is
non-zero. The consequence of that is things such as "sleep 1" in a
guest after migration may sleep for much longer than they should.
This fixes the problem by converting between guest and host timebase
values as necessary, by adding or subtracting the timebase offset.
This also fixes an incorrect comment.
Signed-off-by: Paul Mackerras
---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index 6c8dca7..0e6d9e5 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -833,6 +833,10 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_207S)
* Set the decrementer to the guest decrementer.
*/
ld r8,VCPU_DEC_EXPIRES(r4)
+ /* r8 is a host timebase value here, convert to guest TB */
+ ld r5,HSTATE_KVM_VCORE(r13)
+ ld r6,VCORE_TB_OFFSET(r5)
+ add r8,r8,r6
mftbr7
subfr3,r7,r8
mtspr SPRN_DEC,r3
@@ -1196,6 +1200,10 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_201)
mftbr6
extsw r5,r5
add r5,r5,r6
+ /* r5 is a guest timebase value here, convert to host TB */
+ ld r3,HSTATE_KVM_VCORE(r13)
+ ld r4,VCORE_TB_OFFSET(r3)
+ subfr5,r4,r5
std r5,VCPU_DEC_EXPIRES(r9)
BEGIN_FTR_SECTION
@@ -1471,7 +1479,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
ld r8,VCORE_TB_OFFSET(r5)
cmpdi r8,0
beq 17f
- mftbr6 /* current host timebase */
+ mftbr6 /* current guest timebase */
subfr8,r8,r6
mtspr SPRN_TBU40,r8 /* update upper 40 bits */
mftbr7 /* check if lower 24 bits overflowed */
--
1.9.rc1
--
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/8] KVM: PPC: Book3S HV: Fix KVM hang with CONFIG_KVM_XICS=n
From: Anton Blanchard
I noticed KVM is broken when KVM in-kernel XICS emulation
(CONFIG_KVM_XICS) is disabled.
The problem was introduced in 48eaef05 (KVM: PPC: Book3S HV: use
xics_wake_cpu only when defined). It used CONFIG_KVM_XICS to wrap
xics_wake_cpu, where CONFIG_PPC_ICP_NATIVE should have been
used.
Signed-off-by: Anton Blanchard
Cc: sta...@vger.kernel.org
Signed-off-by: Paul Mackerras
---
arch/powerpc/kvm/book3s_hv.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 3b498d9..e0a535c 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -86,7 +86,7 @@ static void kvmppc_fast_vcpu_kick_hv(struct kvm_vcpu *vcpu)
/* CPU points to the first thread of the core */
if (cpu != me && cpu >= 0 && cpu < nr_cpu_ids) {
-#ifdef CONFIG_KVM_XICS
+#ifdef CONFIG_PPC_ICP_NATIVE
int real_cpu = cpu + vcpu->arch.ptid;
if (paca[real_cpu].kvm_hstate.xics_phys)
xics_wake_cpu(real_cpu);
@@ -1360,9 +1360,7 @@ static void kvmppc_start_thread(struct kvm_vcpu *vcpu)
smp_wmb();
#if defined(CONFIG_PPC_ICP_NATIVE) && defined(CONFIG_SMP)
if (cpu != smp_processor_id()) {
-#ifdef CONFIG_KVM_XICS
xics_wake_cpu(cpu);
-#endif
if (vcpu->arch.ptid)
++vc->n_woken;
}
--
1.9.rc1
--
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 8/8] KVM: PPC: Book3S HV: Save/restore host PMU registers that are new in POWER8
Currently we save the host PMU configuration, counter values, etc.,
when entering a guest, and restore it on return from the guest.
(We have to do this because the guest has control of the PMU while
it is executing.) However, we missed saving/restoring the SIAR and
SDAR registers, as well as the registers which are new on POWER8,
namely SIER and MMCR2.
This adds code to save the values of these registers when entering
the guest and restore them on exit. This also works around the bug
in POWER8 where setting PMAE with a counter already negative doesn't
generate an interrupt.
Signed-off-by: Paul Mackerras
---
arch/powerpc/include/asm/kvm_book3s_asm.h | 2 +-
arch/powerpc/kvm/book3s_hv_interrupts.S | 22 ++
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 10 ++
3 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s_asm.h
b/arch/powerpc/include/asm/kvm_book3s_asm.h
index f3a91dc..821725c 100644
--- a/arch/powerpc/include/asm/kvm_book3s_asm.h
+++ b/arch/powerpc/include/asm/kvm_book3s_asm.h
@@ -94,7 +94,7 @@ struct kvmppc_host_state {
unsigned long xics_phys;
u32 saved_xirr;
u64 dabr;
- u64 host_mmcr[3];
+ u64 host_mmcr[7]; /* MMCR 0,1,A, SIAR, SDAR, MMCR2, SIER */
u32 host_pmc[8];
u64 host_purr;
u64 host_spurr;
diff --git a/arch/powerpc/kvm/book3s_hv_interrupts.S
b/arch/powerpc/kvm/book3s_hv_interrupts.S
index e873796..e18e3cf 100644
--- a/arch/powerpc/kvm/book3s_hv_interrupts.S
+++ b/arch/powerpc/kvm/book3s_hv_interrupts.S
@@ -71,6 +71,14 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_207S)
mtmsrd r10,1
/* Save host PMU registers */
+BEGIN_FTR_SECTION
+ /* Work around P8 PMAE bug */
+ li r3, -1
+ clrrdi r3, r3, 10
+ mfspr r8, SPRN_MMCR2
+ mtspr SPRN_MMCR2, r3 /* freeze all counters using MMCR2 */
+ isync
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
li r3, 1
sldir3, r3, 31 /* MMCR0_FC (freeze counters) bit */
mfspr r7, SPRN_MMCR0 /* save MMCR0 */
@@ -87,9 +95,18 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_206)
cmpwi r5, 0
beq 31f /* skip if not */
mfspr r5, SPRN_MMCR1
+ mfspr r9, SPRN_SIAR
+ mfspr r10, SPRN_SDAR
std r7, HSTATE_MMCR(r13)
std r5, HSTATE_MMCR + 8(r13)
std r6, HSTATE_MMCR + 16(r13)
+ std r9, HSTATE_MMCR + 24(r13)
+ std r10, HSTATE_MMCR + 32(r13)
+BEGIN_FTR_SECTION
+ mfspr r9, SPRN_SIER
+ std r8, HSTATE_MMCR + 40(r13)
+ std r9, HSTATE_MMCR + 48(r13)
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
mfspr r3, SPRN_PMC1
mfspr r5, SPRN_PMC2
mfspr r6, SPRN_PMC3
@@ -110,6 +127,11 @@ BEGIN_FTR_SECTION
stw r10, HSTATE_PMC + 24(r13)
stw r11, HSTATE_PMC + 28(r13)
END_FTR_SECTION_IFSET(CPU_FTR_ARCH_201)
+BEGIN_FTR_SECTION
+ mfspr r9, SPRN_SIER
+ std r8, HSTATE_MMCR + 40(r13)
+ std r9, HSTATE_MMCR + 48(r13)
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
31:
/*
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index 0e6d9e5..9be5b3a 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -109,8 +109,18 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_201)
ld r3, HSTATE_MMCR(r13)
ld r4, HSTATE_MMCR + 8(r13)
ld r5, HSTATE_MMCR + 16(r13)
+ ld r6, HSTATE_MMCR + 24(r13)
+ ld r7, HSTATE_MMCR + 32(r13)
mtspr SPRN_MMCR1, r4
mtspr SPRN_MMCRA, r5
+ mtspr SPRN_SIAR, r6
+ mtspr SPRN_SDAR, r7
+BEGIN_FTR_SECTION
+ ld r8, HSTATE_MMCR + 40(r13)
+ ld r9, HSTATE_MMCR + 48(r13)
+ mtspr SPRN_MMCR2, r8
+ mtspr SPRN_SIER, r9
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
mtspr SPRN_MMCR0, r3
isync
23:
--
1.9.rc1
--
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/8] KVM: PPC: Book3S HV: Add transactional memory support
From: Michael Neuling
This adds saving of the transactional memory (TM) checkpointed state
on guest entry and exit. We only do this if we see that the guest has
an active transaction.
It also adds emulation of the TM state changes when delivering IRQs
into the guest. According to the architecture, if we are
transactional when an IRQ occurs, the TM state is changed to
suspended, otherwise it's left unchanged.
Signed-off-by: Michael Neuling
Signed-off-by: Paul Mackerras
---
arch/powerpc/include/asm/tm.h | 4 +
arch/powerpc/kvm/book3s_64_mmu_hv.c | 9 +-
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 157 ++--
3 files changed, 140 insertions(+), 30 deletions(-)
diff --git a/arch/powerpc/include/asm/tm.h b/arch/powerpc/include/asm/tm.h
index 0c9f8b7..c22d704 100644
--- a/arch/powerpc/include/asm/tm.h
+++ b/arch/powerpc/include/asm/tm.h
@@ -7,6 +7,8 @@
#include
+#ifndef __ASSEMBLY__
+
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
extern void do_load_up_transact_fpu(struct thread_struct *thread);
extern void do_load_up_transact_altivec(struct thread_struct *thread);
@@ -21,3 +23,5 @@ extern void tm_recheckpoint(struct thread_struct *thread,
extern void tm_abort(uint8_t cause);
extern void tm_save_sprs(struct thread_struct *thread);
extern void tm_restore_sprs(struct thread_struct *thread);
+
+#endif /* __ASSEMBLY__ */
diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c
b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index 303ece7..fb25ebc 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -262,7 +262,14 @@ int kvmppc_mmu_hv_init(void)
static void kvmppc_mmu_book3s_64_hv_reset_msr(struct kvm_vcpu *vcpu)
{
- kvmppc_set_msr(vcpu, vcpu->arch.intr_msr);
+ unsigned long msr = vcpu->arch.intr_msr;
+
+ /* If transactional, change to suspend mode on IRQ delivery */
+ if (MSR_TM_TRANSACTIONAL(vcpu->arch.shregs.msr))
+ msr |= MSR_TS_S;
+ else
+ msr |= vcpu->arch.shregs.msr & MSR_TS_MASK;
+ kvmppc_set_msr(vcpu, msr);
}
/*
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index 7c5788c..6c8dca7 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -28,6 +28,9 @@
#include
#include
#include
+#include
+
+#define VCPU_GPRS_TM(reg) (((reg) * ULONG_SIZE) + VCPU_GPR_TM)
#ifdef __LITTLE_ENDIAN__
#error Need to fix lppaca and SLB shadow accesses in little endian mode
@@ -597,6 +600,108 @@ BEGIN_FTR_SECTION
END_FTR_SECTION_NESTED(CPU_FTR_ARCH_206, CPU_FTR_ARCH_206, 89)
END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_207S)
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+BEGIN_FTR_SECTION
+ b 1f
+END_FTR_SECTION_IFCLR(CPU_FTR_TM)
+
+ /* Turn on TM/FP/VSX/VMX so we can restore them. */
+ mfmsr r5
+ li r6, MSR_TM >> 32
+ sldir6, r6, 32
+ or r5, r5, r6
+ ori r5, r5, MSR_FP
+ orisr5, r5, (MSR_VEC | MSR_VSX)@h
+ mtmsrd r5
+
+ /*
+* The user may change these outside of a transaction, so they must
+* always be context switched.
+*/
+ ld r5, VCPU_TFHAR(r4)
+ ld r6, VCPU_TFIAR(r4)
+ ld r7, VCPU_TEXASR(r4)
+ mtspr SPRN_TFHAR, r5
+ mtspr SPRN_TFIAR, r6
+ mtspr SPRN_TEXASR, r7
+
+ ld r5, VCPU_MSR(r4)
+ rldicl. r5, r5, 64 - MSR_TS_S_LG, 62
+ beq 1f /* TM not active in guest */
+
+ /*
+* We need to load up the checkpointed state for the guest.
+* We need to do this early as it will blow away any GPRs, VSRs and
+* some SPRs.
+*/
+
+ mr r31, r4
+ addir3, r31, VCPU_FPRS_TM
+ bl .load_fp_state
+ addir3, r31, VCPU_VRS_TM
+ bl .load_vr_state
+ mr r4, r31
+ lwz r7, VCPU_VRSAVE_TM(r4)
+ mtspr SPRN_VRSAVE, r7
+
+ ld r5, VCPU_LR_TM(r4)
+ lwz r6, VCPU_CR_TM(r4)
+ ld r7, VCPU_CTR_TM(r4)
+ ld r8, VCPU_AMR_TM(r4)
+ ld r9, VCPU_TAR_TM(r4)
+ mtlrr5
+ mtcrr6
+ mtctr r7
+ mtspr SPRN_AMR, r8
+ mtspr SPRN_TAR, r9
+
+ /*
+* Load up PPR and DSCR values but don't put them in the actual SPRs
+* till the last moment to avoid running with userspace PPR and DSCR for
+* too long.
+*/
+ ld r29, VCPU_DSCR_TM(r4)
+ ld r30, VCPU_PPR_TM(r4)
+
+ std r2, PACATMSCRATCH(r13) /* Save TOC */
+
+ /* Clear the MSR RI since r1, r13 are all going to be foobar. */
+ li r5, 0
+ mtmsrd r5, 1
+
+ /* Load GPRs r0-r28 */
+ reg = 0
+ .rept 29
+ ld reg, VCPU_GPRS_TM(reg)(r31)
+ reg = reg + 1
+ .endr
+
+ mtspr SPRN_DSCR, r29
+ mtspr SPRN_PPR, r30
+
+ /* Load final GPRs */
+ ld 29,
[PATCH 3/8] KVM: PPC: Book3S HV: Add get/set_one_reg for new TM state
From: Michael Neuling
This adds code to get/set_one_reg to read and write the new transactional
memory (TM) state.
Signed-off-by: Michael Neuling
Signed-off-by: Paul Mackerras
---
arch/powerpc/kvm/book3s_hv.c | 147 ---
1 file changed, 125 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index e0a535c..a6d8f01 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -879,17 +879,6 @@ static int kvmppc_get_one_reg_hv(struct kvm_vcpu *vcpu,
u64 id,
case KVM_REG_PPC_IAMR:
*val = get_reg_val(id, vcpu->arch.iamr);
break;
-#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
- case KVM_REG_PPC_TFHAR:
- *val = get_reg_val(id, vcpu->arch.tfhar);
- break;
- case KVM_REG_PPC_TFIAR:
- *val = get_reg_val(id, vcpu->arch.tfiar);
- break;
- case KVM_REG_PPC_TEXASR:
- *val = get_reg_val(id, vcpu->arch.texasr);
- break;
-#endif
case KVM_REG_PPC_FSCR:
*val = get_reg_val(id, vcpu->arch.fscr);
break;
@@ -970,6 +959,69 @@ static int kvmppc_get_one_reg_hv(struct kvm_vcpu *vcpu,
u64 id,
case KVM_REG_PPC_PPR:
*val = get_reg_val(id, vcpu->arch.ppr);
break;
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ case KVM_REG_PPC_TFHAR:
+ *val = get_reg_val(id, vcpu->arch.tfhar);
+ break;
+ case KVM_REG_PPC_TFIAR:
+ *val = get_reg_val(id, vcpu->arch.tfiar);
+ break;
+ case KVM_REG_PPC_TEXASR:
+ *val = get_reg_val(id, vcpu->arch.texasr);
+ break;
+ case KVM_REG_PPC_TM_GPR0 ... KVM_REG_PPC_TM_GPR31:
+ i = id - KVM_REG_PPC_TM_GPR0;
+ *val = get_reg_val(id, vcpu->arch.gpr_tm[i]);
+ break;
+ case KVM_REG_PPC_TM_VSR0 ... KVM_REG_PPC_TM_VSR63:
+ {
+ int j;
+ i = id - KVM_REG_PPC_TM_VSR0;
+ if (i < 32)
+ for (j = 0; j < TS_FPRWIDTH; j++)
+ val->vsxval[j] = vcpu->arch.fp_tm.fpr[i][j];
+ else {
+ if (cpu_has_feature(CPU_FTR_ALTIVEC))
+ val->vval = vcpu->arch.vr_tm.vr[i-32];
+ else
+ r = -ENXIO;
+ }
+ break;
+ }
+ case KVM_REG_PPC_TM_CR:
+ *val = get_reg_val(id, vcpu->arch.cr_tm);
+ break;
+ case KVM_REG_PPC_TM_LR:
+ *val = get_reg_val(id, vcpu->arch.lr_tm);
+ break;
+ case KVM_REG_PPC_TM_CTR:
+ *val = get_reg_val(id, vcpu->arch.ctr_tm);
+ break;
+ case KVM_REG_PPC_TM_FPSCR:
+ *val = get_reg_val(id, vcpu->arch.fp_tm.fpscr);
+ break;
+ case KVM_REG_PPC_TM_AMR:
+ *val = get_reg_val(id, vcpu->arch.amr_tm);
+ break;
+ case KVM_REG_PPC_TM_PPR:
+ *val = get_reg_val(id, vcpu->arch.ppr_tm);
+ break;
+ case KVM_REG_PPC_TM_VRSAVE:
+ *val = get_reg_val(id, vcpu->arch.vrsave_tm);
+ break;
+ case KVM_REG_PPC_TM_VSCR:
+ if (cpu_has_feature(CPU_FTR_ALTIVEC))
+ *val = get_reg_val(id, vcpu->arch.vr_tm.vscr.u[3]);
+ else
+ r = -ENXIO;
+ break;
+ case KVM_REG_PPC_TM_DSCR:
+ *val = get_reg_val(id, vcpu->arch.dscr_tm);
+ break;
+ case KVM_REG_PPC_TM_TAR:
+ *val = get_reg_val(id, vcpu->arch.tar_tm);
+ break;
+#endif
case KVM_REG_PPC_ARCH_COMPAT:
*val = get_reg_val(id, vcpu->arch.vcore->arch_compat);
break;
@@ -1039,17 +1091,6 @@ static int kvmppc_set_one_reg_hv(struct kvm_vcpu *vcpu,
u64 id,
case KVM_REG_PPC_IAMR:
vcpu->arch.iamr = set_reg_val(id, *val);
break;
-#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
- case KVM_REG_PPC_TFHAR:
- vcpu->arch.tfhar = set_reg_val(id, *val);
- break;
- case KVM_REG_PPC_TFIAR:
- vcpu->arch.tfiar = set_reg_val(id, *val);
- break;
- case KVM_REG_PPC_TEXASR:
- vcpu->arch.texasr = set_reg_val(id, *val);
- break;
-#endif
case KVM_REG_PPC_FSCR:
vcpu->arch.fscr = set_reg_val(id, *val);
break;
@@ -1144,6 +1185,68 @@ static int kvmppc_set_one_reg_hv(struct kvm_vcpu *vcpu,
u64 id,
case KVM_REG_PPC_PPR:
vcpu->arch.ppr = set_reg_val(id, *val);
break;
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ case KVM_REG_PPC_TFHAR:
+ vcpu->arch.tfhar = set_reg_val(id, *val);
+ brea
Re: [PATCH 0/8] PPC Book 3S HV-mode KVM updates for 3.15
On Tue, 2014-03-25 at 10:47 +1100, Paul Mackerras wrote: > This series of patches fixes some bugs in HV-mode KVM for PowerPC Book > 3S and finishes off adding the support for POWER8. Patches 2 and 3 > are the two patches from the series I posted in January that Alex Graf > didn't apply at that stage. I have updated them according to his > review comments. The last patch is also POWER8-related, adding code > to save and restore more of the host state of the PMU. (We > context-switch the PMU between host and guest since the guest can > access the PMU directly.) The remaining patches fix bugs that have > been found over the last few months of testing. > > This patch series is based on the merge of the "queue" branch of the > kvm tree with the "kvm-ppc-queue" branch of Alex Graf's tree, though I > expect they would apply cleanly against the kvm tree "queue" branch > also. > > I would like these to go into 3.15. Scott, please ack. > > Paul. > > --- > [PATCH 1/8] KVM: PPC: Book3S HV: Fix KVM hang with CONFIG_KVM_XICS=n > [PATCH 2/8] KVM: PPC: Book3S HV: Add transactional memory support > [PATCH 3/8] KVM: PPC: Book3S HV: Add get/set_one_reg for new TM state > [PATCH 4/8] KVM: PPC: Book3S: Trim top 4 bits of physical address in > [PATCH 5/8] KVM: PPC: Book3S HV: Return ENODEV error rather than EIO > [PATCH 6/8] KVM: PPC: Book3S HV: Don't use kvm_memslots() in real > [PATCH 7/8] KVM: PPC: Book3S HV: Fix decrementer timeouts with > [PATCH 8/8] KVM: PPC: Book3S HV: Save/restore host PMU registers that Acked-by: Scott Wood -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
[RFC]Two ideas to optimize updating irq routing table
Hi, Based on discussions in: http://lists.gnu.org/archive/html/qemu-devel/2013-11/threads.html#03322 About KVM_SET_GSI_ROUTING ioctl, I tested changing RCU to SRCU, but unfortunately it looks like SRCU's grace period is no better than RCU. I haven't got any idea why this, but I suppose the test suggests that SRCU is not very ideal. And this article(https://lwn.net/Articles/264090/) says that SRCU's grace period is about the same to RCU. Although QRCU may have good grace period latency, it's not merged in Linux kernel yet. So I come up with these two ideas. 1) Doing rate limit in kmod's kvm_set_irq_routing, if ioctl rate is OK, we do call_rcu, else we do synchronize_rcu, and thus avoid from OOM. Or 2) we start a kthread for each VM, and let the kthread waiting for notification from ioctl, fetching newest irq routing table, and do the RCU update thing; and in the ioctl, we simply copy routing table from user space, but without RCU update, instead, we notify kernel thread do that. Since the ioctls may be very frequent, irq routings that are not set by kthread in time are override with newest irq tables from user space. This way, we don't have to set a threshold for ioctl frequency, and the ioctl may return sooner than synchronize RCU, letting the ioctl vCPU have a better response. How do you think? Or do you have any better ideas? Thanks in advance. Best regards, -Gonglei -- 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 v4 0/5] KVM: x86: flush tlb out of mmu-lock after write protection
Ping.. On 03/10/2014 10:01 PM, Xiao Guangrong wrote: > This patchset is splited from my previous patchset: > [PATCH v3 00/15] KVM: MMU: locklessly write-protect > that can be found at: > https://lkml.org/lkml/2013/10/23/265 > > Changelog v4 : > - add more comments for patch 5 and thank for Marcelo's review > > Xiao Guangrong (5): > Revert "KVM: Simplify kvm->tlbs_dirty handling" > KVM: MMU: properly check last spte in fast_page_fault() > KVM: MMU: lazily drop large spte > KVM: MMU: flush tlb if the spte can be locklessly modified > KVM: MMU: flush tlb out of mmu lock when write-protect the sptes > > arch/x86/kvm/mmu.c | 72 > ++ > arch/x86/kvm/mmu.h | 14 + > arch/x86/kvm/paging_tmpl.h | 7 ++--- > arch/x86/kvm/x86.c | 20 ++--- > include/linux/kvm_host.h | 4 +-- > virt/kvm/kvm_main.c| 5 +++- > 6 files changed, 85 insertions(+), 37 deletions(-) > -- 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
