NetBSD Problem Report #49330

From www@NetBSD.org  Tue Oct 28 12:04:08 2014
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 0574CA6684
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 28 Oct 2014 12:04:08 +0000 (UTC)
Message-Id: <20141028120406.B476CA6685@mollari.NetBSD.org>
Date: Tue, 28 Oct 2014 12:04:06 +0000 (UTC)
From: brad@anduin.eldar.org
Reply-To: brad@anduin.eldar.org
To: gnats-bugs@NetBSD.org
Subject: Attempting to compile a Xen DOM0 and DRMKMS kernel doesn't compile
X-Send-Pr-Version: www-1.0

>Number:         49330
>Category:       port-xen
>Synopsis:       Attempting to compile a Xen DOM0 and DRMKMS kernel doesn't compile
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    riastradh
>State:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Oct 28 12:05:00 +0000 2014
>Closed-Date:    
>Last-Modified:  Tue Aug 14 17:49:56 +0000 2018
>Originator:     Brad
>Release:        7.0_BETA
>Organization:
eldar.org
>Environment:
Compiling up 7.0_BETA on 6.1_STABLE
>Description:
I don't know if this is exactly suppose to work, but I was attempting to compile a Xen DOM0 kernel with the new DRMKMS support in it and the compile fails:

/lhome/build/NetBSD_7/amd64/TOOLS/bin/x86_64--netbsd-gcc -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -mno-avx -msoft-float -mno-fp-ret-in-387 -ffreestanding -fno-zero-initialized-in-bss -g -O2 -fno-omit-frame-pointer -fstack-protector -Wstack-protector --param ssp-buffer-size=1 -fno-strict-aliasing -fno-common -std=gnu99 -Werror -Wall -Wno-main -Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wno-unreachable-code -Wno-pointer-sign -Wno-attributes -Wextra -Wno-unused-parameter -Wold-style-definition -Wno-sign-compare --sysroot=/lhome/build/NetBSD_7/amd64/DIST -Damd64 -Dx86_64 -I. -I/usr/installed_src/NetBSD_7_branch/src/sys/arch/amd64/compile/DRMKMS_XEN3_DOM0/xen-ma -I../../../../../common/include -I../../../../arch -I../../../.. -nostdinc -DMSGBUFSIZE=24576 -DMAXUSERS=32 -D_KERNEL -D_KERNEL_OPT -std=gnu99 -I../../../../lib/libkern/../../../common/lib/libc/quad -I../../../
 ../lib/libkern/../../../common/lib/libc/string -I../../../../lib/libkern/../../../common/lib/libc/arch/x86_64/string -D_FORTIFY_SOURCE=2 -I../../../../external/bsd/ipf -I../../../../external/isc/atheros_hal/dist -I../../../../external/isc/atheros_hal/ic -I../../../../external/bsd/drm2/include -I../../../../external/bsd/common/include -I../../../../external/bsd/drm2/include -I../../../../external/bsd/drm2/include/drm -I../../../../external/bsd/drm2/dist -I../../../../external/bsd/drm2/dist/include -I../../../../external/bsd/drm2/dist/include/drm -I../../../../external/bsd/drm2/dist/uapi -I../../../../external/bsd/common/include -D__KERNEL__ -DCONFIG_AGP -I../../../../external/bsd/drm2/dist/drm/i915 -I../../../../external/bsd/drm2/i915drm -DCONFIG_DRM_I915_FBDEV -I../../../../external/bsd/drm2/dist/drm/radeon -I../../../../external/bsd/drm2/include/radeon -I../../../../external/bsd/drm2/radeon -I../../../../external/bsd/acpica/dist/include -c ../../../../external/bsd/drm2/pci/
 drm_pci.c
../../../../external/bsd/drm2/pci/drm_pci.c: In function 'drm_pci_get_irq':
../../../../external/bsd/drm2/pci/drm_pci.c:232:9: error: incompatible types when assigning to type 'int' from type 'pci_intr_handle_t'
  ih_int = ih_pih;
         ^

*** Failed target:  drm_pci.o

The kernel include:

include "arch/amd64/conf/XEN3_DOM0"

i915drmkms*     at pci? dev ? function ?
intelfb*        at intelfbbus?

radeon*         at pci? dev ? function ?
radeondrmkmsfb* at radeonfbbus?

