From: Paolo Bonzini <pbonzini@redhat.com>
To: Efimov Vasily <real@ispras.ru>, qemu-devel@nongnu.org
Cc: "John Snow" <jsnow@redhat.com>,
qemu-block@nongnu.org, "Gerd Hoffmann" <kraxel@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Kevin Wolf" <kwolf@redhat.com>, "Max Reitz" <mreitz@redhat.com>,
"Richard Henderson" <rth@twiddle.net>,
"Eduardo Habkost" <ehabkost@redhat.com>,
"Hervé Poussineau" <hpoussin@reactos.org>,
"Markus Armbruster" <armbru@redhat.com>,
"Marcel Apfelbaum" <marcel@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Kirill Batuzov" <batuzovk@ispras.ru>
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 [thread overview]
Message-ID: <e4e2c00f-1241-faeb-da2e-e63f5147515e@redhat.com> (raw)
In-Reply-To: <1466598298-21214-1-git-send-email-real@ispras.ru>
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
next prev parent reply other threads:[~2016-06-22 13:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-22 12:24 [Qemu-devel] [PATCH v2 00/14] Make Q35 devices closer to Qemu object model Efimov Vasily
2016-06-22 12:24 ` [Qemu-devel] [PATCH v2 01/14] ide: move headers to include folder Efimov Vasily
2016-06-22 12:24 ` [Qemu-devel] [PATCH v2 02/14] pcspk: convert "pit" property type from ptr to link Efimov Vasily
2016-06-22 12:24 ` [Qemu-devel] [PATCH v2 03/14] vmport: identify vmport type by macro TYPE_VMPORT Efimov Vasily
2016-06-22 12:24 ` [Qemu-devel] [PATCH v2 04/14] pflash: make TYPE_CFI_PFLASH0{1, 2} macros public Efimov Vasily
2016-06-22 12:24 ` [Qemu-devel] [PATCH v2 05/14] Q35: implement property interfece to several parameters Efimov Vasily
2016-06-22 12:24 ` [Qemu-devel] [PATCH v2 06/14] pc_q35: configure Q35 instance using properties Efimov Vasily
2016-06-22 12:24 ` [Qemu-devel] [PATCH v2 07/14] pckbd: handle A20 IRQ as GPIO Efimov Vasily
2016-06-22 12:24 ` [Qemu-devel] [PATCH v2 08/14] port92: " Efimov Vasily
2016-06-22 12:24 ` [Qemu-devel] [PATCH v2 09/14] ICH9 SMB: make TYPE_ICH9_SMB_DEVICE macro public Efimov Vasily
2016-06-22 12:24 ` [Qemu-devel] [PATCH v2 10/14] ICH9 LPC: handle GSI as qdev GPIO Efimov Vasily
2016-06-22 12:24 ` [Qemu-devel] [PATCH v2 11/14] ICH9 LPC: move call of isa_bus_irqs to 'realize' method Efimov Vasily
2016-06-22 12:24 ` [Qemu-devel] [PATCH v2 12/14] isa: introduce wrapper isa_connect_gpio_out Efimov Vasily
2016-06-22 12:24 ` [Qemu-devel] [PATCH v2 13/14] MC146818 RTC: add GPIO access to output IRQ Efimov Vasily
2016-06-22 12:24 ` [Qemu-devel] [PATCH v2 14/14] ICH9 LPC: configure PCI IRQs routing internally Efimov Vasily
2016-06-22 13:24 ` Paolo Bonzini [this message]
2016-06-22 18:27 ` [Qemu-devel] [PATCH v2 00/14] Make Q35 devices closer to Qemu object model Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e4e2c00f-1241-faeb-da2e-e63f5147515e@redhat.com \
--to=pbonzini@redhat.com \
--cc=armbru@redhat.com \
--cc=batuzovk@ispras.ru \
--cc=ehabkost@redhat.com \
--cc=hpoussin@reactos.org \
--cc=jsnow@redhat.com \
--cc=kraxel@redhat.com \
--cc=kwolf@redhat.com \
--cc=marcel@redhat.com \
--cc=mreitz@redhat.com \
--cc=mst@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=real@ispras.ru \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).