From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH v3 18/24] xen/passthrough: iommu_deassign_device_dt: By default reassign device to nobody Date: Mon, 23 Feb 2015 16:35:24 +0000 Message-ID: <1424709324.27930.211.camel@citrix.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> <54EB624C0200007800062AFB@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YPw1c-0006UX-3G for xen-devel@lists.xenproject.org; Mon, 23 Feb 2015 16:38:28 +0000 In-Reply-To: <54EB624C0200007800062AFB@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 Cc: xen-devel@lists.xenproject.org, Julien Grall , stefano.stabellini@citrix.com, tim@xen.org List-Id: xen-devel@lists.xenproject.org On Mon, 2015-02-23 at 16:24 +0000, Jan Beulich wrote: > >>> 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... Right, sorry that wasn't very clear of me. > > 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. > > >