KVM call agenda for 2014-05-13

KVM call agenda for 2014-05-13

[Juan Quintela]

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.

[Qemu-devel] KVM call agenda for 2014-05-13

[Juan Quintela]

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.

Re: [Qemu-devel] KVM call agenda for 2014-05-13

[Peter Maydell]

On 12 May 2014 10:10, Juan Quintela <quintela@redhat.com> wrote:
> 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

Re: [Qemu-devel] KVM call agenda for 2014-05-13

[Peter Maydell]

On 12 May 2014 10:10, Juan Quintela <quintela@redhat.com> wrote:
> 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

Re: [Qemu-devel] KVM call agenda for 2014-05-13

[Peter Crosthwaite]

On Mon, May 12, 2014 at 7:44 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 12 May 2014 10:10, Juan Quintela <quintela@redhat.com> wrote:
>> 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

> thanks
> -- PMM
>

Re: [Qemu-devel] KVM call agenda for 2014-05-13

[Peter Crosthwaite]

On Mon, May 12, 2014 at 7:44 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 12 May 2014 10:10, Juan Quintela <quintela@redhat.com> wrote:
>> 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

> thanks
> -- PMM
>

Re: [Qemu-devel] KVM call agenda for 2014-05-13

[Peter Maydell]

On 12 May 2014 11:30, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
> On Mon, May 12, 2014 at 7:44 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 12 May 2014 10:10, Juan Quintela <quintela@redhat.com> wrote:
>>> 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?

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

Re: [Qemu-devel] KVM call agenda for 2014-05-13

[Peter Maydell]

On 12 May 2014 11:30, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
> On Mon, May 12, 2014 at 7:44 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 12 May 2014 10:10, Juan Quintela <quintela@redhat.com> wrote:
>>> 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?

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

Re: [Qemu-devel] KVM call agenda for 2014-05-13

[Peter Crosthwaite]

On Mon, May 12, 2014 at 9:09 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 12 May 2014 11:30, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
>> On Mon, May 12, 2014 at 7:44 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>>> On 12 May 2014 10:10, Juan Quintela <quintela@redhat.com> wrote:
>>>> 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?
>
> 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:

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

> thanks
> -- PMM
>

Re: [Qemu-devel] KVM call agenda for 2014-05-13

[Peter Maydell]

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

Re: KVM call agenda for 2014-05-13

[Peter Crosthwaite]

[-- Attachment #1: Type: text/plain, Size: 1997 bytes --]

On Tuesday, May 13, 2014, Peter Maydell <peter.maydell@linaro.org> wrote:

> On 13 May 2014 00:27, Peter Crosthwaite <peter.crosthwaite@xilinx.com<javascript:;>>
> 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).
>
>
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?


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


> 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


> thanks
> -- PMM
>
>

[-- Attachment #2: Type: text/html, Size: 2998 bytes --]

Re: [Qemu-devel] KVM call agenda for 2014-05-13

[Peter Crosthwaite]

[-- Attachment #1: Type: text/plain, Size: 1997 bytes --]

On Tuesday, May 13, 2014, Peter Maydell <peter.maydell@linaro.org> wrote:

> On 13 May 2014 00:27, Peter Crosthwaite <peter.crosthwaite@xilinx.com<javascript:;>>
> 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).
>
>
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?


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


> 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


> thanks
> -- PMM
>
>

[-- Attachment #2: Type: text/html, Size: 2998 bytes --]

Re: [Qemu-devel] KVM call agenda for 2014-05-13

[Peter Maydell]

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

Re: [Qemu-devel] KVM call agenda for 2014-05-13

[Peter Maydell]

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

Re: [Qemu-devel] KVM call agenda for 2014-05-13

[Andreas Färber]

Am 12.05.2014 13:09, schrieb Peter Maydell:
> On 12 May 2014 11:30, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
>> On Mon, May 12, 2014 at 7:44 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>>> On 12 May 2014 10:10, Juan Quintela <quintela@redhat.com> wrote:
>>>> 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?
> 
> 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

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

Re: [Qemu-devel] KVM call agenda for 2014-05-13

[Andreas Färber]

Am 12.05.2014 13:09, schrieb Peter Maydell:
> On 12 May 2014 11:30, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
>> On Mon, May 12, 2014 at 7:44 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>>> On 12 May 2014 10:10, Juan Quintela <quintela@redhat.com> wrote:
>>>> 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?
> 
> 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

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

Re: KVM call agenda for 2014-05-13

[Peter Crosthwaite]

[-- Attachment #1: Type: text/plain, Size: 1918 bytes --]

On Tuesday, May 13, 2014, Andreas Färber <afaerber@suse.de> wrote:

> Am 12.05.2014 13:09, schrieb Peter Maydell:
> > On 12 May 2014 11:30, Peter Crosthwaite <peter.crosthwaite@xilinx.com<javascript:;>>
> wrote:
> >> On Mon, May 12, 2014 at 7:44 PM, Peter Maydell <
> peter.maydell@linaro.org <javascript:;>> wrote:
> >>> On 12 May 2014 10:10, Juan Quintela <quintela@redhat.com<javascript:;>>
> wrote:
> >>>> 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?
> >
> > 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


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

[-- Attachment #2: Type: text/html, Size: 2833 bytes --]

Re: [Qemu-devel] KVM call agenda for 2014-05-13

[Peter Crosthwaite]

[-- Attachment #1: Type: text/plain, Size: 1918 bytes --]

On Tuesday, May 13, 2014, Andreas Färber <afaerber@suse.de> wrote:

> Am 12.05.2014 13:09, schrieb Peter Maydell:
> > On 12 May 2014 11:30, Peter Crosthwaite <peter.crosthwaite@xilinx.com<javascript:;>>
> wrote:
> >> On Mon, May 12, 2014 at 7:44 PM, Peter Maydell <
> peter.maydell@linaro.org <javascript:;>> wrote:
> >>> On 12 May 2014 10:10, Juan Quintela <quintela@redhat.com<javascript:;>>
> wrote:
> >>>> 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?
> >
> > 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


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

[-- Attachment #2: Type: text/html, Size: 2833 bytes --]