qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores


From: Michael Rolnik
Subject: Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores
Date: Wed, 6 Jul 2016 12:36:58 +0300

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 <address@hidden>
wrote:

> On 6 July 2016 at 00:55, Richard Henderson <address@hidden> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]