right it accesses CPU registers but from helper context.
the flow is as follows
1. there is a write to [0x0000: 0x0100) region
2. tlb_fill is called, it does the following
a. sets env->fullwr
b. calls cpu_loop_exit_restore.
c. the whole block is retranslated and instead of st it generates
helper_fullwr for each store within this TB.
3. helper_fullwr calls cpu_physical_memory_write
4. sample_io_write is called and register is changed since the whole thing
is done from within a helper
On Wed, Jul 6, 2016 at 12:04 AM, Peter Maydell <peter.mayd...@linaro.org>
wrote:
> On 5 July 2016 at 21:31, Michael Rolnik <mrol...@gmail.com> wrote:
> > <quote>
> > As Richard says you have problems with trying to write
> > CPU registers from a device anyway, but please consider
> > trying to have some level of abstraction rather than
> > just having the device code reach into the CPU object.
> > The general model here is real hardware and devices, and
> > a real device has no access into the inside workings of
> > another one except via whatever interfaces the other
> > device explicitly provides.
> >
> > (Better still would be if we don't need to do any of this
> > at all, because it gets pretty ugly pretty quickly.
> > The guest has access to its own registers by definition,
> > so having a second way to read and write them via memory
> > is a bit weird.)
> > </quote>
> >
> > The code is already fixed.
>
> I just looked back at the v9 patch, and it is still
> just directly reaching into the CPU object, which is
> what I suggested you do not want to do.
>
> thanks
> -- PMM
>
--
Best Regards,
Michael Rolnik
