On Wed, Apr 21, 2010 at 12:31:50PM +0200, Hans J. Koch wrote:
> On Wed, Apr 21, 2010 at 12:38:49PM +0300, Michael S. Tsirkin wrote:
> >
> > > + j++;
> > > + }
> > > + }
> > > + for (i = 0, j = 0; i < PCI_STD_RESOURCE_END &&
> > > + j < MAX_UIO_PORT_REGIONS; i++) {
> > > + if (pci_resource_flags(pdev, i) & IORESOURCE_IO) {
> > > + name = kmalloc(8, GFP_KERNEL);
> > > + if (name == NULL)
> > > + break;
> > > + sprintf(name, "iobar%d", i);
> > > + info->port[j].name = name;
> > > + info->port[j].start = pci_resource_start(pdev, i);
> > > + info->port[j].size = pci_resource_len(pdev, i);
> > > + info->port[j].porttype = UIO_PORT_X86;
> > > + j++;
> >
> > At least on x86, I think io bar can not be mmapped.
>
> That's right. porttype == UIO_PORT_X86 is only there for information
> purposes. Userspace then knows that it cannot map this but has to use
> things like inb(), outb() and friends after getting access rights with
> ioperm()/iopl(). "start" and "size" gives userspace the information
> needed to do this.
>
> Thanks,
> Hans
So that fails in the declared purpose of allowing an unpriveledged
userspace driver, as inb/outb are priveledged operations.
--
MST
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
