qemu-devel
[Top][All Lists]
Advanced

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

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


From: John Williams
Subject: Re: [Qemu-devel] [RFC] Memory API and fine grained Memory Regions
Date: Sun, 28 Oct 2012 23:37:29 +0000

> -----Original Message-----
> From: Edgar E. Iglesias [mailto:address@hidden
> Sent: Saturday, 27 October 2012 2:12 PM
> To: Peter Crosthwaite
> Cc: address@hidden 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.





reply via email to

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