xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ben Guthro <ben.guthro@virtualcomputer.com>
Cc: "Pavel Matěja" <pavel@netsafe.cz>,
	xen-devel@lists.xensource.com, tom.goetz@virtualcomputer.com
Subject: Re: ioperm problem
Date: Thu, 17 Nov 2011 12:30:10 -0500	[thread overview]
Message-ID: <20111117173010.GA3623@phenom.dumpdata.com> (raw)
In-Reply-To: <4EC51292.7000302@virtualcomputer.com>

On Thu, Nov 17, 2011 at 08:56:34AM -0500, Ben Guthro wrote:
> Attached is our patch to work around issues with the ioports with
> some older nVidia cards.
> 
> This, admittedly is a bit of a hack, and not exactly something that
> I would see upstream wanting to carry, for a variety of reasons. It
> really should all be predicated on whether the kernel is the initial
> domain, etc.
> 
> This opens up the legacy VGA ports in the VGA arbiter code.

Was there a userspace program that did this? As in it would
call ioperm?

> 
> Konrad - I think that you had suggested an alternate way of doing
> this, IIRC, but I can't seem to find it in my inbox. Due to
> competing demands, and my nVidia hardware disappearing, I never went
> back to rework this code.

Ah, I might have some code that I just uncovered from Jeremy's old
git tree.

I've put it up on devel/ioperm - it nicely wraps the ioperm
call to go the native or paravirt.

> 
> As written, however, it did solve the problem at hand - however
> hacky it may be.

<nods>

Pavel,

Can you try to merge the #devel/ioperm patches in your tree and see
if they fix your problem?

The git tree is at git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> 
> /btg
> 
> On 11/16/2011 09:57 AM, Konrad Rzeszutek Wilk wrote:
> >On Sun, Nov 13, 2011 at 10:19:06PM +0100, Pavel Matěja wrote:
> >>Hi,
> >>I'm trying to port AMD VGA passthru patch to the latest XEN and vanila kernel
> >>and I got SIGSEGV in
> >>
> >>static void ati_hw_out(uint16_t hport, uint32_t data)
> >>{
> >>     ioperm(gfx_info.host_pio_base, gfx_info.pio_size, 1);
> >>     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?
> >
> >
> >>
> >>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 similar
> >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?

> diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
> index ace2b16..d488426 100644
> --- a/drivers/gpu/vga/vgaarb.c
> +++ b/drivers/gpu/vga/vgaarb.c
> @@ -421,6 +421,50 @@ bail:
>  }
>  EXPORT_SYMBOL(vga_put);
>  
> +#ifdef CONFIG_XEN
> +#include <xen/xen.h>
> +#include <xen/interface/physdev.h>
> +#include <xen/interface/xen.h>
> +#include <asm/xen/hypervisor.h>
> +#include <asm/xen/hypercall.h>
> +
> +#define IO_BITMAP_BITS 65536
> +#define IO_BITMAP_BYTES (IO_BITMAP_BITS/8)
> +
> +#define VGA_START_PORT 0x3B0
> +#define VGA_END_PORT 0x3DF
> +
> +static void
> +vga_ioport_map(struct pci_dev *pdev)
> +{
> +	unsigned int i, j;
> +	struct physdev_set_iobitmap op;
> +	uint8_t *bitmap;
> +
> +	bitmap = kmalloc(IO_BITMAP_BYTES, GFP_KERNEL);
> +	memset(bitmap, 0xff, IO_BITMAP_BYTES);
> +
> +	/* PCI io bars */
> +	for (i = 0; i < PCI_NUM_RESOURCES; i++)
> +		if (pci_resource_flags(pdev, i) & IORESOURCE_IO)
> +			for (j = pci_resource_start(pdev, i);
> +				j <= pci_resource_end(pdev, i); j++)
> +				__clear_bit(j, (unsigned long*)bitmap);
> +
> +	/* legacy vga */
> +	for (i = VGA_START_PORT; i <= VGA_END_PORT; i++)
> +		__clear_bit(i, (unsigned long*)bitmap);
> +
> +	op.bitmap = bitmap;
> +	op.nr_ports = IO_BITMAP_BITS;
> +	if(HYPERVISOR_physdev_op(PHYSDEVOP_set_iobitmap, &op) != 0)
> +		pr_info("PHYSDEVOP_set_iobitmap failed\n");
> +
> +}
> +#else
> +#define vga_ioport_map(x)
> +#endif
> +
>  /*
>   * Currently, we assume that the "initial" setup of the system is
>   * not sane, that is we come up with conflicting devices and let
> @@ -509,6 +553,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev *pdev)
>  		vga_iostate_to_str(vgadev->owns),
>  		vga_iostate_to_str(vgadev->locks));
>  
> +	vga_ioport_map(pdev);
>  	spin_unlock_irqrestore(&vga_lock, flags);
>  	return true;
>  fail:

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

  reply	other threads:[~2011-11-17 17:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-13 21:19 ioperm problem Pavel Matěja
2011-11-16 14:57 ` Konrad Rzeszutek Wilk
2011-11-17 13:56   ` Ben Guthro
2011-11-17 17:30     ` Konrad Rzeszutek Wilk [this message]
2011-11-17 17:37       ` Alan Cox
2011-11-17 18:05       ` Jeremy Fitzhardinge
2011-11-17 20:29         ` Konrad Rzeszutek Wilk
2011-11-17 22:20         ` Ben Guthro
2011-11-18  8:13       ` Pavel Matěja

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111117173010.GA3623@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=ben.guthro@virtualcomputer.com \
    --cc=pavel@netsafe.cz \
    --cc=tom.goetz@virtualcomputer.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).