Skip to contentSkip to conversation

KVM call agenda for 2014-05-13

DISCUSSION Juan Quintela 4 participants 10 messages May 12, 2014 – May 13, 2014 KVM

lore
Share & tools
lore

Juan Quintela

author
#0 lore raw

Hi

Please, send any topic that you are interested in covering.

- QOMifying both Memory regions and GPIOs and attaching them via QOM links (Peter Crosthwaite)

Thanks, Juan.

Call details:

15:00 CEST
13:00 UTC
09:00 EDT

Every two weeks

If you need phone number details, contact me privately.

#1 lore raw
Quoted 4 lines · Juan Quintela

Please, send any topic that you are interested in covering.

- QOMifying both Memory regions and GPIOs and attaching them via QOM links (Peter Crosthwaite)

Is there some further useful material on-list on this subject, or are we just going to have a rerun of the discussions on the last two calls?

thanks
-- PMM

#2 lore raw
Quoted 10 lines · Peter Maydell
Quoted 4 lines · Juan Quintela

Please, send any topic that you are interested in covering.

- QOMifying both Memory regions and GPIOs and attaching them via QOM links (Peter Crosthwaite)

Is there some further useful material on-list on this subject, or are we just going to have a rerun of the discussions on the last two calls?

I have any ugly work-in-progress series. TBH I was going to wait for discussion outcomes. Want me to RFC it?

Regards,
Peter

Quoted 3 lines

thanks
-- PMM

#3 lore raw
Quoted 7 lines · Peter Crosthwaite
Quoted 6 lines · Peter Maydell
Quoted 4 lines · Juan Quintela

Please, send any topic that you are interested in covering.

- QOMifying both Memory regions and GPIOs and attaching them via QOM links (Peter Crosthwaite)

Quoted 6 lines
Quoted 3 lines

Is there some further useful material on-list on this subject, or are we just going to have a rerun of the discussions on the last two calls?

I have any ugly work-in-progress series. TBH I was going to wait for discussion outcomes. Want me to RFC it?

I don't think you necessarily need to post code, but maybe a writeup of current status/options would be useful to try to make the on-call discussion productive?

thanks
-- PMM

#4 lore raw
Quoted 12 lines · Peter Maydell
Quoted 10 lines · Peter Crosthwaite
Quoted 9 lines · Peter Maydell
Quoted 4 lines · Juan Quintela

Please, send any topic that you are interested in covering.

- QOMifying both Memory regions and GPIOs and attaching them via QOM links (Peter Crosthwaite)

Is there some further useful material on-list on this subject, or are we just going to have a rerun of the discussions on the last two calls?

Quoted 7 lines
Quoted 2 lines

I have any ugly work-in-progress series. TBH I was going to wait for discussion outcomes. Want me to RFC it?

I don't think you necessarily need to post code, but maybe a writeup of current status/options would be useful to try to make the on-call discussion productive?

Ok so here's my plan:

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.

QOMify Memory regions. So they are added as child objects to devices. Devices can do this explicitly in instance_init, or sysbus can handle it - sysbus_init_mmio parents the memory region to the device to transparently convert all existing devs to compliance.

The address and container (the memory region containing this one as a subregion) of memory regions are QOM properties, of type integer and link resp. Setting the properties does the memory_region_add_subregion().

The root address space is parented the machine in exec.c. This give the address space a canonical path. Its root memory region is a child of it, so it also is referencable by canon path.

Sysbus IRQ are abandoned completely and re-implemented as named GPIOs. The sysbus irq API remains and makes this transition behind-the-scenes.

GPIOs are QOMified. qemu_allocate_irqs does the object_new() etc. IRQ inputs are then added as child objects of the instantiating device. Handled by qemu_init_gpio_in_named(). gpio_outs are setup as links. qdev_connect_gpio_out does the linkage.

QOM is patched to allow setting of a device's child's properties from a ref to the parent. Best illustrated by example (see below).

Anyways without a single patch to the command line interface, HMP, QMP, or implementing any machine specific hotplug or adding any new special busses, this works:

-device xlnx.xps-timer,\
sysbus-mr-0.container=/machine/sysmem/root-mr,\
sysbus-mr-0.addr=0x83c00000,\
sysbus-irq-0=/machine/intc/unnamed-gpio-0

All the other ways to create devices should just work, this is not a command line specific feature.

Note, I edited my machine model to sanitize the canonical path of the interrupt controller:

