qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] test: port postcopy test to ppc64


From: Thomas Huth
Subject: Re: [Qemu-devel] [PATCH] test: port postcopy test to ppc64
Date: Thu, 21 Jul 2016 23:02:12 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2

On 21.07.2016 15:46, Laurent Vivier wrote:
> 
> 
> On 21/07/2016 15:16, Thomas Huth wrote:
>> On 21.07.2016 12:12, Laurent Vivier wrote:
>>> As userfaultfd syscall is available on powerpc, migration
>>> postcopy can be used.
>>
>> Good idea to add this test for PPC, too!
> 
> The idea comes from David Gilbert :)
> Thanks David!
> 
>>
>>> This patch adds the support needed to test this on powerpc,
>>> instead of using a bootsector to run code to modify memory,
>>> we use a FORTH script in "boot-command" property.
>>>
>>> As spapr machine doesn't support "-prom-env" argument
>>> (the nvram is initialized by SLOF and not by QEMU),
>>> "boot-command" is provided to SLOF via a file mapped nvram
>>> (with "-drive file=...,if=pflash")
>>
>> I wonder whether we could easily add support for the "-prom-env"
>> parameter for the sPAPR machine, too, since the NVRAM layout seems to be
>> pretty much the same as on the old CHRP Mac machines...?
> 
> The only thing we need to have "-prom-env" is to initialize the nvram
> partitions in QEMU if they don't exist.
> 
> I didn't follow this way because this work is normally to be done by the
> firmware not by QEMU. If we do it in QEMU, SLOF will do not, and we
> can't be sure we are doing the things well, as SLOF does.

I'm slightly familiar with the NVRAM code in SLOF ... shouldn't be too
hard to get a similar layout done with QEMU, especially if we can re-use
some of the OpenBIOS NVRAM functions in QEMU.

> On Mac, it is another history, originally, firmware was OpenHackware,
> not OpenBIOS, and OH was only here to allow to boot the kernel nothing
> more (it was really a hack: there was not forth interpreter [oh, my god!]).
> So all the important stuffs were done by QEMU, like to initialize the
> NVRAM, the PCI bus, ... and this allows to set values in the environment
> variables.
> 
> But if you think it is viable, it should be really easy to do (like
> cut'n'paste from OpenBIOS ABI)...

Having -prom-env for SLOF, too, would be really posh, so I think I'll
have a try when I got some spare minutes ... hmm, my TODO list seems to
keep rather growing than shrinking ... maybe I'm doing something wrong ;-)

 Thomas




reply via email to

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