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
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
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
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
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
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
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
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
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
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
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
11 matches
Mail list logo