[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH RFC qom-next 4/4] pcie_port: Turn PCIEPort and P
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [PATCH RFC qom-next 4/4] pcie_port: Turn PCIEPort and PCIESlot into abstract QOM types |
Date: |
Sun, 28 Jul 2013 15:58:03 +0300 |
On Sun, Jul 28, 2013 at 02:36:33PM +0200, Andreas Färber wrote:
> Hi Anthony,
>
> Am 22.07.2013 22:29, schrieb Anthony Liguori:
> > for consistency, I think having everything be relatively to
> > *one* type for a Property list is pretty helpful.
> >
> > Expecting someone to know the type hierarchy by heart such that this
> > doesn't look like a bug is too much IMHO.
>
> I have changed v2 not to mix different-but-compatible struct types in
> one VMStateDescription.
>
> Could you clarify if that was what you meant with the above?
>
> Or would you also be opposed to - post-1.6 - changing
> VMSTATE_PCIE_DEVICE(parent_obj[.parent_obj], MyStruct)
> to
> VMSTATE_PCIE_DEVICE()
> as suggested elsewhere in this thread?
>
> I'm thinking that writing VMSTATE_PCIE_DEVICE() already clearly
> indicates the developer knows the device inherits from TYPE_PCI_DEVICE.
>
> All PCIe devices using VMSTATE_PCIE_DEVICE() today use it at an offset
> of 0 and so do all PCI devices using VMSTATE_PCI_DEVICE() apparently.
> VMSTATE_PCI_DEVICE_POINTER() would be unaffected, but is unused anyway.
>
> My survey also concluded that luckily all VMSTATE_PCIE_DEVICE() and
> VMSTATE_PCI_DEVICE() are placed as first VMStateField, so moving parent
> state to its class might be possible, similar to qdev props todays with
> class_base_init clearing it for derived types.
> However this would require to either refactor core VMState code to
> operate on a list, aggregated from one or more zero-terminated arrays,
> which I would consider invasive and error-prone, or simply have Device
> code allocate a new VMStateDescription before registering it in QOM
> realize (so it can be free'd on unrealize). Thoughts?
>
> Either way, it would work for CPU but not for PCI, since there are two
> different macros, VMSTATE_PCI_DEVICE() and VMSTATE_PCIE_DEVICE() both
> for PCIDeviceClass. Not sure how to solve that without multi-inheritence.
Maybe combine them and use is_express to select the correct
format.
> SHPC_VMSTATE() seems to be another macro beyond VMSTATE_MSIX() operating
> on PCIDevice but placed in an individual device (pci-bridge-dev). Can it
> be turned into a subsection, Michael?
>
> Regards,
> Andreas
Not without breaking cross-version migration I think?
> --
> 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] [PATCH RFC qom-next 4/4] pcie_port: Turn PCIEPort and PCIESlot into abstract QOM types, (continued)
- Re: [Qemu-devel] [PATCH RFC qom-next 4/4] pcie_port: Turn PCIEPort and PCIESlot into abstract QOM types, Anthony Liguori, 2013/07/22
- Re: [Qemu-devel] [PATCH RFC qom-next 4/4] pcie_port: Turn PCIEPort and PCIESlot into abstract QOM types, Andreas Färber, 2013/07/22
- Re: [Qemu-devel] [PATCH RFC qom-next 4/4] pcie_port: Turn PCIEPort and PCIESlot into abstract QOM types, Michael S. Tsirkin, 2013/07/23
- Re: [Qemu-devel] [PATCH RFC qom-next 4/4] pcie_port: Turn PCIEPort and PCIESlot into abstract QOM types, Andreas Färber, 2013/07/23
- Re: [Qemu-devel] [PATCH RFC qom-next 4/4] pcie_port: Turn PCIEPort and PCIESlot into abstract QOM types, Michael S. Tsirkin, 2013/07/23
- Re: [Qemu-devel] [PATCH RFC qom-next 4/4] pcie_port: Turn PCIEPort and PCIESlot into abstract QOM types, Andreas Färber, 2013/07/23
- Re: [Qemu-devel] [PATCH RFC qom-next 4/4] pcie_port: Turn PCIEPort and PCIESlot into abstract QOM types, Gerd Hoffmann, 2013/07/23
- Re: [Qemu-devel] [PATCH RFC qom-next 4/4] pcie_port: Turn PCIEPort and PCIESlot into abstract QOM types, Michael S. Tsirkin, 2013/07/23
- Re: [Qemu-devel] [PATCH RFC qom-next 4/4] pcie_port: Turn PCIEPort and PCIESlot into abstract QOM types, Michael S. Tsirkin, 2013/07/23
- Re: [Qemu-devel] [PATCH RFC qom-next 4/4] pcie_port: Turn PCIEPort and PCIESlot into abstract QOM types, Andreas Färber, 2013/07/28
- Re: [Qemu-devel] [PATCH RFC qom-next 4/4] pcie_port: Turn PCIEPort and PCIESlot into abstract QOM types,
Michael S. Tsirkin <=
[Qemu-devel] [PATCH RFC qom-next 1/4] pci-bridge: Turn into abstract QOM type, Andreas Färber, 2013/07/21
Re: [Qemu-devel] [PATCH RFC qom-next 0/4] QOM'ification of pci-bridge types, Michael S. Tsirkin, 2013/07/21