#nouveau*       at pci? dev ? function ?
#nouveaufb*     at nouveaufbbus

#no options     DIAGNOSTIC
#options        DIAGNOSTIC      # inexpensive kernel consistency checks
#options        DEBUG           # expensive debugging checks/support
#options        LOCKDEBUG       # debug locks
makeoptions     DEBUG="-g"      # compile full symbol table

#options        ACPIVERBOSE     # verbose ACPI device autoconfig messages
options         PCIVERBOSE      # verbose PCI device autoconfig messages
options         USBVERBOSE      # verbose USB device autoconfig messages

You will get some additional errors if you leave in the the debugging / diag options.


The background:

I have a Lenovo T530 with 16GB of memory that I am running a 6.1_STABLE DOM0 kernel on it hosting a number of guests of various sorts.  This all works pretty well.  A weakness is the X speed, as it is using the vesa X driver when running the local X server.  I have booted a non-Xen kernel of 7.0_BETA and the new DRMKMS X servers for the intel chipset appears to perform much better, so I was hoping that I would be able to combine a Xen DOM0 kernel with DRMKMS and get the full and desired effect.
>How-To-Repeat:
Attempt to use the above config.
>Fix:

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: kern-bug-people->riastradh
Responsible-Changed-By: riastradh@NetBSD.org
Responsible-Changed-When: Sat, 28 Feb 2015 15:04:55 +0000
Responsible-Changed-Why:
mine


State-Changed-From-To: open->analyzed
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Sat, 28 Feb 2015 15:04:55 +0000
State-Changed-Why:
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.


From: Taylor R Campbell <riastradh@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, netbsd-bugs@netbsd.org,
	gnats-admin@netbsd.org, brad@anduin.eldar.org
