| Message ID | CAEgOgz6toLuB59qeCL+6O2Ut48-xP42S4zRMBrJn-dHMi9cuxw@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 13 May 2014 00:27, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote: > Ok so here's my plan: This generally all sounds good to me. A slight nit: > QOMify address spaces. So they can be instantiated, reffed etc. > completely aside from the hotplug discussion this greatly helps > connecting bus master devices using proper QOM links. E.G. using > machine-set link properties rather &address_space_memory everywhere. I'm not sure that the thing a bus master exposes to be connected up should be an AddressSpace -- I think it should be a MemoryRegion (more precisely, the code creating the bus-master should create a MemoryRegion and pass it to the bus-master device). 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 create a combined board+SoC view to pass to the CPU object proper. So for consistency 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.) thanks -- PMM -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 13 May 2014 12:07, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote: > On Tuesday, May 13, 2014, Peter Maydell <peter.maydell@linaro.org> wrote: >> I'm not sure that the thing a bus master exposes to be connected >> up should be an AddressSpace -- I think it should be a MemoryRegion >> (more precisely, the code creating the bus-master should create >> a MemoryRegion and pass it to the bus-master device). >> > > So this does alter the current thinking slightly, in that the current DMA > API has devices reffing addr spaces. I think the idea there is to provide > iommu capability? Well, the DMA API generally can mostly remain as-is: that's the API for devices which are bus-masters to use to do the read/write/etc operations. So that kind of device would take a MemoryRegion* representing its view of the world, convert it to an AddressSpace in its realize method, and then use the AS to do DMA as required via the existing API. I haven't looked closely at how we handle IOMMUs currently... >> 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 create a combined board+SoC view to >> pass to the CPU object proper. > > > My thinking here is SoC can create an address space for it's masters to > master (cpu included) and add slave peripherals to its root MR. Both AS and > MR are then exposed to board level by the SoC for board level master and > slaves resp. This seems confused about who creates the address spaces. It doesn't seem very consistent for the object in the middle of the stack (the SoC container) to create them and pass them both up to the CPU and down to the board. The nice thing about "MRs everywhere" is the consistency effect: it's always the lowest layer that creates the container and hands it up to the layer above. > Although if we pull this off without major change its definitely preffered > by me. AS vs MR confusion is an issue. Can we realistically convert all > master AS refs to MR? I can't currently see any reason why it wouldn't work. This will mean we'll typically end up with several ASes which are duplicates (eg if all CPUs in the system have the same view of memory then they'll have their own ASes which all have the same MR root) but IIRC from discussion earlier this isn't a big deal. thanks -- PMM -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- a/hw/microblaze/petalogix_s3adsp1800_mmu.c +++ b/hw/microblaze/petalogix_s3adsp1800_mmu.c @@ -97,6 +97,8 @@ petalogix_s3adsp1800_init(QEMUMachineInitArgs *args) 1, 0x89, 0x18, 0x0000, 0x0, 1); dev = qdev_create(NULL, "xlnx.xps-intc"); + object_property_add_child(qdev_get_machine(), "intc", OBJECT(dev), + &error_abort); But you could have done the whole /machine/unattached/... ugliness