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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
