From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:47307)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <B07421@freescale.com>) id 1VJnuY-00033S-Mf
	for qemu-devel@nongnu.org; Wed, 11 Sep 2013 13:09:10 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <B07421@freescale.com>) id 1VJnuR-0004BH-CW
	for qemu-devel@nongnu.org; Wed, 11 Sep 2013 13:09:02 -0400
Received: from ch1ehsobe001.messaging.microsoft.com ([216.32.181.181]:6090
	helo=ch1outboundpool.messaging.microsoft.com)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <B07421@freescale.com>) id 1VJnuR-0004BB-6Z
	for qemu-devel@nongnu.org; Wed, 11 Sep 2013 13:08:55 -0400
Message-ID: <1378919324.12204.399.camel@snotra.buserror.net>
From: Scott Wood <scottwood@freescale.com>
Date: Wed, 11 Sep 2013 12:08:44 -0500
In-Reply-To: <9F6FE96B71CF29479FF1CDC8046E15036AA03E@039-SN1MPN1-002.039d.mgd.msft.net>
References: <9F6FE96B71CF29479FF1CDC8046E15036AA03E@039-SN1MPN1-002.039d.mgd.msft.net>
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] vfio for platform devices - 9/5/2012 - minutes
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Yoder Stuart-B08248 <B08248@freescale.com>
Cc: 'Peter Maydell' <peter.maydell@linaro.org>, 'Antonios Motakis' <a.motakis@virtualopensystems.com>, Wood Scott-B07421 <B07421@freescale.com>, 'Santosh Shukla' <santosh.shukla@linaro.org>, 'Alexander Graf' <agraf@suse.de>, "kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "'kim.phillips@linaro.org'" <kim.phillips@linaro.org>, 'Alex Williamson' <alex.williamson@redhat.com>, Bhushan Bharat-R65777 <R65777@freescale.com>, Sethi Varun-B16395 <B16395@freescale.com>, "kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>, 'Christoffer Dall' <christoffer.dall@linaro.org>

On Wed, 2013-09-11 at 11:42 -0500, Yoder Stuart-B08248 wrote:
> One thing we didn't discuss needs to be considered (probably by
> Kim who is looking at the 'binding device' issue) is around
> returning a passthru device back to the host.
> 
> After a platform device has been bound to vfio and is in use by
> user space or a virtual machine, we also need to be able
> to unwind all that and return the device back to the host
> in a sane state.
> 
> What happens when user space exits and the vfio file
> descriptors are closed?
> 
> What if the device is still active and doing bus 
> mastering?   (e.g. a VM crashed causing a QEMU
> exit)
> 
> How can the vfio-platform layer in the host kernel
> get a specific device in a sane state?
> 
> When a plaform device is 'unbound' from vfio, what
> specifically happens to the device?
> 
> Platform devices don't have generic mechanisms like on PCI
> to disable bus mastering or even disable or reset a
> device.
> 
> Haven't thought through all this yet, but just raising
> some issues I see.

In the absence of some code in the host kernel that knows how to reset
the device, I think the model needs to be that devices start out with
the IOMMU blocking all transactions, and the user must ensure that the
device has been quiesced prior to enabling the device at the IOMMU.
This may require a hypercall or similar to let QEMU know when it's safe
to enable the device's IOMMU mappings (assuming that there's no virtual
IOMMU visible to the VM).

-Scott