[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH for-1.4 0/2] target-s390x: CPU cleanups preparin
From: |
Andreas Färber |
Subject: |
Re: [Qemu-devel] [PATCH for-1.4 0/2] target-s390x: CPU cleanups preparing for 1.5 |
Date: |
Thu, 31 Jan 2013 16:23:14 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130105 Thunderbird/17.0.2 |
Am 30.01.2013 23:48, schrieb Andreas Färber:
> As a reminder here's a link to one of my original discussions of the new
> types:
> https://lists.nongnu.org/archive/html/qemu-devel/2012-05/msg01286.html
>
> That is, for any non-TCG functions (TCG does not support CPUState yet) an
> S390CPU argument should be preferred over CPUS390XState since it allows cheap
> access to its own fields, CPUState's via CPU() and to CPUS390XState via ->env.
> Doing this consistently avoids costs of casting back and forth unnecessarily.
>
> s390 code should use s390_env_get_cpu() where needed, not ENV_GET_CPU().
>
> As a rule of thumb, any field in include/exec/cpu-defs.h:CPU_COMMON can be
> expected to end up in CPUState (or accessible from there) sooner or later.
> Per-target functions can be expected to change to CPUState soon.
Maybe too brief: This was referring to functions like kvm_arch_*() that
each target implements, knowing its CPU type. In particular
do_interrupt() is one of my next candidates.
Andreas
>
> New fields that do not need to be accessed via TCGv or from a hot TCG helper
> function should be added to S390CPU, not to CPUS390XState.
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg