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 16:37:25 +0000 Message-ID: <54EB5745.8090709@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> <54EAFC7F.6030101@linaro.org> <54EB0CF60200007800062657@mail.emea.novell.com> <1424705982.27930.172.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YPw15-0006Ko-DR for xen-devel@lists.xenproject.org; Mon, 23 Feb 2015 16:37:55 +0000 Received: by mail-wi0-f170.google.com with SMTP id hi2so21342251wib.1 for ; Mon, 23 Feb 2015 08:37:53 -0800 (PST) In-Reply-To: <1424705982.27930.172.camel@citrix.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: Ian Campbell , Jan Beulich Cc: xen-devel@lists.xenproject.org, stefano.stabellini@citrix.com, tim@xen.org List-Id: xen-devel@lists.xenproject.org On 23/02/15 15:39, Ian Campbell wrote: > On Mon, 2015-02-23 at 10:20 +0000, Jan Beulich wrote: >>>>> On 23.02.15 at 11:10, wrote: >>> 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. > > "there is no possibility to reset a platform device" isn't quite true, > there is certainly a theoretical possibility (i.e. it is obviously the > case that a dom0 could be written to do so for at least some devices). > So what happens if such a dom0 arises in the future? I suppose the > intention is that the user would having deassigned from domU and > determined that there kernel has the necessary feature would do some > sort of xl command to assign to dom0? The list of things to do for resetting a device would be: - Deassign device from DOMU (though it's done during destruction) - Assign the device to DOM0 and map MMIO - Reset the device But that not my concern right now. As we agreed, this feature (i.e reset a device) is not in the scope of this series. So assigning the device to DOM0 is not safe at all. >>> 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. >> >> And I think spelling this out in the description is what Ian is >> asking for. > > Yes. > > I think it probably ought to be mentioned in the docs surrounding the > hypercalls in question, for both PCI, DT and any other device type > whether or not there is some implicit rebinding or not. Ok. -- Julien Grall