Re: Xen on RP4

[Elliott Mitchell <ehem+xen@xxxxxxx>]

On Fri, Oct 23, 2020 at 04:59:30PM -0700, Stefano Stabellini wrote:
> On Fri, 23 Oct 2020, Elliott Mitchell wrote:
> > Finally came up with one detail of a change I'd made in the right time
> > frame to trigger this issue.  As such I can now control this behavior and
> > get it to occur or not.
> > 
> > I have some suspicion my planned workload approach differs from others.
> > 
> > During the runs where I was able to successfully boot a child domain,
> > domain 0 had been allocated 512MB of memory.  During the unsuccessful run
> > where the above message occurred, domain 0 had been allocated 2GB of
> > memory.  This appears to reliably control the occurrence of this bug.

> In your case, the allocation must fail, no_iotlb_memory is set, and I
> expect you see this warning among the boot messages:
> 
>   Cannot allocate buffer
> 
> Later during initialization swiotlb-xen comes in
> (drivers/xen/swiotlb-xen.c:xen_swiotlb_init) and given that io_tlb_start
> is != 0 it thinks the memory is ready to use when actually it is not.

Then I look at more copies of `dmesg` logs and discover I did have one
where that message occurred.  Then start playing a bit more and a
matching pattern emerges.

dom0_mem=1023M
=> "software IO TLB: mapped [mem 0x2c000000-0x30000000] (64MB)"

dom0_mem=1024M
=> "software IO TLB: Cannot allocate buffer"

That looks suspicious.  Really suspicious.  I don't know how many bugs
are combined together, nor where they are, but more data for you.

I see a possibility Tianocore marks a smaller region of memory as being
DMA-capable.  This though is speculation.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@xxxxxxx  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445