From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: ioperm problem Date: Wed, 16 Nov 2011 09:57:30 -0500 Message-ID: <20111116145730.GA11502@phenom.dumpdata.com> References: <201111132219.07211.pavel@netsafe.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <201111132219.07211.pavel@netsafe.cz> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Pavel =?utf-8?Q?Mat=C4=9Bja?= , Ben Guthro , tom.goetz@virtualcomputer.com Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Sun, Nov 13, 2011 at 10:19:06PM +0100, Pavel Mat=C4=9Bja wrote: > Hi, > I'm trying to port AMD VGA passthru patch to the latest XEN and vanila = kernel=20 > and I got SIGSEGV in >=20 > static void ati_hw_out(uint16_t hport, uint32_t data) > { > ioperm(gfx_info.host_pio_base, gfx_info.pio_size, 1); =20 > asm volatile ("out %1, %0"::"Nd"(hport),"a"(data)); > ioperm(gfx_info.host_pio_base, gfx_info.pio_size, 0); > } Does it work under baremetal? What is the host_pio_base? Is the host_pio_base part of the permitted IO ports? (you can see that if you run 'xl debug-keys q' and it should show you something like this: (XEN) Rangesets belonging to domain 1: (XEN) I/O Ports { b400-b41f, b800-b81f } (XEN) Interrupts { 18-19, 54-55 } (XEN) I/O Memory { fe940-fe9ff } (XEN) Memory pages belonging to domain 1: (you can get that from xm dmesg). As you can see, the b400->b41f are allowed in the domain 1. Is your host_pio_base in there? >=20 > I tried old 2.6.32 XEN kernel and there is no such problem. > It looks related to arch/x86/kernel/ioport.c but I'm not sure. > Is anyone here familiar with that code? Yes, and I think I saw somebody ask me about that too. Lets rope them in this converstation - they got it to work but my memory is foggy at what was required. Ben, Thomas, I remember you guys had a tough time with vd86 which did something simila= r and it ultimately was due to to /dev/mem not passing in VM_IO. But the ioperm/outb sounds familiar too. Was there a missing hypercall when forking/copying the ioperm bitmap?