qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH 24/58] PPC: E500: Add PV spinning code
Date: Tue, 27 Sep 2011 18:47:19 +0000

On Tue, Sep 27, 2011 at 5:58 PM, Scott Wood <address@hidden> wrote:
> 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 <address@hidden> wrote:
>>>> On 27.09.2011, at 17:50, Blue Swirl wrote:
>>>>> On Mon, Sep 26, 2011 at 11:19 PM, Scott Wood <address@hidden> 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?

The difference is that the fw_cfg interface is pretty simple and
private between QEMU and OpenBIOS, whereas magical HW to support ePAPR
interface is public and towards a kernel. With the ROM approach, the
interface would exist between the ROM and kernel as intended.

> 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.

I think I've confused sPAPR (which has a lot of messy OF tree stuff) and ePAPR.

>>>>>> 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).

That looks OK.

>>>> 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).

This is a different issue, a limitation exists that QEMU can't execute
from MMIO region. But flash is a bit different, on write it's MMIO but
on read like RAM, so it should work.

> 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.

I'd use fw_cfg for passing the device tree to the ROM.

> 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.

Yes and it's also possible to emulate different interfaces of a
system. But from QEMU code maintenance point of view, semi-hosting
approaches should not get in the way of system emulation. If they are
optional and do not affect the rest of the system, they are OK.

On the other hand, maybe it's a problem with QEMU architecture, the
design is very much tuned to support HW emulation and not various
software interfaces.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]