Re: [Xen-devel] [PATCH v3 12/13] xen/arm: Add the property "protected-devices" in the hypervisor node

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2014-04-03 at 22:51 +0100, Julien Grall wrote:
> Hi Ian,
> 
> Sorry, I forgot to answer to this email...
> 
> On 19/03/14 10:33, Ian Campbell wrote:
> > On Tue, 2014-03-18 at 20:09 +0000, Julien Grall wrote:
> >> Hi Ian,
> >>
> >> On 03/18/2014 04:48 PM, Ian Campbell wrote:
> >>> On Tue, 2014-03-11 at 15:49 +0000, Julien Grall wrote:
> >>>> DOM0 is using the swiotlb to bounce DMA. With the IOMMU support in Xen,
> >>>> protected devices should not use it.
> >>>>
> >>>> Only Xen is abled to know if an IOMMU protects the device. The new 
> >>>> property
> >>>> "protected-devices" is a list of device phandles protected by an IOMMU.
> >>>>
> >>>> Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>
> >>>>
> >>>> ---
> >>>>      This patch *MUST NOT* be applied until we agreed on a device binding
> >>>>      the device tree folks. DOM0 can run safely with swiotlb on protected
> >>>>      devices while LVM is not used for guest disk.
> >>>
> >>> LVM works these days I think.
> >>
> >> With this patch series applied, LVM will be broken if the hard drive is
> >> protected by an IOMMU.
> >
> > How/why?
> 
> If the guest is using LVM for its block, bouncing via the swiotlb with 
> IOMMU enabled will result to wrong mapping. If I remember correctly it's 
> because SWIOTLB DMA address is a physical address and not an IPA. So the 
> IOMMU will rejected the request.

Can this not be made to work? The swiotlb shouldn't be breaking things
like this, regardless of whether there is an iommu which it doesn't know
about it should be returning sane results, which might imply the Xen
needs to be giving it sensible results.

At what point is the IOMMU rejecting the request? I didn't expect it to
be involved in the swiotlb path -- that's a copy into dom0 owned RAM
with a known 1:1 mapping (provided either by the literal use of a 1:1
mapping or by using the IOMMU to give the guest that impression).

> So we have to by-pass swiotlb in this case.
> 
> >
> >> It's the case on midway, the platform will crash just after the guest
> >> begins to boot.
> >
> > This configuration works today (osstest tests it) so this would be a
> > regression. Can you sort this please?
> 
> As said above with IOMMU enabled I won't be able to sort it until my 
> patch series for Linux will be upstreamed.

We really need to be able to manage this transition in a compatible way,
that means new kernels working on old hypervisors as well as old kernels
working on new hypervisors (it's obviously fine for this case to bounce
when it doesn't need to).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel