Re: [Qemu-devel] [PATCH v3 00/22] Steps towards per CPU address-spaces

["Edgar E. Iglesias" <edgar.iglesias@gmail.com>]

On Mon, Jan 13, 2014 at 09:37:23PM +0100, Artyom Tarasenko wrote:
> Hi Edgar,

Hi Artyom,

> 
> On Mon, Jan 13, 2014 at 8:39 AM,  <edgar.iglesias@gmail.com> wrote:
> > From: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com>
> >
> > Hi,
> >
> > I'm looking at modeling systems where multiple CPUs co-exist with
> > different views of their attached buses/devs.
> >
> > With this series I'm trying to take some steps towards having
> > an address-space per CPU.
> 
> This is a very interesting approach. Would it be also possible to have
> multiple address-spaces per CPU?
> At least SPARC emulation would profit from that, the CPUs have
> separate MMUs for data and code.

In general (dma, cpus, etc) it's just a matter of adding more AS props
and have logic within the device to route things to specific ASs depending
on internal state and kind of access.

For DMA capable devs it would be fairly easy with the AS props in place.

To do multiple AS per CPU we would need more refactoring. We could make
the AS passing more top-down or maybe add a target specific callback
with info about the access and let arch specific code return an AS
based on cpu state and kind of access. The latter is probably doable
without too much effort but I can imagine its a bit slower...

This series doesn't reach that far wrt to CPUs but I think it's a step on
the way. We can do more refactoring incrementally. The reason I'm not
aiming at doing it all at once is that I'm afraid the series will get
unmanageable do to the intrusiveness.

I'll try to keep this use-case in mind as we continue.

Thanks,
Edgar



> 
> Artyom
> 
> > It's not complete but good enough for
> > making it possible to model (to some extent) CPU local memories
> > for MicroBlaze systems in emulation mode (TCG). I'm updating the
> > petalogix-ml605 here and will follow-up later with the petalogix-s3adsp.
> >
> > The per-cpu address space is added into the CPUState. I tried to
> > measure performance diff with having it in the CPUState->env.
> > For "normal" and even for IO heavy workloads on linux kernels,
> > the diff is not measurable. I also tested with a tight guest loop
> > that continuously does I/O accesses and there I can see a 2.5% drop in perf.
> > I dont think the runtime type check involved when casting from env to CS
> > will be much of a problem.
> >
> > I've reordered the series and moved the AS props to the end, hoping
> > we can get through the bulk of the series with less controversy and
> > get it commited soon.
> > I've kept the interface with properties to set AddressSpace pointers
> > which I think is the more flexible approach but we can explore other
> > ideas if there are.
> >
> > There is lots of future work needed, for example to transform more of
> > the cpu_* bus accessing functions. To add more usage of AddressSpace
> > properties to pass on address spaces to DMA models. Qtest mechanisms
> > to target specific address spaces, etc...
> >
> > Cheers,
> > Edgar
> >
> > v2 -> v3:
> > Move CPU address-space prop into CPUState level.
> >
> > v1 -> v2:
> > Add braces in cpu_memory_rw_debug.
> > Avoid mixing var/code declarations in tcg_commit.
> > Move per-cpu address space into CPUState.
> > Reorder patch series to add the AS properties last.
> 
> 
> 
> -- 
> Regards,
> Artyom Tarasenko
> 
> linux/sparc and solaris/sparc under qemu blog:
> http://tyom.blogspot.com/search/label/qemu