Re: kern/49330 (Attempting to compile a Xen DOM0 and DRMKMS kernel doesn't compile)

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Fri, Mar 06, 2015 at 02:08:24PM +0000, Taylor R Campbell wrote:
>    Date: Sat, 28 Feb 2015 15:04:55 +0000 (UTC)
>    From: riastradh%NetBSD.org@localhost
> 
>    Was afraid I might find a system where pci_intr_handle_t is not int.
>    It shouldn't be too hard to adapt the drm code to this case: just
>    introduce a new type drm_irq_t or something, as a union of all the
>    possible interrupt handle types in drm, and put it in the right
>    places, with the compiler's help.  But it will take some work, and
>    cause more divergence from upstream.
> 
> Turns out drm doesn't actually use PCI interrupt handles -- the irq
> numbers it ostensibly handles appear to be a sham.  So I committed all
> the changes in drm necessary to work around this.
> 
> There remain some issues in Xen.  The attached patch makes a Xen/amd64
> dom0 kernel build with drm (including Intel, Radeon, and Nouveau), but
> I'm clueless about Xen, so I'm not going to commit it myself.

initxen_load_memmap() is wrong: what you get here are physical addresses (PA),
but later I guess you'll use them as machine addresses (MA) for DMA engines.

With Xen you can't use free lists as you do on bare metal, because
PA and MA are not necesserely in the same region. Requesting memory
from e.g. VM_FREELIST_FIRST1G will give you PA below the 1G boundary,
but you have no guarantees that the MA will be below the 1G boundary.
Also, even if the PAs are contigous, the MAs may not be (with some
debug options, the hypervisor will make sure they are not).

The only way to get pages with contraints on machine addresses is
to use Xen specific allocation  hypercalls. You can look at
sys/arch/xen/x86/xen_bus_dma.c for how to use this (especially
_xen_alloc_contig())

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--