qemu-devel
[Top][All Lists]
Advanced

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

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


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v2 00/14] Make Q35 devices closer to Qemu object model.
Date: Wed, 22 Jun 2016 15:24:33 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1


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



reply via email to

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