On 14 August 2013 19:13, Christoffer Dall <christoffer.dall@xxxxxxxxxx> wrote: > On Wed, Aug 14, 2013 at 07:01:05PM +0100, Peter Maydell wrote: >> 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. No, the suggestion is that the 'firmware' blob is a specifically written thing to work with QEMU/KVM, so it supports the right entry points but is written to work within a slightly odd environment where: * the kernel supports an emulated MVBAR * SMC causes us to redirect the guest so it enters as per the MVBAR, but in EL1, not EL3 * the "firmware" blob does whatever is necessary before returning from the SMC There is obviously no insulation between the guest kernel and the firmware blob in this scenario, but if we're not actually trying to emulate secure mode, just deal somehow with a handful of API calls, that should be fine. (This is an idea I've floated before, based partly on what the current QEMU OMAP3 emulation does. The advantage from my point of view is that it keeps the details of what the SMC entrypoints are supposed to do out of QEMU and in the board-specific blob.) -- PMM _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
