On 31.01.2013, at 17:15, Andreas Färber wrote: > Am 31.01.2013 16:48, schrieb Alexander Graf: >> >> On 31.01.2013, at 16:23, Andreas Färber wrote: >> >>> 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. >> >> Any particular reason this is 1.4 material? > > 1/2 is the cleanup of 1.4's virtio-ccw that we discussed at IBM. > 2/2 shows that variable placement inside do_interrupt() was no accident. > > The alternative is you acking it and me putting it in qom-cpu-next. > It's a prereq for other series as indicated in the commit messages and > we're not in Hard Freeze yet, so you get to decide.
Well, I'd hope having it in now makes backporting patches later easier, so I just applied them. Thanks a lot for all your refactoring work :) Alex
