Re: [Qemu-devel] [PATCH 24/58] PPC: E500: Add PV spinning code

[Scott Wood <scottwood@freescale.com>]

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 <agraf@suse.de> wrote:
>>> On 27.09.2011, at 17:50, Blue Swirl wrote:
>>>> On Mon, Sep 26, 2011 at 11:19 PM, Scott Wood <scottwood@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