qemu-devel
[Top][All Lists]
Advanced

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

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


From: Edgar E. Iglesias
Subject: Re: [Qemu-devel] [PATCH v4 00/22] Steps towards per CPU address-spaces
Date: Tue, 11 Feb 2014 09:10:55 +1000
User-agent: Mutt/1.5.21 (2010-09-15)

On Sun, Feb 09, 2014 at 02:21:31PM +0000, Peter Maydell wrote:
> On 9 February 2014 13:31, Andreas Färber <address@hidden> wrote:
> > Paolo,
> >
> > Am 03.02.2014 10:44, schrieb Edgar E. Iglesias:
> >> Edgar E. Iglesias (22):
> >>   exec: Make tb_invalidate_phys_addr input an AS
> >>   exec: Make iotlb_to_region input an AS
> >>   exec: Always initialize MemorySection address spaces
> >>   exec: Make memory_region_section_get_iotlb use section AS
> >>   memory: Add MemoryListener to typedefs.h
> >
> > I've been waiting on your review of this series since CPU changes start
> > only with the next patch and I consider most of them a "memory" topic.
> >
> > Do you intend to review them or should I go ahead and queue these on
> > qom-cpu if they compile and don't obviously break things?
> 
> I've just had a look at these, and I think the first part of the series
> (up to and including "exec: Make cpu_memory_rw_debug
> use the CPUs AS") looks good. I didn't check the fine detail
> of all the conversions of the ld/st*_phys changes but they look
> mostly mechanical anyway. So for that set of patches:
> 
> Reviewed-by: Peter Maydell <address@hidden>

Thanks

> 
> I think we could queue that initial set for committal now (via
> your qom tree or paolo's tree) if nobody else has review comments
> to make.
> 
> I'm not so sure about the "find address space by name" and
> what looks like using address space name strings to wire
> address spaces up to CPUs, though. Also I suspect that really
> we ought to be using MemoryRegions for this interface:
> 
> Consider a board model which puts together some RAM and
> devices. It ought to have the same interface for passing this
> up to the CPU whether it's doing so directly or via some SoC
> container device. For the SoC container case, this has to be
> by passing a MemoryRegion, since the SoC will want to add
> some devices of its own to that region. So the interface for
> passing things to the CPU should also be a MemoryRegion
> (which the CPU then turns into an AddressSpace for its own
> internal use.)
> 
> Are there cases involving IOMMUs or some other edgecase
> that mean we might need to pass AddressSpaces around directly?

My thinking was in terms of trying to minimize the amount of
AS structures we create in cases were the nr of master outnumber
the nr of ASs. But there might be ways to achieve being light
even if we dont explicitely pass AS refs around. Will try to get
a chance to look at a MemoryRegion based interface instead
(if no one beats me to it).

Thanks,
Edgar



reply via email to

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