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: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores
Date: Tue, 5 Jul 2016 23:24:30 +0100

On 5 July 2016 at 22:41, Michael Rolnik <address@hidden> 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

Thanks for the data sheet links. Looking at
them, the access to register contents via
load/store instructions definitely seems to be
part of the CPU itself, not a device or something
at board level. So I think it should be handled
by code that's suitably named (ie not "sample")
and in the right place in our source tree.

We have two models for this kind of thing:
where the CPU has devices that are kind of built in,
but still clearly separate (like timer devices some of
the ARM CPUs have), we've done this by having device
models for them in hw/timer etc, with a "put the
devices in the right places" container object in hw/cpu.

The other model, which I think is a better fit for these AVR
cores, is how target-i386 handles its SMM memory. Basically
in the CPU's realize function you can set up the CPU's
address space to be a container which has within it
(a) the magic MemoryRegion which handles the accesses
to cpu registers
(b) the "system address space", ie the outside world
I think this will work best because it keeps the
access to the cpu env and its register state within
the target-avr/ code, and because the access functions
for handling accesses in this low address space are
so simple, and so tightly coupled to the special
handling of fullwr that you describe above.

The x86 code is in x86_cpu_realizefn(). (You don't
need to postpone creating the second memory region
until machine-done the way that code does, though.)

thanks
-- PMM



reply via email to

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