From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH v3 18/24] xen/passthrough: iommu_deassign_device_dt: By default reassign device to nobody Date: Mon, 23 Feb 2015 16:24:28 +0000 Message-ID: <54EB624C0200007800062AFB@mail.emea.novell.com> 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 1YPvo9-0003zi-DQ for xen-devel@lists.xenproject.org; Mon, 23 Feb 2015 16:24:33 +0000 In-Reply-To: <1424705982.27930.172.camel@citrix.com> Content-Disposition: inline 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 , Julien Grall Cc: xen-devel@lists.xenproject.org, stefano.stabellini@citrix.com, tim@xen.org List-Id: xen-devel@lists.xenproject.org >>> On 23.02.15 at 16:39, 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? I suppose this was really targeted at Julien... Jan >> > 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. > > Ian.