From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48543) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3RvS-0004Gd-64 for qemu-devel@nongnu.org; Sun, 28 Jul 2013 10:26:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V3RvK-0000LR-Sw for qemu-devel@nongnu.org; Sun, 28 Jul 2013 10:26:22 -0400 Received: from cantor2.suse.de ([195.135.220.15]:33653 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3RvK-0000LH-Ka for qemu-devel@nongnu.org; Sun, 28 Jul 2013 10:26:14 -0400 Message-ID: <51F52A00.7080601@suse.de> Date: Sun, 28 Jul 2013 16:26:08 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1374975670-8820-1-git-send-email-afaerber@suse.de> <51F5202C.6060602@suse.de> In-Reply-To: <51F5202C.6060602@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH RFC for-1.6 qom-next 0/3] PCIe VMState cleanups for 1.6 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" , Stefan Hajnoczi Cc: Juan Quintela , qemu-devel@nongnu.org, Hannes Reinecke , Anthony Liguori , Paolo Bonzini , Cam Macdonell , Gerd Hoffmann Am 28.07.2013 15:44, schrieb Andreas F=C3=A4rber: > Am 28.07.2013 03:41, schrieb Andreas F=C3=A4rber: >> Patch 1 assumes the following are equivalent: >> a) - Struct A >> - Field Aa >> ... >> - Field X >> ... >> b) - Struct A >> - Field Aa >> ... >> - Field X >> >> Patch 2 relies on XHCI not being released yet, thus no compatibiliy co= ncerns. >> >> Patch 3 assumes the following are equivalent: >> a) - Struct A >> - Field Aa >> ... >> - Field X >> b) - Struct A >> - Field Aa >> ... >> - Subsection Ax >> - Field X >> >> CC'ing Juan to verify which of these are correct/safe. >=20 > If the answer is "doing both as subsections will work fine" then this > series could be postponed post-1.6, of course. >=20 > Looking deeper at PCI devices, I notice that while XHCI was the only > device to use VMSTATE_MSIX() macro, other devices were using > msix_init*() as well, namely > * nvme (unmigratable) > * pci-assign (unmigratable) > * vfio (unmigratable) > * vmxnet3 - does an extra register_savevm() just for msix_save() > * ivshmem - calling msix_save() conditionally after pci_device_save() > * virtio-pci - calling msix_save() conditionally after pci_device_save(= ) Sorry, unconditionally, but msix_save() is no-op if !msix_present(), so effect is the same - stored immediately after for some devices, with ivshmem using its own qdev property condition hopefully equivalent to msix_present() and vmxnet3 breaking that scheme. While pci_device_save() internally reuses vmstate_pci[e]_device, neither ivshmem nor virtio-pci set PCIDeviceClass::is_express, so are unaffected by changes of vmstate_pcie_device in this series. Stefan, do you see bumping vmxnet3 version_id post-1.6 as an acceptable solution? Then we could make MSI-X a vmstate_pci_device subsection, too, if I'm not making a thinko. Andreas > * megasas - #ifdef USE_MSIX'ed out, will need changes >=20 > CC'ing net and scsi maintainers and Hannes. >=20 > Regards, > Andreas >=20 --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg