lkml.org 
[lkml]   [2010]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH V3] VFIO driver: Non-privileged user level PCI drivers
On Wed, Jul 28, 2010 at 04:13:19PM -0600, Alex Williamson wrote:
> On Thu, 2010-07-29 at 00:57 +0300, Michael S. Tsirkin wrote:
> > On Wed, Jul 28, 2010 at 03:57:02PM -0600, Alex Williamson wrote:
> > >
> > > Something like GET_MSIX_VECTORS seems like a user library routine to me.
> > > The PCI config space is well specified and if we try to do more than
> > > shortcut trivial operations (like getting the BAR length), we risk
> > > losing functionality. And for my purposes, translating to and from a
> > > made up API to PCI for the guest seems like a pain.
> >
> > Won't a userspace library do just as well for you?
>
> You mean aside from qemu's reluctance to add dependencies for more
> libraries?

Main reason is portability. So as long as it's kvm-only stuff, they
likely won't care.

> My only concern is that I want enough virtualized/raw config
> space that I'm not always translating PCI config accesses from the guest
> into some userspace API. If it makes sense to do this for things like
> MSI, since I need someone to figure out what resources can actually be
> allocated on the host, then maybe the library makes sense for that.
> Then again, if every user needs to do this, let the vfio kernel driver
> check what it can get and virtualize the available MSIs in exposed
> config space, and my driver would be even happier.
>
> Alex

It would? guest driver might or might not work if you reduce the number
of vectors for device. So I think you need an API to find out whether
all vectors can be allocated.

And these are examples of why virtualizing is wrong:
1. hides real hardware
2. no way to report errors

--
MST


\
 
 \ /
  Last update: 2010-07-29 16:35    [W:0.030 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site