mbox series

[0/2] Romless QEMU shutdown patches

Message ID 159480834629.15819.10175861928294983612.stgit@pasha-ThinkPad-X280
Headers show
Series Romless QEMU shutdown patches | expand

Message

Pavel Dovgalyuk July 15, 2020, 10:19 a.m. UTC
Some machines require custom ROMs or kernels. They can't be started without
-bios, -kernel, or -pflash options. But this requirement can't be detected
automatically.

Running a romless machine may be needed for automatic introspection of default
machine hardware, when QEMU is started with a single -machine option.

This series provides patches that enable QEMU execution for MIPS and ARM machines,
even when there is no ROM.

---

Pavel Dovgalyuk (2):
      hw/mips: remove exit(1) in case of missing ROM
      hw/arm: remove exit(1) in case of missing ROM


 0 files changed

--
Pavel Dovgalyuk

Comments

Philippe Mathieu-Daudé Oct. 9, 2020, 4 p.m. UTC | #1
On 7/20/20 11:56 AM, Peter Maydell wrote:
> On Wed, 15 Jul 2020 at 11:19, Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru> wrote:
>>
>> This patch updates ARM-based machines to allow starting them without ROM.
>> In this case CPU starts to execute instructions from the empty memory,
>> but QEMU allows introspecting the machine configuration.
>>
>> Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgalyuk@ispras.ru>
> 
> I guess this makes sense -- this is how most of our machines
> already behave, so consistency and being able to introspect
> the machine config are both worth having. Also these errors
> mostly pre-date the 'generic loader' device, which is another
> way to load guest code that the error-exit prevents. (You could
> even load guest code via the gdbstub if you wanted...)

Note the 'generic loader' device allows you to select any CPU
address space, while gdbstub is restricted to the first CPU.

> 
> Calling arm_load_kernel() must not be conditional -- it is the
> function which makes sure the guest CPU is reset.
> 
> (A handful of boards will call arm_load_kernel() only if
> !qtest_enabled(), but most call it unconditionally. We should
> look at why those handful of boards seem to need the conditional
> and either remove it if useless or see if it should be applied
> in other places or if arm_load_kernel() itself could be improved
> to make the check unnecessary for all boards.)

Who should look at that? Maybe add that as a byte-sized task?

Regards,

Phil.