Peter, I think I will do the following 1. helper fullwr will modify CPU owned registers by itself and call cpu_outb for non owned registers 2. I will add helper fullrd that will behave like fullwr. 3. any board/model will have to install a device in the io space for registers not owned by the CPU.
it will make sample_io.c device obsolete and make (future) devices more independent. what do you think? Could you please point me to an example how to create a device in the io space? Michael On Wed, Jul 6, 2016 at 12:19 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 6 July 2016 at 00:55, Richard Henderson <r...@twiddle.net> wrote: > > On 07/05/2016 02:41 PM, Michael Rolnik wrote: > >> > >> 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 > > > > > > It is my opinion that helper_fullwr should simply modify the respective > > registers. There's no point adding two more layers of calls. > > I was also wondering if it would be simpler to also direct > reads to a helper_fullrd, rather than having the write > handling in the helper and the read handling in a device > that's rather distant from it in a source-code-location sense. > (Well, it would be simpler, also a bit slower, but how much > do we care about the latter here?) > > thanks > -- PMM > -- Best Regards, Michael Rolnik
