[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Virtualising qmp_query_cpus() arch specifics
From: |
Andreas Färber |
Subject: |
Re: [Qemu-devel] Virtualising qmp_query_cpus() arch specifics |
Date: |
Thu, 09 Jul 2015 14:31:31 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 |
Am 09.07.2015 um 08:36 schrieb Peter Crosthwaite:
> Hi All,
>
> So for my multi-arch work, one of the eventual requirements is to
> remove all #define TARGET_FOO from core code. I came across this in
> cpus.c/qmp_query_cpus():
>
> #if defined(TARGET_I386)
> X86CPU *x86_cpu = X86_CPU(cpu);
> CPUX86State *env = &x86_cpu->env;
> #elif defined(TARGET_PPC)
> PowerPCCPU *ppc_cpu = POWERPC_CPU(cpu);
> CPUPPCState *env = &ppc_cpu->env;
> ...
>
> #if defined(TARGET_I386)
> info->value->has_pc = true;
> info->value->pc = env->eip + env->segs[R_CS].base;
> #elif defined(TARGET_PPC)
> info->value->has_nip = true;
> info->value->nip = env->nip;
> ...
>
> This should probably be a QOM CPU virtual function. What makes me
> uneasy about it however, is a direct implementation means the QAPI
> autogenerated CPUInfoList struct would need to be exposed to
> target-foo/cpu.c. Is this ok or an abstraction fail? Do we need some
> other other minimal struct to communicate between target-foo and QMP
> with these particulars? Any third options?
Wouldn't that just be a get_pc() matching your set_pc() hook?
Unfortunately there's name differences above, pc vs. nip. Maybe we can
just use a generic field and keep #ifdef stuff only as legacy compat?
Cheers,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)