From: "Andreas Färber" <afaerber@suse.de>
To: "Lluís Vilanova" <vilanova@ac.upc.edu>
Cc: Luiz Capitulino <lcapitulino@redhat.com>,
qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v5 03/43] monitor: Don't access registers through CPUState
Date: Thu, 15 Mar 2012 19:12:15 +0100 [thread overview]
Message-ID: <4F6230FF.8090307@suse.de> (raw)
In-Reply-To: <87r4wthmbx.fsf@ginnungagap.bsc.es>
Am 15.03.2012 17:15, schrieb Lluís Vilanova:
> Andreas Färber writes:
>
>> Use CPUX86State etc. instead (hand-converted).
>
> Is there any reason not to move this into CPU${arch}State and instead provide
> virtual methods in CPUState?
Yes, a very simple one: This is one of the prerequisite patches to
having a QOM CPUState struct we can place such virtual methods in.
Originally, not even reset was in there, but there were comments that my
series was getting too long, so I moved it out of the ARM series and
squashed it into what is now patch 43.
> For example (a CPUState argument is implicit on all methods):
>
> int reg_get_number(const char *regname);
> const char* reg_get_name(int regnum);
>
> /* register validity for a specific instantiation must be chekced somehow */
> bool reg_valid(int regnum);
>
> size_t reg_get_size(int regnum);
>
> /* multiple sizes must be handled somehow */
> /* precondition: get_reg_validity(regnum) == true */
> void reg_get_value(int regnum, void *buf);
> void reg_set_value(int regnum, void *buf);
>
>
> This way, target-specific code would be moved where it belongs, partially
> merging (for example) code from both monitor.c, gdbstub.c and the target
> itself.
That is definitely the direction I want to go with QOM CPUs. I haven't
dug into gdbstub or monitor too deeply yet, beyond looking for ways to
make the CPUState -> CPUArchState conversion as small as possible.
In this case, I am not sure why the original authors chose not to place
the code into target-*. Maybe those reasons no longer apply.
Anyway, once all CPUs are converted - or if you're adventurous based on
my qom-cpu-wip branch - I'd be happy to review patches moving more stuff
into CPUState. :) Moving properties from CPUArchState into CPUState
seemed fairly mechanical, so I attacked the more challenging problem of
statically calculated offsets for TCG's icount first.
I'd also envision some of the #defines we have flying around in cpu.h to
turn into read-only CPU properties, like page size or number of MMU
modes, so that the CPU becomes more self-describing and doesn't pollute
the global namespace.
> The downside is that using pointers to set/get the value is pretty
> uncomfortable.
We can add cpu_...(CPUState, ...) wrapper functions, like cpu_reset().
Cheers,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
next prev parent reply other threads:[~2012-03-15 18:12 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-14 21:42 [Qemu-devel] [PULL] QOM CPUState v5 Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 01/43] PPC: 405: Use proper CPU reset Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 02/43] Rename cpu_reset() to cpu_state_reset() Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 03/43] monitor: Don't access registers through CPUState Andreas Färber
2012-03-15 16:15 ` Lluís Vilanova
2012-03-15 18:12 ` Andreas Färber [this message]
2012-03-15 21:35 ` Lluís Vilanova
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 04/43] monitor: Avoid CPUState in read/write functions Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 05/43] target-lm32/microblaze: Typedef struct CPU{MB, LM32}State Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 06/43] target-sparc: Typedef struct CPUSPARCState early Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 07/43] target-unicore32: Rename to CPUUniCore32State Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 08/43] hw/mc146818: Drop unneeded #includes Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 09/43] linux-user: Don't overuse CPUState Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 10/43] darwin-user: " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 11/43] bsd-user: " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 12/43] target-alpha: " Andreas Färber
2012-03-17 19:20 ` Richard Henderson
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 13/43] target-arm: " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 14/43] target-cris: " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 15/43] target-i386: " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 16/43] target-lm32: " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 17/43] target-m68k: " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 18/43] target-microblaze: " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 19/43] target-mips: " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 20/43] target-ppc: " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 21/43] target-s390x: " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 22/43] target-sh4: " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 23/43] target-sparc: " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 24/43] target-unicore32: " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 25/43] target-xtensa: " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 26/43] arm-semi: Don't use CPUState Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 27/43] m68k-semi: " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 28/43] xtensa-semi: " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 29/43] alpha hw/: " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 30/43] arm " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 31/43] cris " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 32/43] i386 " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 33/43] lm32 " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 34/43] m68k " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 35/43] microblaze " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 36/43] mips " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 37/43] ppc " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 38/43] s390x " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 39/43] sh4 " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 40/43] sparc " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 41/43] xtensa " Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 42/43] Rename CPUState -> CPUArchState Andreas Färber
2012-03-14 21:42 ` [Qemu-devel] [PATCH v5 43/43] qom: Introduce CPU class Andreas Färber
2012-03-15 0:49 ` [Qemu-devel] [PULL] QOM CPUState v5 Anthony Liguori
2012-03-15 10:16 ` [Qemu-devel] [PULL] QOM CPUState v5 - conflict resolution info Andreas Färber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F6230FF.8090307@suse.de \
--to=afaerber@suse.de \
--cc=armbru@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=vilanova@ac.upc.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).