[PATCH] kvm: ppc: bookehv: Sync srr0/1 into GSRR0/1

This patch adds missing sync of SRR0/1 in set SREGS interface. Signed-off-by: Bharat Bhushan --- arch/powerpc/kvm/booke.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c index c2471ed..368b48e 100644 --- a/arch/powerpc/kvm/booke.c +++ b

KVM HV crash

Hi Paul, I've just seen a crash on POWER7 in HV KVM on a host where I run HV and PR KVM VMs in parallel based on the latest code (linus/master merged with for-3.16 merged with kvm-ppc-queue plus some PR patches): Unable to handle kernel paging request for data at address 0x000c Faulting i

Re: [PATCH 0/6] IRQFD without IRQ routing, enabled for XICS

On Mon, 30 Jun 2014 20:51:08 +1000 Paul Mackerras wrote: > I would like to see this go into 3.17. FWIW: I've given this a whirl on s390 (with a dataplane disk), and everything seems to work as before. The only thing which is I think worth mentioning is that embedding the routing entry into the

[PATCH 1/3] KVM: Rename and add argument to check_extension

In preparation to make the check_extension function available to VM scope we add a struct kvm * argument to the function header and rename the function accordingly. It will still be called from the /dev/kvm fd, but with a NULL argument for struct kvm *. Signed-off-by: Alexander Graf --- arch/arm

[PATCH 0/3] KVM: Make KVM_CHECK_EXTENSION a VM ioctl

On PowerPC we have a small problem :). We can run both HV and PR style VMs on the same kvm fd. While this is great, it means that anything that's different between the two needs to have a token in form of a VM fd to find out which one we're asking for. The one thing where this bites us are CAPs. W

[PATCH 3/3] KVM: PPC: Book3S: Provide different CAPs based on HV or PR mode

With Book3S KVM we can create both PR and HV VMs in parallel on the same machine. That gives us new challenges on the CAPs we return - both have different capabilities. When we get asked about CAPs on the kvm fd, there's nothing we can do. We can try to be smart and assume we're running HV if HV i

Re: KVM HV crash

On 14.07.14 13:24, Alexander Graf wrote: Hi Paul, I've just seen a crash on POWER7 in HV KVM on a host where I run HV and PR KVM VMs in parallel based on the latest code (linus/master merged with for-3.16 merged with kvm-ppc-queue plus some PR patches): I guess I must have used an older vml

[PATCH 2/3] KVM: Allow KVM_CHECK_EXTENSION on the vm fd

The KVM_CHECK_EXTENSION is only available on the kvm fd today. Unfortunately on PPC some of the capabilities change depending on the way a VM was created. So instead we need a way to expose capabilities as VM ioctl, so that we can see which VM type we're using (HV or PR). To enable this, add the K

Re: [PATCH 2/3] KVM: Allow KVM_CHECK_EXTENSION on the vm fd

On 14.07.14 19:03, Alexander Graf wrote: The KVM_CHECK_EXTENSION is only available on the kvm fd today. Unfortunately on PPC some of the capabilities change depending on the way a VM was created. So instead we need a way to expose capabilities as VM ioctl, so that we can see which VM type we're

[PATCH v2 2/3] KVM: Allow KVM_CHECK_EXTENSION on the vm fd

The KVM_CHECK_EXTENSION is only available on the kvm fd today. Unfortunately on PPC some of the capabilities change depending on the way a VM was created. So instead we need a way to expose capabilities as VM ioctl, so that we can see which VM type we're using (HV or PR). To enable this, add the K

Re: [PATCH 0/3] KVM: Make KVM_CHECK_EXTENSION a VM ioctl

On Mon, 14 Jul 2014 19:03:35 +0200 Alexander Graf wrote: > On PowerPC we have a small problem :). We can run both HV and PR style VMs > on the same kvm fd. While this is great, it means that anything that's > different between the two needs to have a token in form of a VM fd to find > out which o