qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] hw/core/null-machine: Add the possibility to in


From: Thomas Huth
Subject: Re: [Qemu-devel] [PATCH] hw/core/null-machine: Add the possibility to instantiate a CPU, RAM and kernel
Date: Tue, 17 Jan 2017 14:02:24 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0

On 17.01.2017 13:36, Eduardo Habkost wrote:
> On Tue, Jan 17, 2017 at 09:29:19AM +0000, Peter Maydell wrote:
>> On 16 January 2017 at 19:44, Eduardo Habkost <address@hidden> wrote:
>>> On Mon, Jan 16, 2017 at 07:27:21PM +0000, Peter Maydell wrote:
>>>> On 16 January 2017 at 19:25, Eduardo Habkost <address@hidden> wrote:
>>>>> On Mon, Jan 16, 2017 at 10:53:07AM -0800, Alistair Francis wrote:
>>>>>> On Sun, Jan 15, 2017 at 11:59 PM, Thomas Huth <address@hidden> wrote:
>>>>>>> But I think the users also expect the "-kernel" parameter to be working,
>>>>>>> so I think we should add the loader code in null-machine.c anyway.
>>>>>>
>>>>>> I agree that uses probably expect the '-kernel' option to work as well.
>>>>>
>>>>> So, is it possible to write a generic load_kernel() function that
>>>>> simply reuses the generic-loader code?
>>>>
>>>> No, because users expect -kernel to actually load a Linux kernel
>>>> (meaning with the calling conventions etc the kernel requires),
>>>> whereas generic-loader is just "load a binary blob and start there".
>>>
>>> I don't mean a generic function that works for all machines and
>>> architectures, but a generic function that is good enough for
>>> "-machine none". Isn't "load a binary blob and start there"
>>> exactly what machine_none_load_kernel() in this patch does?
>>
>> If you just want "load a blob and start it" then we already
>> have -device loader. Making -kernel have yet another set of
>> semantics that this time depends on the machine being selected
>> seems like a bad idea. If -kernel doesn't do what it does
>> for the other machines of the same architecture then we should
>> just not accept it.
> 
> Good point. In this case, implementing -kernel on "-machine none"
> will require calling an arch-specific hook from the beginning.
> I'm not sure if it's worth the effort, but I won't object if
> somebody really wants to implement that.

The -kernel parameter is not just only dependent on the target
architecture, it is even dependent on the machine type, e.g. on ppc it
is quite different between embedded (e500.c) and server (spapr.c)
variants. So an arch-specific hook might not make too much sense and
using the generic loader is likely the best we can do - if that does not
work, you likely can't use the "none" machine anyway.

> While this is not implemented, I suggest we make "-machine none"
> reject -kernel instead of silently ignoring it.

I'd prefer to use the generic loader for "-kernel" as a shortcut to
"-device loader,file=..." here, but if the common sense is rather to
refuse the -kernel option on the "none" machine, that's OK for me, too.
Anybody else got an opinion on this?

 Thomas




reply via email to

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