From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59040) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDTXy-0001pA-Cm for qemu-devel@nongnu.org; Mon, 28 Dec 2015 03:52:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aDTXv-0006Gn-6y for qemu-devel@nongnu.org; Mon, 28 Dec 2015 03:52:54 -0500 Received: from mailout3.w1.samsung.com ([210.118.77.13]:58864) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDTXv-0006Gh-0Z for qemu-devel@nongnu.org; Mon, 28 Dec 2015 03:52:51 -0500 Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout3.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0O02002C88NY9PD0@mailout3.w1.samsung.com> for qemu-devel@nongnu.org; Mon, 28 Dec 2015 08:52:46 +0000 (GMT) From: Pavel Fedin References: <1448372127-28115-1-git-send-email-tianyu.lan@intel.com> <20151207165039.GA20210@redhat.com> <56685631.50700@intel.com> <20151210101840.GA2570@work-vm> <566961C1.6030000@gmail.com> <20151210114114.GE2570@work-vm> <56698E68.5040207@intel.com> <566D9320.8000209@intel.com> <20151214112253-mutt-send-email-mst@redhat.com> In-reply-to: <20151214112253-mutt-send-email-mst@redhat.com> Date: Mon, 28 Dec 2015 11:52:43 +0300 Message-id: <003a01d1414d$1f2fd250$5d8f76f0$@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-language: ru Subject: Re: [Qemu-devel] live migration vs device assignment (motivation) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "'Michael S. Tsirkin'" , "'Lan, Tianyu'" Cc: 'Yang Zhang' , "'Tantilov, Emil S'" , kvm@vger.kernel.org, aik@ozlabs.ru, qemu-devel@nongnu.org, 'Alexander Duyck' , lcapitulino@redhat.com, 'Blue Swirl' , kraxel@redhat.com, "'Rustad, Mark D'" , quintela@redhat.com, "'Skidmore, Donald C'" , 'Alexander Graf' , 'Or Gerlitz' , "'Dr. David Alan Gilbert'" , 'Alex Williamson' , 'Anthony Liguori' , cornelia.huck@de.ibm.com, 'Ard Biesheuvel' , "'Dong, Eddie'" , "'Jani, Nrupal'" , amit.shah@redhat.com, 'Paolo Bonzini' Hello! > A dedicated IRQ per device for something that is a system wide event > sounds like a waste. I don't understand why a spec change is strictly > required, we only need to support this with the specific virtual bridge > used by QEMU, so I think that a vendor specific capability will do. > Once this works well in the field, a PCI spec ECN might make sense > to standardise the capability. Keeping track of your discussion for some time, decided to jump in... So far, we want to have some kind of mailbox to notify the quest about migration. So what about some dedicated "pci device" for this purpose? Some kind of "migration controller". This is: a) perhaps easier to implement than capability, we don't need to push anything to PCI spec. b) could easily make friendship with Windows, because this means that no bus code has to be touched at all. It would rely only on drivers' ability to communicate with each other (i guess it should be possible in Windows, isn't it?) c) does not need to steal resources (BARs, IRQs, etc) from the actual devices. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia