Re: [Xen-devel] Xen osstest on Calxeda midway progress (Was: Re: [xen-unstable test] 21486: tolerable FAIL - PUSHED)

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2013-11-06 at 19:40 +0000, Stefano Stabellini wrote:
> > > > Or perhaps we should make it the default in the absence of SMMU?
> > > > Stefano, how did you end up coordinating this stuff with the dom0 kernel
> > > > side of things?
> > > 
> > > I am assuming the presence of the 1:1 mapping and then only dealing with
> > > foreign grants in Linux. So yes, I think that we should just make the
> > > 1:1 workaround the default until we get SMMU support.
> > 
> > Do you have a patch to that affect?
> 
> Just sent.

Got it. I actually meant a patch making it the default globally, but
this one will do for now.

>  I have more patches in my queue, most of them by Julien and
> Andre and might need to be reworked. In particular the patch to
> introduce SMP support.
> 
> 
> > BTW, at one point we discussed relaxing the 1:1 mapping into just a
> > contiguous mapping and publishing the offset to the guest, whatever
> > became of that idea?
> > 
> > Julien solved his issue on Arndale by allocating the 1:1 from as close
> > to the start of physical RAM as he could, but having an offset would be
> > more elegant and less prone to spurious breakage I think.
> 
> I take that by "and publishing the offset to the guest" you mean
> adjusting the start of the memory region in the device tree?

No, that's what we do today. i.e. if RAM is at 0x80000000 and we
allocate a 1:1 region at 0x80800000 then we give the guest a RAM region
at 0x80800000. This caused breakage on Exynos, so Julien change things
(6c21cb36e263 "Allocate memory for dom0 from the bottom with the 1:1
Workaround") to increase the chances that the memory would end up
allocated from closer to 0x80000000, which mostly works because Xen
normally tends to allocate the highest address it can which meets the
callers constraints (bit width etc) and we allocate memory for dom0
fairly early. But it is potentially fragile.

What I'm suggesting is to allocate a contiguous block of memory from
wherever (e.g 0x80800000) but tell the guest it has RAM at 0x80000000
(and map it there in the p2m) and separately expose the 0x00800000
offset for use in the various phys_to_bus calculations (in the swiotlb
or wherever). IOW in the places which your series determines it is safe
to just return the pseudophysical address it would instead apply the
offset.

I'm thinking in terms of a property in the hypervisor node, e.g.
dma-offset = <0x00800000>;

Obviously we would omit this (or explicitly set it to zero) when SMMU is
present.  

How are we intending to signal to dom0 that it needn't do all the
swiotlb magic even for foreign pages when an SMMU is present? We should
build that scheme in now. Presence/absence of dma-offset might be a
convenient hook, but maybe it needs to be per-device?

Ian.



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