From: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
To: "Andreas Färber" <afaerber@suse.de>
Cc: mst@redhat.com, qemu-trivial <qemu-trivial@nongnu.org>,
qemu-devel@nongnu.org, Blue Swirl <blauwirbel@gmail.com>,
Anthony Liguori <anthony@codemonkey.ws>,
pbonzini@redhat.com,
"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [Qemu-devel] [PATCH v2 00/30] PCI: Cleanup legacy casts in device land -- ANN: qom-next revived
Date: Mon, 1 Jul 2013 14:33:35 +1000 [thread overview]
Message-ID: <CAEgOgz4XdjfpSXh36zKkFvfsaTArRhMYPODLhk82pDnQOOk-+w@mail.gmail.com> (raw)
In-Reply-To: <51D00BF1.5070900@suse.de>
Hi Andreas,
On Sun, Jun 30, 2013 at 8:44 PM, Andreas Färber <afaerber@suse.de> wrote:
> Hi Peter,
>
> Am 24.06.2013 08:49, schrieb peter.crosthwaite@xilinx.com:
>> From: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
>>
>> There are a number of different cast implementations from various
>> stages of QEMU development out in device model land. This series cleans
>> up the ones involving TYPE_PCI_DEVICE to consistently use proper QOM
>> casts for both up and down casts.
>>
>> Some were easy, some needed QOM cast macros which are added as
>> appropriate.
>>
>> Following the recent discussion RE performance consequences of QOM
>> casts, im interested in any reports of possible performance regressions
>> here, although I am hoping that Anthony current efforts to improve
>> QOM casting efficiency make this a non-issue.
>
> While I did not run extensive benchmarks, state of the discussion
> between Paolo, Anthony and me, I believe, was that it can be considered
> okay to use QOM casts "everywhere" consistently now, but we should not
> use casts where they are unnecessary (i.e., only where we change type).
> E.g., http://patchwork.ozlabs.org/patch/255367/
>
> I have therefore dropped some opaque casts where the type on both sides
> of void* matched (for an up-/downcast I do prefer the cast for safety).
>
> Anyway, if we get this merged early, then there is still time for more
> benchmarking/optimizations during Soft Freeze IMO.
> Maybe our staging tree will facilitate testing, too. ;)
>
>> Changed since V1:
>> Removed hunks which macroified VMSD names
>> Dropped virtio/virtio.pci patch
>> Rebased
>>
>>
>> Peter Crosthwaite (30):
>> net/e1000: QOM Upcast Sweep
>> net/rtl8139: QOM Upcast Sweep
>> net/pcnet-pci: QOM Upcast Sweep
>> usb/hcd-xhci: QOM Upcast Sweep
>> scsi/lsi53c895a: QOM Upcast Sweep
>> scsi/megasas: QOM Upcast Sweep
>> scsi/esp-pci: QOM Upcast Sweep
>> ide/ich: QOM Upcast Sweep
>> ide/piix: QOM casting sweep
>> acpi/piix4: QOM Upcast Sweep
>> misc/pci-testdev: QOM Upcast Sweep
>> virtio/vmware_vga: QOM casting sweep
>> misc/ivshmem: QOM Upcast Sweep
>> xen/xen_platform: QOM casting sweep
>
> As requested, I've started picking up QOM type/cast/realize patches on:
>
> git://github.com/afaerber/qemu-cpu.git qom-next
Perhaps this is becoming the "qom-devices" queue?
> https://github.com/afaerber/qemu-cpu/commits/qom-next
>
> (Not to be confused with my qom-cpu / qom-cpu-next CPU trees.)
>
> If anyone wishes to contribute patches against that tree, please
> indicate so with --subject-prefix="PATCH qom-next ...".
>
> As a matter of personal taste and consistency, I've used the gtk-doc
> notation DO_UPCAST() wherever I stumbled over it in commit messages.
>
> I've queued all patches above except for ide/piix (09/30) and had
> comments and/or minor changes for some of them. Noticing some
> incompleteness, I will reiterate over them.
>
I think the incompleteness comes from the fact that my series is only
worrying about type PCI_DEVICE. I have left alone QOM cast issues for
casts that are not to/from or through TYPE_PCI_DEVICE, so there are
instances where a QOM cast macro may be introduces but not used.
> Whether I send a pull when we're all happy with it or whether we let
> submaintainers pick/pull by subsystem at some point doesn't matter to
> me, as long as we can join efforts to make QOM realize reality soon. :)
>
I think getting it all into one giant queue then we can centralise
testing a little better.
>> isa/*: QOM casting sweep
>> pci/*: QOM casting sweep
>> pci-bridge/pci_bridge_dev: Don't use DO_UPCAST
>> pci-bridge/*: substitute ->qdev casts with DEVICE()
>> pci/pci_bridge: substitute ->qdev casts with DEVICE()
>> misc/vfio: substitute ->qdev casts with DEVICE()
>> net/eepro100: substitute ->qdev casts with DEVICE()
>> net/ne2000: substitute ->qdev casts with DEVICE()
>> usb/*: substitute ->qdev casts with DEVICE()
>> watchdog/wdt_i6300esb: substitute ->qdev casts with DEVICE()
>> scsi/vmw_pvscsi: substitute ->qdev casts with DEVICE()
>> i2c/smbus_ich9: substitute ->qdev casts with DEVICE()
>> ide/cmd646: substitute ->qdev casts with DEVICE()
>> ide/via: substitute ->qdev casts with DEVICE()
>> pci-host/*: substitute ->qdev casts with DEVICE()
>> i386/*: substitute ->qdev casts with DEVICE()
>
> These patches seem more "sloppy" while not reaching a clear goal such as
> dropping a macro or renaming PCIDevice::qdev, so I'd prefer to get open
> issues sorted out before rushing ahead with half-done conversions.
> Functionally everything I've seen so far looked fine though.
>
> But maybe I'm missing something? What exactly was the motivation behind
> the series? Do you have a follow-up?
>
I have an experimental series out-of-tree (change the parent type of
TYPE_PCI_DEVICE to TYPE_SYSBUS) to remove the need to coreify devices
for use as both sysbus and PCI (e.g. EHCI). These casts get in the way
of that series.
I really want to make it clear though, that this series is legitimate
cleanup without that goal, so I didn't want to tangle this series in
that much-longer discussion.
So this series specifically is a compile bug chase on:
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index 6ef1f97..5f607b3 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -217,7 +217,6 @@ typedef void (*MSIVectorPollNotifier)(PCIDevice *dev,
unsigned int vector_end);
struct PCIDevice {
- DeviceState qdev;
/* PCI config space */
uint8_t *config;
FWIW, one could actually remove all parent_obj fields from QOM structs
(just like this) and the tree should compile, good way to catch all
legacy casts.
Regards,
Peter
> Regards,
> Andreas
>
>>
>> hw/acpi/piix4.c | 31 +++++++++++++++++--------------
>> hw/display/vmware_vga.c | 13 ++++++++-----
>> hw/i2c/smbus_ich9.c | 2 +-
>> hw/i386/kvm/pci-assign.c | 21 ++++++++++++---------
>> hw/i386/pc.c | 3 ++-
>> hw/i386/pc_piix.c | 4 ++--
>> hw/i386/pc_q35.c | 4 ++--
>> hw/ide/ahci.h | 5 +++++
>> hw/ide/cmd646.c | 8 ++++----
>> hw/ide/ich.c | 10 +++++-----
>> hw/ide/piix.c | 8 ++++----
>> hw/ide/via.c | 4 ++--
>> hw/isa/i82378.c | 8 ++++----
>> hw/isa/lpc_ich9.c | 6 +++---
>> hw/misc/ivshmem.c | 18 +++++++++++-------
>> hw/misc/pci-testdev.c | 11 ++++++++---
>> hw/misc/vfio.c | 4 ++--
>> hw/net/e1000.c | 18 ++++++++++++------
>> hw/net/eepro100.c | 14 ++++++++------
>> hw/net/ne2000.c | 6 ++++--
>> hw/net/pcnet-pci.c | 14 +++++++++-----
>> hw/net/rtl8139.c | 26 ++++++++++++++++++--------
>> hw/pci-bridge/dec.c | 2 +-
>> hw/pci-bridge/i82801b11.c | 2 +-
>> hw/pci-bridge/ioh3420.c | 2 +-
>> hw/pci-bridge/pci_bridge_dev.c | 2 +-
>> hw/pci-bridge/xio3130_downstream.c | 2 +-
>> hw/pci-bridge/xio3130_upstream.c | 2 +-
>> hw/pci-host/apb.c | 4 ++--
>> hw/pci-host/q35.c | 4 ++--
>> hw/pci/pci-hotplug.c | 18 ++++++++++--------
>> hw/pci/pci.c | 17 +++++++++--------
>> hw/pci/pci_bridge.c | 7 ++++---
>> hw/pci/pcie.c | 4 ++--
>> hw/pci/shpc.c | 8 ++++----
>> hw/scsi/esp-pci.c | 14 +++++++++-----
>> hw/scsi/lsi53c895a.c | 26 ++++++++++++++++----------
>> hw/scsi/megasas.c | 15 ++++++++++-----
>> hw/scsi/vmw_pvscsi.c | 2 +-
>> hw/usb/hcd-ehci-pci.c | 13 ++++++++-----
>> hw/usb/hcd-ohci.c | 2 +-
>> hw/usb/hcd-uhci.c | 2 +-
>> hw/usb/hcd-xhci.c | 19 +++++++++++++------
>> hw/watchdog/wdt_i6300esb.c | 2 +-
>> hw/xen/xen_platform.c | 28 ++++++++++++++++------------
>> 45 files changed, 258 insertions(+), 177 deletions(-)
>>
>
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
>
next prev parent reply other threads:[~2013-07-01 4:33 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-24 6:49 [Qemu-devel] [PATCH v2 00/30] PCI: Cleanup legacy casts in device land peter.crosthwaite
2013-06-24 6:50 ` [Qemu-devel] [PATCH v2 01/30] net/e1000: QOM Upcast Sweep peter.crosthwaite
2013-06-30 10:59 ` [Qemu-devel] [PATCH qom-next] net/e1000: QOM parent field cleanup Andreas Färber
2013-06-24 6:51 ` [Qemu-devel] [PATCH v2 02/30] net/rtl8139: QOM Upcast Sweep peter.crosthwaite
2013-06-30 11:16 ` [Qemu-devel] [PATCH qom-next] net/rtl8139: QOM parent field cleanup Andreas Färber
2013-06-24 6:52 ` [Qemu-devel] [PATCH v2 03/30] net/pcnet-pci: QOM Upcast Sweep peter.crosthwaite
2013-06-30 7:34 ` Andreas Färber
2013-06-30 11:24 ` Andreas Färber
2013-07-22 17:17 ` Andreas Färber
2013-06-24 6:52 ` [Qemu-devel] [PATCH v2 04/30] usb/hcd-xhci: " peter.crosthwaite
2013-06-30 7:44 ` Andreas Färber
2013-06-30 11:41 ` [Qemu-devel] [PATCH qom-next] usb/hcd-xhci: QOM parent field cleanup Andreas Färber
2013-06-24 6:53 ` [Qemu-devel] [PATCH v2 05/30] scsi/lsi53c895a: QOM Upcast Sweep peter.crosthwaite
2013-06-30 7:51 ` Andreas Färber
2013-06-30 11:54 ` [Qemu-devel] [PATCH qom-next] scsi/lsi53c895a: QOM parent field cleanup Andreas Färber
2013-06-24 6:54 ` [Qemu-devel] [PATCH v2 06/30] scsi/megasas: QOM Upcast Sweep peter.crosthwaite
2013-06-30 12:04 ` [Qemu-devel] [PATCH qom-next] scsi/megasas: QOM parent field cleanup Andreas Färber
2013-06-24 6:55 ` [Qemu-devel] [PATCH v2 07/30] scsi/esp-pci: QOM Upcast Sweep peter.crosthwaite
2013-06-30 12:11 ` [Qemu-devel] [PATCH qom-next] scsi/esp-pci: QOM parent field cleanup Andreas Färber
2013-06-24 6:55 ` [Qemu-devel] [PATCH v2 08/30] ide/ich: QOM Upcast Sweep peter.crosthwaite
2013-06-30 8:21 ` Andreas Färber
2013-06-30 23:36 ` Alexander Graf
2013-07-01 10:03 ` Andreas Färber
2013-07-01 10:10 ` Alexander Graf
2013-06-30 12:20 ` [Qemu-devel] [PATCH qom-next] ide/ich: QOM parent field cleanup Andreas Färber
2013-06-24 6:56 ` [Qemu-devel] [PATCH v2 09/30] ide/piix: QOM casting sweep peter.crosthwaite
2013-06-30 8:25 ` Andreas Färber
2013-07-22 16:20 ` Andreas Färber
2013-07-22 15:58 ` [Qemu-devel] [PATCH qom-next] ide: Introduce abstract QOM type for PCIIDEState Andreas Färber
2013-07-24 23:28 ` Andreas Färber
2013-06-24 6:57 ` [Qemu-devel] [PATCH v2 10/30] acpi/piix4: QOM Upcast Sweep peter.crosthwaite
2013-06-30 12:41 ` [Qemu-devel] [PATCH qom-next] acpi/piix4: QOM parent field cleanup Andreas Färber
2013-06-24 6:58 ` [Qemu-devel] [PATCH v2 11/30] misc/pci-testdev: QOM Upcast Sweep peter.crosthwaite
2013-06-30 12:49 ` Andreas Färber
2013-06-30 12:50 ` [Qemu-devel] [PATCH qom-next] misc/pci-testdev: QOM parent field cleanup Andreas Färber
2013-06-24 6:58 ` [Qemu-devel] [PATCH v2 12/30] virtio/vmware_vga: QOM casting sweep peter.crosthwaite
2013-06-30 8:41 ` Andreas Färber
2013-06-30 13:02 ` [Qemu-devel] [PATCH qom-next] display/vmware_vga: QOM parent field cleanup Andreas Färber
2013-06-24 6:59 ` [Qemu-devel] [PATCH v2 13/30] misc/ivshmem: QOM Upcast Sweep peter.crosthwaite
2013-06-30 9:18 ` Andreas Färber
2013-06-30 13:15 ` Andreas Färber
2013-06-30 13:16 ` [Qemu-devel] [PATCH qom-next] misc/ivshmem: QOM parent field cleanup Andreas Färber
2013-06-24 7:00 ` [Qemu-devel] [PATCH v2 14/30] xen/xen_platform: QOM casting sweep peter.crosthwaite
2013-06-30 9:32 ` Andreas Färber
2013-06-30 13:23 ` [Qemu-devel] [PATCH qom-next] xen/xen_platform: QOM parent field cleanup Andreas Färber
2013-06-24 7:00 ` [Qemu-devel] [PATCH v2 15/30] isa/*: QOM casting sweep peter.crosthwaite
2013-06-24 7:01 ` [Qemu-devel] [PATCH v2 16/30] pci/*: " peter.crosthwaite
2013-06-30 8:05 ` Andreas Färber
2013-06-24 7:02 ` [Qemu-devel] [PATCH v2 17/30] pci-bridge/pci_bridge_dev: Don't use DO_UPCAST peter.crosthwaite
2013-06-24 7:03 ` [Qemu-devel] [PATCH v2 18/30] pci-bridge/*: substitute ->qdev casts with DEVICE() peter.crosthwaite
2013-06-24 7:03 ` [Qemu-devel] [PATCH v2 19/30] pci/pci_bridge: " peter.crosthwaite
2013-06-24 7:04 ` [Qemu-devel] [PATCH v2 20/30] misc/vfio: " peter.crosthwaite
2013-06-24 7:05 ` [Qemu-devel] [PATCH v2 21/30] net/eepro100: " peter.crosthwaite
2013-06-24 7:06 ` [Qemu-devel] [PATCH v2 22/30] net/ne2000: " peter.crosthwaite
2013-06-24 7:06 ` [Qemu-devel] [PATCH v2 23/30] usb/*: " peter.crosthwaite
2013-06-24 7:07 ` [Qemu-devel] [PATCH v2 24/30] watchdog/wdt_i6300esb: " peter.crosthwaite
2013-06-24 7:08 ` [Qemu-devel] [PATCH v2 25/30] scsi/vmw_pvscsi: " peter.crosthwaite
2013-06-24 7:09 ` [Qemu-devel] [PATCH v2 26/30] i2c/smbus_ich9: " peter.crosthwaite
2013-06-24 7:09 ` [Qemu-devel] [PATCH v2 27/30] ide/cmd646: " peter.crosthwaite
2013-06-24 7:10 ` [Qemu-devel] [PATCH v2 28/30] ide/via: " peter.crosthwaite
2013-06-24 7:11 ` [Qemu-devel] [PATCH v2 29/30] pci-host/*: " peter.crosthwaite
2013-06-24 7:12 ` [Qemu-devel] [PATCH v2 30/30] i386/*: " peter.crosthwaite
2013-06-30 10:44 ` [Qemu-devel] [PATCH v2 00/30] PCI: Cleanup legacy casts in device land -- ANN: qom-next revived Andreas Färber
2013-06-30 15:09 ` [Qemu-devel] [PATCH v2 00/30] PCI: Cleanup legacy casts in device land Andreas Färber
2013-07-01 4:33 ` Peter Crosthwaite [this message]
2013-07-01 4:50 ` [Qemu-devel] [PATCH v2 00/30] PCI: Cleanup legacy casts in device land -- ANN: qom-next revived Peter Crosthwaite
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=CAEgOgz4XdjfpSXh36zKkFvfsaTArRhMYPODLhk82pDnQOOk-+w@mail.gmail.com \
--to=peter.crosthwaite@xilinx.com \
--cc=afaerber@suse.de \
--cc=anthony@codemonkey.ws \
--cc=aurelien@aurel32.net \
--cc=blauwirbel@gmail.com \
--cc=edgar.iglesias@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-trivial@nongnu.org \
/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).