hw/microblaze/petalogix_s3adsp1800_mmu.c +2 -0
@@ -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 too. If you name the irq inputs in the intc with my named GPIO series stuff the unnamed-gpio ugliness goes away too. If you throw away sysbus and do the memory-regions and IRQs naming the child objects properly the ugly sysbus names can de dispensed with too. But thats a big tree-wide to name everything properly.

Regards,
Peter

Quoted 3 lines

thanks
-- PMM

#5 lore raw
Quoted 1 line · Peter Crosthwaite

Ok so here's my plan:

This generally all sounds good to me. A slight nit:

Quoted 4 lines

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

#6 lore raw
Quoted 11 lines · Peter Maydell
Quoted 1 line · On 13 May 2014 00:27, Peter Crosthwaite <[email protected]<javascrip…

Ok so here's my plan:

This generally all sounds good to me. A slight nit:

Quoted 4 lines

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.

Quoted 6 lines

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?

Quoted 7 lines

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.

Quoted 6 lines

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.)

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?

Regards
Peter

Quoted 4 lines

thanks
-- PMM

#7 lore raw
Quoted 10 lines · Peter Crosthwaite
Quoted 5 lines · Peter Maydell

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...

Quoted 9 lines
Quoted 7 lines

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.

Quoted 4 lines

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.

Quoted 3 lines

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

#8 lore raw
In reply to Peter Maydell

Am 12.05.2014 13:09, schrieb Peter Maydell:

Quoted 12 lines · Peter Crosthwaite
Quoted 10 lines · Peter Maydell
Quoted 9 lines · Juan Quintela
Quoted 4 lines

Please, send any topic that you are interested in covering.

- QOMifying both Memory regions and GPIOs and attaching them via QOM links (Peter Crosthwaite)

Is there some further useful material on-list on this subject, or are we just going to have a rerun of the discussions on the last two calls?

Quoted 6 lines
Quoted 2 lines

I have any ugly work-in-progress series. TBH I was going to wait for discussion outcomes. Want me to RFC it?

I don't think you necessarily need to post code, but maybe a writeup of current status/options would be useful to try to make the on-call discussion productive?

Here's my WIP qemu_irq conversion, so that we don't discuss IRQs for the third time in a row without results:

https://github.com/afaerber/qemu-cpu/commits/qom-irq

make check passes, not further tested yet.
As a side effect, cleaning up the leaks turned out rather easy.

The only remaining users of qemu_free_irqs() are serial-pci.c and ipack.c. If we can get rid of it altogether, the hacks for freeing the memory chunk could be avoided.

Regards,
Andreas

Signature · 2 lines
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
#9 lore raw
Quoted 19 lines · Andreas Färber

Am 12.05.2014 13:09, schrieb Peter Maydell:

Quoted 1 line

On 12 May 2014 11:30, Peter Crosthwaite <[email protected]<javascript:;>>

Quoted 1 line · wrote:
Quoted 1 line

On Mon, May 12, 2014 at 7:44 PM, Peter Maydell <

Quoted 1 line · [email protected] <javascript:;>> wrote:
Quoted 1 line
Quoted 1 line

On 12 May 2014 10:10, Juan Quintela <[email protected]<javascript:;>>

Quoted 12 lines · wrote:
Quoted 11 lines
Quoted 8 lines
Quoted 4 lines

Please, send any topic that you are interested in covering.

- QOMifying both Memory regions and GPIOs and attaching them via QOM links (Peter Crosthwaite)

Is there some further useful material on-list on this subject, or are we just going to have a rerun of the discussions on the last two calls?

I have any ugly work-in-progress series. TBH I was going to wait for discussion outcomes. Want me to RFC it?

Quoted 8 lines
Quoted 3 lines

I don't think you necessarily need to post code, but maybe a writeup of current status/options would be useful to try to make the on-call discussion productive?

Here's my WIP qemu_irq conversion, so that we don't discuss IRQs for the third time in a row without results:

https://github.com/afaerber/qemu-cpu/commits/qom-irq

Same basic idea as my wip series. No conflict of design at all. I've done some stuff around parenting irqs to their devs that would build onto this.

regards,
Peter

Quoted 16 lines

make check passes, not further tested yet.
As a side effect, cleaning up the leaks turned out rather easy.

The only remaining users of qemu_free_irqs() are serial-pci.c and ipack.c. If we can get rid of it altogether, the hacks for freeing the memory chunk could be avoided.

Regards,
Andreas

--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg