On 09/27/2011 12:03 PM, Alexander Graf wrote: > On 27.09.2011, at 18:53, Blue Swirl wrote: >> On Tue, Sep 27, 2011 at 3:59 PM, Alexander Graf <ag...@suse.de> wrote: >>> On 27.09.2011, at 17:50, Blue Swirl wrote: >>>> On Mon, Sep 26, 2011 at 11:19 PM, Scott Wood <scottw...@freescale.com> >>>> wrote: >>>>> I think the current approach is more usable for most purposes. If you >>>>> start U-Boot instead of a kernel, how do pass information on from the >>>>> user (kernel, rfs, etc)? Require the user to create flash images[1]? >>>> >>>> No, for example OpenBIOS gets the kernel command line from fw_cfg device.
Is that really so different from making QEMU act as an ePAPR-compliant loader? A big difference here is that on x86 you have a large quantity of runtime services provided by the BIOS, which I can certainly understand not wanting to shove into QEMU (though I'd still think you'd want to hack out the initialization parts of the BIOS that depend on special cache behavior, RAM controllers, and such, if at all practical). This spin table stuff is the only runtime service provided by an ePAPR loader. >>>>> Maybe that's a useful mode of operation in some cases, but I don't think >>>>> we should be slavishly bound to it. Think of the current approach as >>>>> something between whole-system and userspace emulation. >>>> >>>> This is similar to ARM, M68k and Xtensa semi-hosting mode, but not at >>>> kernel level but lower. Perhaps this mode should be enabled with >>>> -semihosting flag or a new flag. Then the bare metal version could be >>>> run without the flag. >>> >>> and then we'd have 2 implementations for running in system emulation mode >>> and need to maintain both. I don't think that scales very well. >> >> No, but such hacks are not common. How much would actually need to be duplicated? Seems like other than turning some features off (a smaller set of devices, and not needing extra address translation/cache layers), you'd just have a different way of loading/starting the guest. Most of that code would be common to all ePAPR targets (with a few HW-specific variants for the MMU setup portion). >>> So how would you emulate cache lines with line locking on KVM? >> >> The cache would be a MMIO device which registers to handle all memory >> space. Configuring the cache controller changes how the device >> operates. Put this device between CPU and memory and other devices. >> Performance would probably be horrible, so CPU should disable the >> device automatically after some time. > > So how would you execute code on this region then? :) I think U-Boot only does this for data, not code. But U-Boot will want to execute out of flash, and it will want to be able to move/resize the flash window using the localbus controller (can't treat it as a statically located rom image). Easier would be to run a U-Boot that assumes RAM is already configured, which we support for booting from sources other than NOR flash (would be some minor tweakage to decouple it from those boot scenarios). There'd still be a lot of random I/O that needs to be emulated, or avoided with changes to U-Boot. And there'd still be the question of where the device tree comes from, how information gets passed on from qemu, etc. Full system emulation at that level would be an interesting project and have its uses, but it would be a lot of work and should not get in the way of workloads that don't need/want it. The requirements and usability considerations for virtualization are not always the same as for traditional emulation use cases. -Scott
