Re: [RFC PATCH v3 6/6] kvm/ppc/mpic: add KVM_CAP_IRQ_MPIC
Am 05.04.2013 um 00:35 schrieb Scott Wood scottw...@freescale.com:
On 04/04/2013 05:30:05 PM, Alexander Graf wrote:
Am 04.04.2013 um 20:41 schrieb Scott Wood scottw...@freescale.com:
On 04/04/2013 07:54:20 AM, Alexander Graf wrote:
On 03.04.2013, at 03:57, Scott Wood wrote:
+if (opp-mpic_mode_mask == GCR_MODE_PROXY)
Shouldn't this be an ?
The way the mode field was originally documented was a two-bit field,
where 0b11 was external proxy, and 0b10 was reserved. If we use it
would have to be:
if ((opp-mpic_mode_mask GCR_MODE_PROXY) == GCR_MODE_PROXY)
...
Simply testing opp-mpic_mode_mask GCR_MODE_PROXY would return true in
the case of GCR_MODE_MIXED.
In MPIC 4.3 external proxy is defined as a separate bit (GCR[CI]) that is
ignored if the mixed-mode bit (GCR[M]) is not set, which makes it a bit
more legitimate to view it as a bitmap. Still, I doubt we'll see new mode
bits.
Ok, please add a comment about this here then :).
What sort of comment would you like? Or do you want me to use the (x y)
== y version?
/* This might need to be changed if GCR gets extended */
@@ -460,6 +464,13 @@ void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu)
tasklet_kill(vcpu-arch.tasklet);
kvmppc_remove_vcpu_debugfs(vcpu);
+
+switch (vcpu-arch.irq_type) {
+case KVMPPC_IRQ_MPIC:
+kvmppc_mpic_put(vcpu-arch.mpic);
This doesn't tell the MPIC that this exact CPU is getting killed. What if
we hotplug remove just a single CPU? Don't we have to deregister the CPU
with the MPIC?
If we ever support hot vcpu removal, yes. We'd probably need some MPIC
code changes to accommodate that, and we wouldn't currently have a way to
test it, so I'd rather make it obviously not supported for now.
Is there any way to break heavily if user space attempts this?
Is there any way for userspace to request this currently? They can close the
vcpu fd, but the vcpu won't actually be destroyed until the vm goes down.
Are you sure? X86 does CPU hotplug today, so there has to be something :)
Alex
-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: [PATCH] bookehv: Handle debug exception on guest exit
Hi Kumar/Benh, After further looking into the code I think that if we correct the vector range below in DebugDebug handler then we do not need the change I provided in this patch. Here is the snapshot for 32 bit (head_booke.h, same will be true for 64 bit): #define DEBUG_DEBUG_EXCEPTION \ START_EXCEPTION(DebugDebug); \ DEBUG_EXCEPTION_PROLOG; \ \ /*\ * If there is a single step or branch-taken exception in an \ * exception entry sequence, it was probably meant to apply to\ * the code where the exception occurred (since exception entry \ * doesn't turn off DE automatically). We simulate the effect\ * of turning off DE on entry to an exception handler by turning \ * off DE in the DSRR1 value and clearing the debug status. \ */ \ mfspr r10,SPRN_DBSR; /* check single-step/branch taken */ \ andis. r10,r10,(DBSR_IC|DBSR_BT)@h; \ beq+2f; \ \ lis r10,KERNELBASE@h; /* check if exception in vectors */ \ ori r10,r10,KERNELBASE@l; \ cmplw r12,r10; \ blt+2f; /* addr below exception vectors */\ \ lis r10,DebugDebug@h;\ ori r10,r10,DebugDebug@l; \ Here we assume all exception vector ends at DebugDebug, which is not correct. We probably should get proper end by using some start_vector and end_vector lebels or at least use end at Ehvpriv (which is last defined in head_fsl_booke.S for PowerPC. Is that correct? cmplw r12,r10; \ bgt+2f; /* addr above exception vectors */\ Thanks -Bharat -Original Message- From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Bhushan Bharat-R65777 Sent: Thursday, April 04, 2013 8:29 PM To: Alexander Graf Cc: linuxppc-...@lists.ozlabs.org; k...@vger.kernel.org; kvm-ppc@vger.kernel.org; Wood Scott-B07421 Subject: RE: [PATCH] bookehv: Handle debug exception on guest exit -Original Message- From: Alexander Graf [mailto:ag...@suse.de] Sent: Thursday, April 04, 2013 6:55 PM To: Bhushan Bharat-R65777 Cc: linuxppc-...@lists.ozlabs.org; k...@vger.kernel.org; kvm-ppc@vger.kernel.org; Wood Scott-B07421; Bhushan Bharat-R65777 Subject: Re: [PATCH] bookehv: Handle debug exception on guest exit On 20.03.2013, at 18:45, Bharat Bhushan wrote: EPCR.DUVD controls whether the debug events can come in hypervisor mode or not. When KVM guest is using the debug resource then we do not want debug events to be captured in guest entry/exit path. So we set EPCR.DUVD when entering and clears EPCR.DUVD when exiting from guest. Debug instruction complete is a post-completion debug exception but debug event gets posted on the basis of MSR before the instruction is executed. Now if the instruction switches the context from guest mode (MSR.GS = 1) to hypervisor mode (MSR.GS = 0) then the xSRR0 points to first instruction of KVM handler and xSRR1 points that MSR.GS is clear (hypervisor context). Now as xSRR1.GS is used to decide whether KVM handler will be invoked to handle the exception or host host kernel debug handler will be invoked to handle the exception. This leads to host kernel debug handler handling the exception which should either be handled by KVM. This is tested on e500mc in 32 bit mode Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com --- v0: - Do not apply this change for debug_crit as we do not know those chips have issue or not. - corrected 64bit case branching arch/powerpc/kernel/exceptions-64e.S | 29 - arch/powerpc/kernel/head_booke.h | 26 ++ 2 files changed, 54 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S index 4684e33..8b26294 100644 --- a/arch/powerpc/kernel/exceptions-64e.S +++
Re: [RFC PATCH v3 6/6] kvm/ppc/mpic: add KVM_CAP_IRQ_MPIC
On 04/05/2013 01:09:50 AM, Alexander Graf wrote:
Am 05.04.2013 um 00:35 schrieb Scott Wood scottw...@freescale.com:
On 04/04/2013 05:30:05 PM, Alexander Graf wrote:
Am 04.04.2013 um 20:41 schrieb Scott Wood
scottw...@freescale.com:
On 04/04/2013 07:54:20 AM, Alexander Graf wrote:
On 03.04.2013, at 03:57, Scott Wood wrote:
@@ -460,6 +464,13 @@ void kvm_arch_vcpu_free(struct kvm_vcpu
*vcpu)
tasklet_kill(vcpu-arch.tasklet);
kvmppc_remove_vcpu_debugfs(vcpu);
+
+switch (vcpu-arch.irq_type) {
+case KVMPPC_IRQ_MPIC:
+kvmppc_mpic_put(vcpu-arch.mpic);
This doesn't tell the MPIC that this exact CPU is getting
killed. What if we hotplug remove just a single CPU? Don't we have to
deregister the CPU with the MPIC?
If we ever support hot vcpu removal, yes. We'd probably need
some MPIC code changes to accommodate that, and we wouldn't currently
have a way to test it, so I'd rather make it obviously not supported
for now.
Is there any way to break heavily if user space attempts this?
Is there any way for userspace to request this currently? They can
close the vcpu fd, but the vcpu won't actually be destroyed until the
vm goes down.
Are you sure? X86 does CPU hotplug today, so there has to be
something :)
Hot add, or hot remove?
Can you give me any hint on where to look?
kvm_cpu_hotplug() appears to deal with hotplug of *physical* cpus --
and is currently a no-op on powerpc. Other than that, grepping isn't
turning up much.
-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
