[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] xen/arm: Let the IOMMU be accessible by Dom0 if forcibly disabled in Xen



On Thu, Aug 08, 2019 at 02:23:51PM +0300, Oleksandr wrote:
> 
> On 08.08.19 14:01, Roger Pau Monné wrote:
> 
> Hi, Roger.
> 
> 
> > On Thu, Aug 08, 2019 at 01:53:23PM +0300, Oleksandr Tyshchenko wrote:
> > > From: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>
> > > 
> > > Don't skip IOMMU nodes when creating DT for Dom0 if IOMMU has been
> > > forcibly disabled in bootargs (e.g. "iommu=0") in order to let
> > > the IOMMU be accessible by DOM0.
> > > 
> > > Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>
> > > ---
> > > I have heard there is a "possible" case when the IOMMU could be 
> > > accessible by DOM0.
> > > So, I think, for this to work we need to create corresponding DT nodes in 
> > > the DT
> > > at least.
> > dom0 on ARM being an autotranslated guest I'm not sure how it's going
> > to program the DMA remapping in the iommu, since it doesn't know the
> > mfns of the memory it uses at all, hence I don't see the point in
> > exposing the hardware iommu to dom0 unless there's some emulation done
> > to make dom0 able to access it.
> 
> Currently, Dom0 on ARM is always 1:1 mapped (gfn == mfn). However, I don't
> really know how long this assumption it is going to be true.

Yes, I didn't had this in mind when writing the above reply. With
identity mapping in second stage translation it's indeed true that
dom0 might be able to somehow manage an iommu, but I don't think it's
a good idea to rely on this bodge (the identity mappings), and hence I
would advise against exposing the native iommu to dom0.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.