From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59859) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDWKb-0001dg-LB for qemu-devel@nongnu.org; Mon, 28 Dec 2015 06:51:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aDWKa-0006KQ-Nb for qemu-devel@nongnu.org; Mon, 28 Dec 2015 06:51:17 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59004) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDWKa-0006KM-IA for qemu-devel@nongnu.org; Mon, 28 Dec 2015 06:51:16 -0500 Date: Mon, 28 Dec 2015 13:51:08 +0200 From: "Michael S. Tsirkin" Message-ID: <20151228115108.GC18063@redhat.com> References: <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> <003a01d1414d$1f2fd250$5d8f76f0$@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003a01d1414d$1f2fd250$5d8f76f0$@samsung.com> Subject: Re: [Qemu-devel] live migration vs device assignment (motivation) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pavel Fedin 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, "'Lan, Tianyu'" , 'Ard Biesheuvel' , "'Dong, Eddie'" , "'Jani, Nrupal'" , amit.shah@redhat.com, 'Paolo Bonzini' On Mon, Dec 28, 2015 at 11:52:43AM +0300, Pavel Fedin wrote: > 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 > Sure, or we can use an ACPI device. It doesn't really matter what we do for the mailbox. Whoever writes this first will get to select a mechanism. -- MST