[PATCH 3/4] KVM: PPC: Add support for IOMMU in-kernel handling

[Scott Wood]

On 05/24/2013 09:45:24 PM, David Gibson wrote:
> On Wed, May 22, 2013 at 04:06:57PM -0500, Scott Wood wrote:
> > On 05/20/2013 10:06:46 PM, Alexey Kardashevskiy wrote:
> > >diff --git a/arch/powerpc/kvm/powerpc.c  
> b/arch/powerpc/kvm/powerpc.c
> > >index 8465c2a..da6bf61 100644
> > >--- a/arch/powerpc/kvm/powerpc.c
> > >@@ -396,6 +396,7 @@ int kvm_dev_ioctl_check_extension(long ext)
> > >+++ b/arch/powerpc/kvm/powerpc.c
> > > 		break;
> > > #endif
> > > 	case KVM_CAP_SPAPR_MULTITCE:
> > >+	case KVM_CAP_SPAPR_TCE_IOMMU:
> > > 		r = 1;
> > > 		break;
> > > 	default:
> >
> > Don't advertise SPAPR capabilities if it's not book3s -- and
> > probably there's some additional limitation that would be
> > appropriate.
> 
> So, in the case of MULTITCE, that's not quite right.  PR KVM can
> emulate a PAPR system on a BookE machine, and there's no reason not to
> allow TCE acceleration as well.

That might (or might not; consider things like Altivec versus SPE  
opcode conflict, whether unimplemented SPRs trap, behavior of  
unprivileged SPRs/instructions, etc) be true in theory, but it's not  
currently a supported configuration.  BookE KVM does not support  
emulating a different CPU than the host.  In the unlikely case that  
ever changes to the point of allowing PAPR guests on a BookE host, then  
we can revisit how to properly determine whether the capability is  
supported, but for now the capability will never be valid in the  
CONFIG_BOOKE case (though I'd rather see it depend on an appropriate  
book3s symbol than depend on !BOOKE).

Or we could just leave it as is, and let it indicate whether the host  
kernel supports the feature in general, with the user needing to  
understand when it's applicable...  I'm a bit confused by the  
documentation, however -- the MULTITCE capability was documented in the  
"capabilities that can be enabled" section, but I don't see where it  
can be enabled.

-Scott