[Top][All Lists]

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

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

From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH v3] hw/core/null-machine: Add the possibility to instantiate a CPU and RAM
Date: Fri, 20 Jan 2017 19:06:21 -0200
User-agent: Mutt/1.7.1 (2016-10-04)

On Wed, Jan 18, 2017 at 04:34:47PM -0800, Alistair Francis wrote:
> On Wed, Jan 18, 2017 at 10:56 AM, Thomas Huth <address@hidden> wrote:
> > On 18.01.2017 18:57, Alistair Francis wrote:
> >> On Wed, Jan 18, 2017 at 4:44 AM, Thomas Huth <address@hidden> wrote:
> >>> Sometimes it is useful to have just a machine with CPU and RAM, without
> >>> any further hardware in it, e.g. if you just want to do some instruction
> >>> debugging for TCG with a remote GDB attached to QEMU, or run some embedded
> >>> code with the "-semihosting" QEMU parameter. qemu-system-m68k already
> >>> features a "dummy" machine, and xtensa a "sim" machine for exactly this
> >>> purpose.
> >>> All target architectures have nowadays also a "none" machine, which would
> >>> be a perfect match for this, too - but it currently does not allow to add
> >>> CPU and RAM yet. Thus let's add these possibilities in a generic way to 
> >>> the
> >>> "none" machine, too, so that we hopefully do not need additional "dummy"
> >>> machines in the future anymore (and maybe can also get rid of the already
> >>> existing "dummy"/"sim" machines one day).
> >>> Note that the default behaviour of the "none" machine is not changed, i.e.
> >>> no CPU and no RAM is instantiated by default. You have explicitely got to
> >>> specify the CPU model with "-cpu" and the amount of RAM with "-m" to get
> >>> these new features.
> >>>
> >>> Signed-off-by: Thomas Huth <address@hidden>
> >>> ---
> >>>  v3:
> >>>  - Get rid of the cpu_init_def() wrapper again, make null-machine.o
> >>>    target dependent instead and use cpu_init() directly.
> >>>  - Omit the loader code for the "-kernel" option for now (users can
> >>>    use "-device loader,..." instead). We can add code for the -kernel
> >>>    parameter later (either an implementation or a warning), once we've
> >>>    decided how it should behave for the "none" machine.
> >>
> >> I think there should at least be a warning to start with though. It
> >> seems confusing that no errors are reported but the argument is
> >> ignored.
> >
> > I'm still rather in favor of adding the hunk here that calls the generic
> > loader for "-kernel" ... anyway, we can add either behavior with a later
> > patch. So far the "none" machine never reported an error here, so this
> > is not a regression if we do not have this right from the start.
> Your right, it isn't a regression. I still think we should try to get
> some sort of action in there before the next release.
> Reviewed-by: Alistair Francis <address@hidden>

Thanks. I am going to apply this and include in my next pull


reply via email to

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