Subject: Re: kern/49330 (Attempting to compile a Xen DOM0 and DRMKMS kernel doesn't compile)
Date: Fri, 6 Mar 2015 14:08:24 +0000

 This is a multi-part message in MIME format.
 --=_ngjbvaBAGjbjnb156wY3Fz/JsuWfskOa

    Date: Sat, 28 Feb 2015 15:04:55 +0000 (UTC)
    From: riastradh@NetBSD.org

    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.

 --=_ngjbvaBAGjbjnb156wY3Fz/JsuWfskOa
 Content-Type: text/plain; charset="ISO-8859-1"; name="xenkms"
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: attachment; filename="xenkms.patch"

 Index: sys/arch/amd64/amd64/machdep.c
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 RCS file: /cvsroot/src/sys/arch/amd64/amd64/machdep.c,v
 retrieving revision 1.211
 diff -p -u -r1.211 machdep.c
 --- sys/arch/amd64/amd64/machdep.c	12 May 2014 22:50:03 -0000	1.211
 +++ sys/arch/amd64/amd64/machdep.c	6 Mar 2015 13:47:16 -0000
 @@ -1638,9 +1638,7 @@ init_x86_64(paddr_t first_avail)
  	kern_end =3D KERNBASE + first_avail;
  	physmem =3D xen_start_info.nr_pages;
 =20
 -	uvm_page_physload(atop(avail_start),
 -		atop(avail_end), atop(avail_start),
 -		atop(avail_end), VM_FREELIST_DEFAULT);
 +	initxen_load_memmap();
  #endif	/* !XEN */
 =20
  	init_x86_64_msgbuf();
 Index: sys/arch/i386/i386/machdep.c
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 RCS file: /cvsroot/src/sys/arch/i386/i386/machdep.c,v
 retrieving revision 1.753
 diff -p -u -r1.753 machdep.c
 --- sys/arch/i386/i386/machdep.c	23 Jan 2015 02:52:14 -0000	1.753
 +++ sys/arch/i386/i386/machdep.c	6 Mar 2015 13:47:17 -0000
 @@ -1269,9 +1269,7 @@ init386(paddr_t first_avail)
  	    "0x%" PRIx64 " (%" PRId64 ")\n",
  	    (uint64_t)avail_start, (uint64_t)atop(avail_start),
  	    (uint64_t)avail_end, (uint64_t)atop(avail_end)));
 -	uvm_page_physload(atop(avail_start), atop(avail_end),
 -	    atop(avail_start), atop(avail_end),
 -	    VM_FREELIST_DEFAULT);
 +	initxen_load_memmap();
 =20
  	/* Reclaim the boot gdt page - see locore.s */
  	{
 Index: sys/arch/x86/include/machdep.h
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 RCS file: /cvsroot/src/sys/arch/x86/include/machdep.h,v
 retrieving revision 1.7
 diff -p -u -r1.7 machdep.h
 --- sys/arch/x86/include/machdep.h	12 Jun 2014 19:02:35 -0000	1.7
 +++ sys/arch/x86/include/machdep.h	6 Mar 2015 13:47:17 -0000
 @@ -41,9 +41,13 @@ void	x86_cpu_idle_init(void);
  void	x86_cpu_idle_get(void (**)(void), char *, size_t);
  void	x86_cpu_idle_set(void (*)(void), const char *, bool);
 =20
 +#ifdef XEN
 +void	initxen_load_memmap(void);
 +#else
  int	initx86_parse_memmap(struct btinfo_memmap *, struct extent *);
  int	initx86_fake_memmap(struct extent *);
  int	initx86_load_memmap(paddr_t first_avail);
 +#endif
  int	x86_select_freelist(uint64_t);
 =20
  void	x86_startup(void);
 Index: sys/arch/x86/x86/x86_machdep.c
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 RCS file: /cvsroot/src/sys/arch/x86/x86/x86_machdep.c,v
 retrieving revision 1.67
 diff -p -u -r1.67 x86_machdep.c
 --- sys/arch/x86/x86/x86_machdep.c	11 Aug 2014 03:43:25 -0000	1.67
 +++ sys/arch/x86/x86/x86_machdep.c	6 Mar 2015 13:47:17 -0000
 @@ -426,13 +426,96 @@ x86_cpu_idle_set(void (*func)(void), con
  	(void)strlcpy(x86_cpu_idle_text, text, sizeof(x86_cpu_idle_text));
  }
 =20
 -#ifndef XEN
 +static struct {
 +	int freelist;
 +	uint64_t limit;
 +} x86_freelists[VM_NFREELIST] =3D {
 +	{ VM_FREELIST_DEFAULT, 0 },
 +#ifdef VM_FREELIST_FIRST1T
 +	/* 40-bit addresses needed for modern graphics.  */
 +	{ VM_FREELIST_FIRST1T,	1ULL * 1024 * 1024 * 1024 * 1024 },
 +#endif
 +#ifdef VM_FREELIST_FIRST64G
 +	/* 36-bit addresses needed for oldish graphics.  */
 +	{ VM_FREELIST_FIRST64G,	64ULL * 1024 * 1024 * 1024 },
 +#endif
 +#ifdef VM_FREELIST_FIRST4G
 +	/* 32-bit addresses needed for PCI 32-bit DMA and old graphics.  */
 +	{ VM_FREELIST_FIRST4G,	4ULL * 1024 * 1024 * 1024 },
 +#endif
 +	/* 30-bit addresses needed for ancient graphics.  */
 +	{ VM_FREELIST_FIRST1G,	1ULL * 1024 * 1024 * 1024 },
 +	/* 24-bit addresses needed for ISA DMA.  */
 +	{ VM_FREELIST_FIRST16,	16 * 1024 * 1024 },
 +};
 +
 +extern paddr_t avail_start, avail_end;
 +
 +int
 +x86_select_freelist(uint64_t maxaddr)
 +{
 +	unsigned int i;
 +
 +	if (avail_end <=3D maxaddr)
 +		return VM_NFREELIST;
 +
 +	for (i =3D 0; i < __arraycount(x86_freelists); i++) {
 +		if ((x86_freelists[i].limit - 1) <=3D maxaddr)
 +			return x86_freelists[i].freelist;
 +	}
 +
 +	panic("no freelist for maximum address %"PRIx64, maxaddr);
 +}
 +
 +#ifdef XEN
 +
 +void
 +initxen_load_memmap(void)
 +{
 +	paddr_t start, end, pgstart, pgend;
 +	unsigned i;
 +
 +	start =3D round_page(avail_start);
 +	end =3D trunc_page(avail_end);
 +	KASSERT(start < end);
 +
 +	/*
 +	 * x86_freelists is in descending order of address limit.
 +	 * Iterate over the requested freelists in ascending order of
 +	 * limit, loading what pages we can.
 +	 */
 +	i =3D __arraycount(x86_freelists);
 +	while (0 < i--) {
 +		if (x86_freelists[i].limit =3D=3D 0) {
 +			/* Default freelist.  Put the rest here.  */
 +			KASSERT(x86_freelists[i].freelist =3D=3D
 +			    VM_FREELIST_DEFAULT);
 +			pgstart =3D atop(start);
 +			pgend =3D atop(end);
 +			uvm_page_physload(pgstart, pgend, pgstart, pgend,
 +			    VM_FREELIST_DEFAULT);
 +		} else if (x86_freelists[i].limit < start) {
 +			/* No pages live below here, so leave it empty.  */
 +			continue;
 +		} else if (x86_freelists[i].limit <=3D end) {
 +			/* Put what pages we can here, and move up.  */
 +			pgstart =3D atop(start);
 +			pgend =3D atop(x86_freelists[i].limit);
 +			uvm_page_physload(pgstart, pgend, pgstart, pgend,
 +			    x86_freelists[i].freelist);
 +			start =3D x86_freelists[i].limit;
 +		} else {
 +			/* All pages live below here, so use default.  */
 +			x86_freelists[i].freelist =3D VM_FREELIST_DEFAULT;
 +		}
 +	}
 +}
 +
 +#else
 =20
  #define KBTOB(x)	((size_t)(x) * 1024UL)
  #define MBTOB(x)	((size_t)(x) * 1024UL * 1024UL)
 =20
 -extern paddr_t avail_start, avail_end;
 -
  static int
  add_mem_cluster(phys_ram_seg_t *seg_clusters, int seg_cluster_cnt,
  	struct extent *iomem_ex,
 @@ -706,45 +789,6 @@ extern vaddr_t kern_end;
  extern vaddr_t module_start, module_end;
  #endif
 =20
 -static struct {
 -	int freelist;
 -	uint64_t limit;
 -} x86_freelists[VM_NFREELIST] =3D {
 -	{ VM_FREELIST_DEFAULT, 0 },
 -#ifdef VM_FREELIST_FIRST1T
 -	/* 40-bit addresses needed for modern graphics.  */
 -	{ VM_FREELIST_FIRST1T,	1ULL * 1024 * 1024 * 1024 * 1024 },
 -#endif
 -#ifdef VM_FREELIST_FIRST64G
 -	/* 36-bit addresses needed for oldish graphics.  */
 -	{ VM_FREELIST_FIRST64G,	64ULL * 1024 * 1024 * 1024 },
 -#endif
 -#ifdef VM_FREELIST_FIRST4G
 -	/* 32-bit addresses needed for PCI 32-bit DMA and old graphics.  */
 -	{ VM_FREELIST_FIRST4G,	4ULL * 1024 * 1024 * 1024 },
 -#endif
 -	/* 30-bit addresses needed for ancient graphics.  */
 -	{ VM_FREELIST_FIRST1G,	1ULL * 1024 * 1024 * 1024 },
 -	/* 24-bit addresses needed for ISA DMA.  */
 -	{ VM_FREELIST_FIRST16,	16 * 1024 * 1024 },
 -};
 -
 -int
 -x86_select_freelist(uint64_t maxaddr)
 -{
 -	unsigned int i;
 -
 -	if (avail_end <=3D maxaddr)
 -		return VM_NFREELIST;
 -
 -	for (i =3D 0; i < __arraycount(x86_freelists); i++) {
 -		if ((x86_freelists[i].limit - 1) <=3D maxaddr)
 -			return x86_freelists[i].freelist;
 -	}
 -
 -	panic("no freelist for maximum address %"PRIx64, maxaddr);
 -}
 -
  int
  initx86_load_memmap(paddr_t first_avail)
  {
 Index: sys/arch/xen/conf/files.xen
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 RCS file: /cvsroot/src/sys/arch/xen/conf/files.xen,v
 retrieving revision 1.137
 diff -p -u -r1.137 files.xen
 --- sys/arch/xen/conf/files.xen	4 Jan 2015 07:34:14 -0000	1.137
 +++ sys/arch/xen/conf/files.xen	6 Mar 2015 13:47:17 -0000
 @@ -134,6 +134,7 @@ file	arch/x86/x86/core_machdep.c	coredum
  file	arch/xen/x86/xen_bus_dma.c	machdep
  file	arch/x86/x86/bus_space.c	machdep
  file	arch/xen/x86/consinit.c		machdep
 +file	arch/x86/x86/genfb_machdep.c	machdep & genfb
  file	arch/x86/x86/identcpu.c		machdep
  file	arch/xen/x86/intr.c		machdep
  file	arch/xen/x86/xen_ipi.c		multiprocessor
 Index: sys/arch/xen/include/amd64/vmparam.h
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 RCS file: /cvsroot/src/sys/arch/xen/include/amd64/vmparam.h,v
 retrieving revision 1.2
 diff -p -u -r1.2 vmparam.h
 --- sys/arch/xen/include/amd64/vmparam.h	22 Nov 2007 16:17:02 -0000	1.2
 +++ sys/arch/xen/include/amd64/vmparam.h	6 Mar 2015 13:47:17 -0000
 @@ -32,7 +32,4 @@
  #undef VM_PHYSSEG_MAX
  #define	VM_PHYSSEG_MAX	1
 =20
 -#undef VM_NFREELIST
 -#undef VM_FREELIST_FIRST16
 -#define	VM_NFREELIST	1
  #endif /* _VMPARAM_H_ */
 Index: sys/arch/xen/xen/xen_acpi_machdep.c
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 RCS file: /cvsroot/src/sys/arch/xen/xen/xen_acpi_machdep.c,v
 retrieving revision 1.5
 diff -p -u -r1.5 xen_acpi_machdep.c
 --- sys/arch/xen/xen/xen_acpi_machdep.c	18 Aug 2009 16:41:03 -0000	1.5
 +++ sys/arch/xen/xen/xen_acpi_machdep.c	6 Mar 2015 13:47:17 -0000
 @@ -10,6 +10,8 @@ __KERNEL_RCSID(0, "$NetBSD: xen_acpi_mac
  #define ACPI_MACHDEP_PRIVATE
  #include <machine/acpi_machdep.h>
 =20
 +const int acpi_md_vesa_modenum =3D 0;
 +
  int
  acpi_md_sleep(int state)
  {

 --=_ngjbvaBAGjbjnb156wY3Fz/JsuWfskOa--

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: gnats-bugs@NetBSD.org, kern-bug-people@NetBSD.org, netbsd-bugs@NetBSD.org,
        gnats-admin@NetBSD.org, brad@anduin.eldar.org
Subject: Re: kern/49330 (Attempting to compile a Xen DOM0 and DRMKMS kernel
 doesn't compile)
Date: Mon, 9 Mar 2015 11:46:55 +0100

 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
 > 
 >    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>
      NetBSD: 26 ans d'experience feront toujours la difference
 --

From: Brad Spencer <brad@anduin.eldar.org>
To: bouyer@antioche.eu.org
Cc: riastradh@NetBSD.org, gnats-bugs@NetBSD.org, kern-bug-people@NetBSD.org,
        netbsd-bugs@NetBSD.org, gnats-admin@NetBSD.org
Subject: Re: kern/49330 (Attempting to compile a Xen DOM0 and DRMKMS kernel
 doesn't compile)
Date: Mon, 9 Mar 2015 13:44:42 -0400 (EDT)

    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
    > 
    >    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>
 	NetBSD: 26 ans d'experience feront toujours la difference
    --





 I was the one who submitted the original Bug regarding this issue and
 appreciate it getting looked at.  I probably can't aid with the
 development, but can help out with any testing.  I have a T530 laptop that
 I run Xen 4.2 with a NetBSD 6.x DOM0, and tons of guests of various types,
 and it would be truly a nice thing to be able to go to a NetBSD 7.x DOM0
 and actually use the non-vesa driver when running X.



 -- 
 Brad Spencer - brad@anduin.eldar.org - KC8VKS
 http://anduin.eldar.org  - & -  http://anduin.ipv6.eldar.org [IPv6 only]

From: Piotr Meyer <aniou@smutek.pl>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/49330
Date: Sun, 7 Jun 2015 23:35:19 +0200

 Small remark: as Xen/DRM user I'm also very interested in this case.
 Although I don't have skills to deal with that bug with bare hands but
 count me in for any testing or supporting work.

 -- 
 Piotr 'aniou' Meyer

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.