[Qemu-devel] [RFC] Memory API and fine grained Memory Regions

[Qemu-devel] [RFC] Memory API and fine grained Memory Regions

[Peter Crosthwaite]

In my recent USB series Avi mentioned he wanted to do some work with
the memory API and encourage devices to use the memory API to do
fine-grained register decoding, i.e. each register is its own
MemoryRegion. This has the advantage of getting rid of the symmetric
switch statements in the read and write handlers. The big drawback I
am seeing is however is indexing into the register file. For example
in a device i'm working on ATM I have this read handler for my device
registers:

static uint64_t devcfg_read (void *opaque, hwaddr addr,
        unsigned size)
{
    struct XilinxDevcfg *s = opaque;
    uint32_t ret;

    addr >>= 2;
    switch (addr)
    {
        //TODO: implement any read side effects
    }
    ret = s->regs[addr];
    DB_PRINT("addr=" TARGET_FMT_plx " = %x\n", addr * 4, ret);
    return ret;
}

For actually writing into the device registers, its just uses an array
index, no need to switch (ret = s->regs[addr]). However for my side
effects I will need to populate that switch. If we convert to fine
grained memory regions then the switch goes away and my side effect
become pretty, but my register update becomes ugly as each individual
handler needs to index into s->regs with a constant index for the
actual read.

Is there a way we can have our cake and eat it too? Can we define two
handlers for the one memory region? I have one handler that does the
the read and write (or even just throw down a memory_region_init_ram)
that does the load and store of register data, and a number of
secondary handlers for side effects?

Regards,
Peter

Re: [Qemu-devel] [RFC] Memory API and fine grained Memory Regions

[Gerd Hoffmann]

  Hi,

> For actually writing into the device registers, its just uses an array
> index, no need to switch (ret = s->regs[addr]). However for my side
> effects I will need to populate that switch. If we convert to fine
> grained memory regions then the switch goes away and my side effect
> become pretty, but my register update becomes ugly as each individual
> handler needs to index into s->regs with a constant index for the
> actual read.

In hw/intel-hda.c I went for a simliar approach (predating memory api
though).  There is a struct describing each register.  Which bits are
writable, which bits are write-1-to-clear, what is the state after
reset, what is the offset in IntelHDAState.  Alot of the access logic
can be in generic code then.

There are also (optional) per-register read/write handlers.  read
handlers rarely needed, only for registers generating content on access
such as timers.  write handlers are needed for most registers, but
certainly not all of them.  read-only registers obviously can go
without, likewise registers which hold the dma address of some data
structures.

Feel free to steal ideas there.

cheers,
  Gerd

Re: [Qemu-devel] [RFC] Memory API and fine grained Memory Regions

[Edgar E. Iglesias]

On Fri, Oct 26, 2012 at 05:03:04PM +1000, Peter Crosthwaite wrote:
> In my recent USB series Avi mentioned he wanted to do some work with
> the memory API and encourage devices to use the memory API to do
> fine-grained register decoding, i.e. each register is its own
> MemoryRegion. This has the advantage of getting rid of the symmetric
> switch statements in the read and write handlers. The big drawback I
> am seeing is however is indexing into the register file. For example
> in a device i'm working on ATM I have this read handler for my device
> registers:
> 
> static uint64_t devcfg_read (void *opaque, hwaddr addr,
>         unsigned size)
> {
>     struct XilinxDevcfg *s = opaque;
>     uint32_t ret;
> 
>     addr >>= 2;
>     switch (addr)
>     {
>         //TODO: implement any read side effects
>     }
>     ret = s->regs[addr];
>     DB_PRINT("addr=" TARGET_FMT_plx " = %x\n", addr * 4, ret);
>     return ret;
> }


Hi,

If well designed, most hw has a well designed symtery between regs
that makes things simpler if you can just opencode the decding.
IMO, an mr per reg would just add a massive overhead for no win.
And also, hw implemented decoders look very much like
switch cases in qemu which make things easy to map.

What is the win?

Cheers,
Edgar

Re: [Qemu-devel] [RFC] Memory API and fine grained Memory Regions

[John Williams]

