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