From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Fedin Subject: RE: [Qemu-devel] live migration vs device assignment (motivation) Date: Mon, 28 Dec 2015 11:52:43 +0300 Message-ID: <003a01d1414d$1f2fd250$5d8f76f0$@samsung.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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' To: "'Michael S. Tsirkin'" , "'Lan, Tianyu'" Return-path: Received: from mailout3.w1.samsung.com ([210.118.77.13]:58862 "EHLO mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751502AbbL1Iwt (ORCPT ); Mon, 28 Dec 2015 03:52:49 -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 kvm@vger.kernel.org; Mon, 28 Dec 2015 08:52:46 +0000 (GMT) In-reply-to: <20151214112253-mutt-send-email-mst@redhat.com> Content-language: ru Sender: kvm-owner@vger.kernel.org List-ID: 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