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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to