> -----Original Message-----
> From: Edgar E. Iglesias [mailto:edgar.iglesias@gmail.com]
> Sent: Saturday, 27 October 2012 2:12 PM
> To: Peter Crosthwaite
> Cc: qemu-devel@nongnu.org Developers; Avi Kivity; Peter Maydell; John
> Williams
> Subject: Re: [Qemu-devel] [RFC] Memory API and fine grained Memory
> Regions
>
> On Fri, Oct 26, 2012 at 05:03:04PM +1000, Peter Crosthwaite wrote:
> > In my recent USB series Avi mentioned he wanted to do some work with
> > the memory API and encourage devices to use the memory API to do
> > fine-grained register decoding, i.e. each register is its own
> > MemoryRegion. This has the advantage of getting rid of the symmetric
> > switch statements in the read and write handlers. The big drawback I
> > am seeing is however is indexing into the register file. For example
> > in a device i'm working on ATM I have this read handler for my device
> > registers:
> >
> > static uint64_t devcfg_read (void *opaque, hwaddr addr,
> >         unsigned size)
> > {
> >     struct XilinxDevcfg *s = opaque;
> >     uint32_t ret;
> >
> >     addr >>= 2;
> >     switch (addr)
> >     {
> >         //TODO: implement any read side effects
> >     }
> >     ret = s->regs[addr];
> >     DB_PRINT("addr=" TARGET_FMT_plx " = %x\n", addr * 4, ret);
> >     return ret;
> > }
>
>
> IMO, an mr per reg would just add a massive overhead for no win.

I tend to agree with Edgar here - QEMU has a careful line to walk between being an emulator and an RTL simulator.

Any WAG on the runtime overhead of a mem region per register vs a switch-based decodes in read/write handlers?

John



This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

Re: [Qemu-devel] [RFC] Memory API and fine grained Memory Regions

[Avi Kivity]

On 10/29/2012 01:37 AM, John Williams wrote:

>> IMO, an mr per reg would just add a massive overhead for no win.
> 
> I tend to agree with Edgar here - QEMU has a careful line to walk between being an emulator and an RTL simulator.
> 
> Any WAG on the runtime overhead of a mem region per register vs a switch-based decodes in read/write handlers?
> 

Actually a region-per-register can be faster, since the subpage logic
will dispatch the access directly to the handler, instead of going first
to the device handler, then following the switch.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [RFC] Memory API and fine grained Memory Regions

[Avi Kivity]

On 10/27/2012 06:12 AM, Edgar E. Iglesias wrote:

> 
> Hi,
> 
> If well designed, most hw has a well designed symtery between regs
> that makes things simpler if you can just opencode the decding.
> IMO, an mr per reg would just add a massive overhead for no win.
> And also, hw implemented decoders look very much like
> switch cases in qemu which make things easy to map.
> 
> What is the win?

As Gerd says, stuff like automatic read handlers and write-protected
bits can be done declaratively instead of programatically.


-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [RFC] Memory API and fine grained Memory Regions

[Edgar E. Iglesias]

On Mon, Oct 29, 2012 at 06:34:37PM +0200, Avi Kivity wrote:
> On 10/29/2012 01:37 AM, John Williams wrote:
> 
> >> IMO, an mr per reg would just add a massive overhead for no win.
> > 
> > I tend to agree with Edgar here - QEMU has a careful line to walk between being an emulator and an RTL simulator.
> > 
> > Any WAG on the runtime overhead of a mem region per register vs a switch-based decodes in read/write handlers?
> > 
> 
> Actually a region-per-register can be faster, since the subpage logic
> will dispatch the access directly to the handler, instead of going first
> to the device handler, then following the switch.


I understood the suggestion as if you would need to allocate a MemoryRegion
per reg. That sounds to me like a massive overhead. Many of these regs
hold pure configuration state and have no side effects. Some devices map
huge amount of address space and use bits in the addresses to decide the
effect of the access. At minimum you'd have to allow for old style decoding
without forcing the device to put a function pointer to the same func for
every address.

But as long as it is optional and it doesn't slow things down, I agree
that some device models will benefit.

Cheers,
Edgar