Am 26.05.2014 12:31, schrieb Alexander Graf: > > On 26.05.14 12:20, Andreas Färber wrote: >> Am 26.05.2014 11:57, schrieb Alexander Graf: >>> Any reason we're so incredibly inconsistent in what we do during realize >>> with reset? I would really prefer to ensure we're doing the same thing >>> on all targets. >>> >>> >>> Alex >>> >>> $ grep -R -A 3 -B 3 qemu_init_vcpu target-* >>> target-alpha/cpu.c- CPUState *cs = CPU(dev); >>> target-alpha/cpu.c- AlphaCPUClass *acc = ALPHA_CPU_GET_CLASS(dev); >>> target-alpha/cpu.c- >>> target-alpha/cpu.c: qemu_init_vcpu(cs); >>> target-alpha/cpu.c- >>> target-alpha/cpu.c- acc->parent_realize(dev, errp); >>> target-alpha/cpu.c-} >> Alpha is the main blocker for unifying CPU reset iirc. It does not >> implement reset at all and thus is not calling it. The struct was not >> designed for zero'ing things, so there's a mix of data fields and >> pointers without clear separation to allow memset(), and I have neither >> a working alpha test image nor the time to investigate this at the >> moment. >> >> WIP here: >> https://github.com/afaerber/qemu-cpu/commits/qom-cpu-alpha >> https://github.com/afaerber/qemu-cpu/commits/qom-cpu-reset >> >> According to my commit unicore32 is another odd sock that doesn't reset >> the CPU - despite implemented iirc. > > So if we had reset, we could call > > qemu_init_vcpu(); > cpu_reset() > > inside parent_realize(), right? That's exactly what the single commit on qom-cpu-reset does. :) Andreas > Then let's prepare for that step and make at least all targets that do > call cpu_reset call it after init_vcpu(). > > > Alex > -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
