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

Re: i915 "GPU HANG", bisected to a2daa27c0c61 "swiotlb: simplify swiotlb_max_segment"



On 18.10.2022 13:02, Christoph Hellwig wrote:
> On Tue, Oct 18, 2022 at 10:57:37AM +0200, Jan Beulich wrote:
>> Shouldn't this then be xen_pv_domain() that you use here, and - if you
>> really want IS_ENABLED() in addition - CONFIG_XEN_PV?
> 
> I'll need help from people that understand Xen better than me what
> the exact conditions (and maybe also comments are).

Leaving the "i915 abuses" part aside (because I can't tell what exactly the
abuse is), but assuming that "can't cope with bounce buffering" means they
don't actually use the allocated buffers, I'd suggest this:

        /*
         * For Xen PV guests pages aren't contiguous in DMA (machine) address
         * space.  The DMA API takes care of that both in dma_alloc_* (by
         * calling into the hypervisor to make the pages contiguous) and in
         * dma_map_* (by bounce buffering).  But i915 abuses ignores the
         * coherency aspects of the DMA API and thus can't cope with bounce
         * buffering actually happening, so add a hack here to force small
         * allocations and mappings when running in PV mode on Xen.
         */
        if (IS_ENABLED(CONFIG_XEN_PV) && xen_pv_domain())
                max = PAGE_SIZE;

I've dropped the TDX related remark because I don't think it's meaningful
for PV guests. Otoh I've left the "abuses ignores" word sequence as is, no
matter that it reads odd to me. Plus, as hinted at before, I'm not
convinced the IS_ENABLED() use is actually necessary or warranted here.

Jan



 


Rackspace

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