From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v3 18/24] xen/passthrough: iommu_deassign_device_dt: By default reassign device to nobody Date: Mon, 23 Feb 2015 10:10:07 +0000 Message-ID: <54EAFC7F.6030101@linaro.org> References: <1421159133-31526-1-git-send-email-julien.grall@linaro.org> <1421159133-31526-19-git-send-email-julien.grall@linaro.org> <1424451889.30924.363.camel@citrix.com> <54EB039202000078000625F8@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YPpxs-00075r-2q for xen-devel@lists.xenproject.org; Mon, 23 Feb 2015 10:10:12 +0000 Received: by wesw62 with SMTP id w62so16857822wes.12 for ; Mon, 23 Feb 2015 02:10:10 -0800 (PST) In-Reply-To: <54EB039202000078000625F8@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Ian Campbell Cc: xen-devel@lists.xenproject.org, stefano.stabellini@citrix.com, tim@xen.org List-Id: xen-devel@lists.xenproject.org Hi Jan, On 23/02/2015 09:40, Jan Beulich wrote: >>>> On 20.02.15 at 18:04, wrote: >> On Tue, 2015-01-13 at 14:25 +0000, Julien Grall wrote: >>> Currently, when the device is deassigned from a domain, we directly reassign >>> to DOM0. >>> >>> As the device may not have been correctly reset, this may lead to corruption >> or >>> expose some part of DOM0 memory. Also, we may have no way to reset some >>> platform devices. >>> >>> If Xen reassigns the device to "nobody", it may receive some global/context >>> fault because the transaction has failed (indeed the context has been >>> marked invalid). Unfortunately there is no simple way to quiesce a buggy >>> hardware. I think we could live with that for a first version of platform >>> device passthrough. >>> >>> DOM0 will have to issue an hypercall to assign the device to itself if it >>> wants to use it. >> >> Does this behaviour differ from x86? If so then it is worth calling that >> out explicitly (even if not, good to know I think!) > Indeed this is different from x86, and I think such behavior should > be consistent across architectures. If Dom0 isn't handed back the > device, who's going to do the supposedly prerequisite reset? On > x86/PCI that's pciback's job, and it would be illegitimate for the > driver to do _anything_ with the device if it wasn't owned by Dom0. I think we already had this discussion on a previous version... Right now, there is no possibility to reset a platform device in the kernel. There is some discussion about it but nothing more. This series doesn't intend to have a generic solution for platform device pass-through. It's target embedded people who will always passthrough the same device to the same guest. As DOM0 *should not* use the device (no reset driver, and no possibility to unbind), the safest way is to reassign the device to nobody. So if the device is not quiescent it may mess up DOM0. Regards, -- Julien Grall