Re: [Qemu-devel] [PATCH v2 00/14] Make Q35 devices closer to Qemu object model.

[Michael S. Tsirkin]

On Wed, Jun 22, 2016 at 03:24:33PM +0200, Paolo Bonzini wrote:
> 
> 
> On 22/06/2016 14:24, Efimov Vasily wrote:
> > The patch series makes several devices closer to Qemu object model.
> > 
> > I am developing a tool that automatize creation of device and machine 
> > models.
> > 
> > Recently, I've take part in development of several models. And I noticed 
> > that
> > a significant part of code is same. The examples are:
> > - Each device represented by a header and a source.
> > - The device or machine class is described by a set of callbacks containing 
> > in
> > TypeInfo structure.
> > - Each TypeInfo structure is accounted by a register function.
> > - A register function is sheduled by a type_init macro.
> > - Class and state structures of an inherited type are prepended by ones of 
> > the
> > parent type.
> > - A device must have VM state description.
> > - A device or a machine can have properties.
> > - A device can use internal APIs such as: timer, chardev, blockdev, IRQ,
> > system bys memory and port mapping, PCI BARs, PCI MSI(X), etc.
> > - A machine consists of devices and memory tree. Devices are linked by IRQs 
> > and
> > buses and assigned property values.
> > - All of the above should follow the Qemu coding style.
> > 
> > For every listed item can be generated a stub code. All stubs can be 
> > generated
> > with respect to each other forming compileable device (or machine). Ideally,
> > a programmer have to implement custom device/machine logic and to assign
> > meaningful names to variables, functions, macroses etc. using a refactoring
> > tool.
> > 
> > Of cource, a device/machine description for the tool has to be significantly
> > smaller than the code the tool produced. A GUI constructor is preferred too.
> > 
> > I've chosed Q35 machine to test the tool. The Q35 is one of the most 
> > complex boards. I have implemented 64-bit CPU, soft MMU, 1GB RAM, 1 HDD,
> > PCI, USB machine variant. Most of devices is instantiated using the object
> > model. Some logic (I/O port 80, I/O port F0, A20 line) is dedicated to new
> > devices. The stubs for thay is also generated by the tool.
> > 
> > In course of implementing Q35 I've noticed that some device models does not
> > follow Qemu object model close enough. The patch series is desined to make 
> > them
> > closer.
> > 
> > Change log:
> > 
> > v1 -> v2:
> > A patch was added after 11-th one. The patch introduces function
> > isa_connect_gpio_out needed by new version of consequent patch.
> > 
> >  01: Git global option diff.renames was set true to generate the patch 
> > avoiding
> > checkpatch.pl issues.
> > 
> >  02, 05: qdev_prop_allow_set_link_before_realize is used instead of
> > object_property_allow_set_link.
> > 
> >  07, 08: Named GPIO was used for a20 line.
> > 
> >  10, 11: The patches were rebased against the patch series
> > https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg05619.html
> > 
> >  10: Named GPIO is used for gsi. The name is "gsi" with alias ICH9_GPIO_GSI.
> > 
> >  12: It's a new patch. The patch introduces function isa_connect_gpio_out.
> > 
> >  13 (previously 12): Use isa_connect_gpio_out instead of isa_init_irq.
> 
> I have queued patches 1-13, as said before I'm not sure of patch 14 and
> I want to think about it some more. :)
> 
> Paolo

You can add my
Reviewed-by: Michael S. Tsirkin <address@hidden>
if you wish.

I'll comment on 14 separately.

-- 
MST