[Top][All Lists]

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

Re: [Qemu-ppc] [Qemu-devel] [PATCH 2/2] vl: Print CPU help after we've r

From: Eduardo Habkost
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH 2/2] vl: Print CPU help after we've registered the CPU accelerators
Date: Wed, 8 Mar 2017 11:50:38 -0300
User-agent: Mutt/1.7.1 (2016-10-04)

On Wed, Mar 08, 2017 at 03:31:01PM +0100, Peter Maydell wrote:
> On 3 March 2017 at 15:58, Eduardo Habkost <address@hidden> wrote:
> > On Tue, Jan 31, 2017 at 02:11:59PM +0100, Thomas Huth wrote:
> >> When running with KVM on POWER, we register some CPU types during
> >> the initialization function of the ppc64 KVM code (which unfortunately
> >> also can not be done via a type_init() like it is done on x86).
> >
> > Can you elaborate why it can't be done via type_init()? If the
> > QOM type hierarchy depends on any runtime data unavailable at
> > type_init(), we should fix that.
> On ARM we (currently) have the KVM-only 'host' CPU type be
> added to the type hierarchy only at runtime in kvm_init(),
> but we deal with the '-help' problem by having arm_cpu_list() do
> #ifdef CONFIG_KVM
>     /* The 'host' CPU type is dynamically registered only if KVM is
>      * enabled, so we have to special-case it here:
>      */
>     (*cpu_fprintf)(f, "  host (only available in KVM mode)\n");
> #endif

We already have similar code at ppc_cpu_list():

    cpu_fprintf(f, "\n");
    cpu_fprintf(f, "PowerPC %-16s\n", "host");

If I understood it correctly, the current problem is just
inaccurate alias information being printed because the alias
table is modified by the accelerator.

My current suggestion is to avoid printing anything that depends
on the current machine/accelerator at the help output.


reply via email to

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