Continuing with my set of patches I sent long time ago to get traces
from guest code [1], the next (and almost final) step is to be able to
set a different CPI (cycles per instruction) value for each vCPU.
The first and simplest question is to know if icount could be easily
enabled on non-softmmu frontends.
The next question is how to get the CPI information to work. As my
objective is to see it integrated into QEMU proper, I'd like to avoid
any invasive code modifications.
The target is to have a per-vCPU CPI value that will make each vCPU
appear as executing instructions at different speeds. On one end of the
spectrum, the per-vCPU CPI can be tuned to roughly emulate the timing
effects of frequency scaling (understanding the cycles in CPI as
relative to a "universal" clock that runs at a fixed speed and contains
the whole system). On the other end, my plans are to feed the guest code
tracing information into a cycle-accurate architecture simulator, so
that the simulator will eventually tune the per-vCPU CPI values to
change the relative speed of each vCPU according to the timing results.
>From what I've understood by reading the source, it seems I could modify
'qemu_icount_round' to set the target instruction count according to the
CPI of the current vCPU. This would in turn nullify the global
'icount_time_shift', which should be removed in favour of the per-vCPU
CPI value.
Does it sound right to you? I ask because I still have no clear idea how
this will interact with the timing calculations outside TCG execution.
[1] It is now ported to QEMU's tracing infrastructure, with some extra
nice additions, and I'm waiting for the acceptance of the
"tracing-state" series before I start flooding with new series built
on that.
Thanks,
Lluis
--
"And it's much the same thing with knowledge, for whenever you learn
something new, the whole world becomes that much richer."
-- The Princess of Pure Reason, as told by Norton Juster in The Phantom
Tollbooth
