[PATCH] KVM: ARM: ignore guest L2 cache control SMCs on Highbank and OMAP

[Christoffer Dall]

On Wed, Aug 14, 2013 at 07:01:05PM +0100, Peter Maydell wrote:
> On 14 August 2013 18:18, Christoffer Dall <christoffer.dall at linaro.org> wrote:
> > How would we distinguish between a PSCI call that the kernel should
> > support and a call to secure firmware that needs to be forwarded to
> > QEMU?  Is this simply a binary config at VM creation time?
> 
> Kernel PSCI is always HVC (right?) so you could just say
> that HVC is the kernel's business and SMC is the guest
> firmware's.
> 

As I understand it, current implementations rely on info from the DT and
guests are therefore told only to use HVCs, but the spec allows both an
HVC and an SMC as the conduit (unless I read this wrong), so I think
it's quite possible that we'll end up supporting something that needs
make PSCI calls via SMC.  On the other hand, if QEMU can make the
distinction and do everything that the kernel would otherwise be able to
do to handle the PSCI, then we can still just let QEMU handle the whole
thing.

(feel free to replace QEMU with "user space" in the above)

> If we make the kernel just restart the guest inside its
> firmware blob without reflecting the SMC out to userspace
> are we going to regret it later?
> 

Are you suggesting that we'd load the secure firmware inside the guest
in a separate address space somehow and just let it execute the binary?
That won't work without considerable emulation efforts in the kernel to
support the privileged operations right?  What if the secure firmware
does something SoC-specific that KVM will never know about, but QEMU
would, then there's still the need for some 'backdoor' out to QEMU.

Did I misunderstand your point here?

I would imagine that at most QEMU can tell KVM to set SMC calls to
exactly one of these modes:
 1) Handle SMCs as undefined
 2) Handle SMCs as PSCI
 3) Forward all SMCs to me

And that would more or less be the end of it as far as KVM is
involved...

-Christoffer