* Tom Lyon (p...@lyon-about.com) wrote:
> On Friday 09 April 2010 02:58:19 am Avi Kivity wrote:
> > - access to all config space, but BARs must be translated so userspace
> > cannot attack the host
> Please elaborate. All of PCI config? All of PCIe config? Seems like a huge
> mess.
All of config
* Avi Kivity (a...@redhat.com) wrote:
> On 04/02/2010 08:05 PM, Greg KH wrote:
> - access to all config space, but BARs must be translated so
> userspace cannot attack the host
Specifically, intermediated access to config space. For example, need
to know about MSI/MSI-X updates in config space.
On 04/09/2010 07:34 PM, Tom Lyon wrote:
- access to all config space, but BARs must be translated so userspace
cannot attack the host
Please elaborate. All of PCI config? All of PCIe config? Seems like a huge mess.
Yes. Anything a guest's device driver may want to access.
The 'che
On Fri, Apr 09, 2010 at 09:34:16AM -0700, Tom Lyon wrote:
> The 'check' items are already done, not fully tested; probably available next
> week.
> Can we leave the others for future patches? Please? And I definitely need
> help with
> the PCI config stuff.
Yeah, go in small steps forward. Just
On Friday 09 April 2010 02:58:19 am Avi Kivity wrote:
> On 04/02/2010 08:05 PM, Greg KH wrote:
> >
> >> Currently kvm does device assignment with its own code, I'd like to unify
> >> it with uio, not split it off.
> >>
> >> Separate notifications for msi-x interrupts are just as useful for uio as
>
On 04/02/2010 08:05 PM, Greg KH wrote:
Currently kvm does device assignment with its own code, I'd like to unify
it with uio, not split it off.
Separate notifications for msi-x interrupts are just as useful for uio as
they are for kvm.
I agree, there should not be a difference here for
On Fri, Apr 02, 2010 at 09:43:35AM +0300, Avi Kivity wrote:
> On 04/01/2010 10:24 PM, Tom Lyon wrote:
>>
>>> But there are multiple msi-x interrupts, how do you know which one
>>> triggered?
>>>
>> You don't. This would suck for KVM, I guess, but we'd need major rework of
>> the
>> generic U
On 04/02/2010 12:27 AM, Tom Lyon wrote:
kvm really wants the event counter to be an eventfd, that allows hooking
it directly to kvm (which can inject an interrupt on an eventfd_signal),
can you adapt your patch to do this?
I looked further into eventfds - they seem the perfect solution f
On 04/01/2010 10:24 PM, Tom Lyon wrote:
But there are multiple msi-x interrupts, how do you know which one
triggered?
You don't. This would suck for KVM, I guess, but we'd need major rework of the
generic UIO stuff to have a separate event channel for each MSI-X.
Doesn't it suck fo
On Thursday 01 April 2010 08:54:14 am Avi Kivity wrote:
> On 04/01/2010 06:39 PM, Tom Lyon wrote:
> >>> - support for MSI and MSI-X interrupts (the intel 82599 VFs support
> >>> only MSI-X)
> >>
> >> How does a userspace program receive those interrupts?
> >
> > Same as other UIO drivers - by read(
On Thu, Apr 01, 2010 at 12:24:45PM -0700, Tom Lyon wrote:
> For my purposes, collapsing all the MSI-Xs into one MSI-look-alike is fine,
> because I'd be using MSI anyways if I could. The weird Intel 82599 VF only
> supports MSI-X.
For KVM this is not fine. The device should look in the guest as
On Thu, Apr 01, 2010 at 12:18:27PM -0700, Tom Lyon wrote:
> On Thursday 01 April 2010 09:07:47 am Joerg Roedel wrote:
> > For the KVM use-case we need to be able to specify the io virtual
> > address for a given process virtual address. This is not possible with
> > the dma-api interface. So if we
On Thursday 01 April 2010 09:10:57 am Avi Kivity wrote:
> On 04/01/2010 07:06 PM, Tom Lyon wrote:
> > On Thursday 01 April 2010 08:54:14 am Avi Kivity wrote:
> >> On 04/01/2010 06:39 PM, Tom Lyon wrote:
> > - support for MSI and MSI-X interrupts (the intel 82599 VFs support
> > only MSI-X)
On Thursday 01 April 2010 09:07:47 am Joerg Roedel wrote:
> On Thu, Apr 01, 2010 at 08:40:34AM -0700, Tom Lyon wrote:
> > On Thursday 01 April 2010 05:52:18 am Joerg Roedel wrote:
> > > > The point of this patch is to beef up the uio_pci_generic driver so
> > > > that a non-privileged user process
On Wed, Mar 31, 2010 at 05:08:38PM -0700, Tom Lyon wrote:
> uio_pci_generic has previously been discussed on the KVM list, but this patch
> has nothing to do with KVM, so it is also going to LKML.
Just a side note: It would be nice if you Cc:'ed the UIO maintainers (Greg
and me) on patches like t
On Thu, Apr 01, 2010 at 05:25:04PM +0300, Michael S. Tsirkin wrote:
> On Wed, Mar 31, 2010 at 05:08:38PM -0700, Tom Lyon wrote:
> > uio_pci_generic has previously been discussed on the KVM list, but this
> > patch
> > has nothing to do with KVM, so it is also going to LKML.
> >
> > The point of
On Wed, Mar 31, 2010 at 05:08:38PM -0700, Tom Lyon wrote:
> uio_pci_generic has previously been discussed on the KVM list, but this patch
> has nothing to do with KVM, so it is also going to LKML.
>
> The point of this patch is to beef up the uio_pci_generic driver so that a
> non-privileged use
On 04/01/2010 07:06 PM, Tom Lyon wrote:
On Thursday 01 April 2010 08:54:14 am Avi Kivity wrote:
On 04/01/2010 06:39 PM, Tom Lyon wrote:
- support for MSI and MSI-X interrupts (the intel 82599 VFs support
only MSI-X)
How does a userspace program receive those interrupts?
On 04/01/2010 03:08 AM, Tom Lyon wrote:
uio_pci_generic has previously been discussed on the KVM list, but this patch
has nothing to do with KVM, so it is also going to LKML.
(needs to go to lkml even if it was for kvm)
The point of this patch is to beef up the uio_pci_generic driver so t
On 04/01/2010 06:39 PM, Tom Lyon wrote:
- support for MSI and MSI-X interrupts (the intel 82599 VFs support only
MSI-X)
How does a userspace program receive those interrupts?
Same as other UIO drivers - by read()ing an event counter.
IIRC the usual event counter is /dev/u
On Thursday 01 April 2010 08:54:14 am Avi Kivity wrote:
> On 04/01/2010 06:39 PM, Tom Lyon wrote:
> >>> - support for MSI and MSI-X interrupts (the intel 82599 VFs support
> >>> only MSI-X)
> >>
> >> How does a userspace program receive those interrupts?
> >
> > Same as other UIO drivers - by read(
On Thu, Apr 01, 2010 at 08:40:34AM -0700, Tom Lyon wrote:
> On Thursday 01 April 2010 05:52:18 am Joerg Roedel wrote:
> > > The point of this patch is to beef up the uio_pci_generic driver so that
> > > a non-privileged user process can run a user level driver for most PCIe
> > > devices. This can
On Thursday 01 April 2010 07:25:04 am Michael S. Tsirkin wrote:
> On Wed, Mar 31, 2010 at 05:08:38PM -0700, Tom Lyon wrote:
> > uio_pci_generic has previously been discussed on the KVM list, but this
> > patch has nothing to do with KVM, so it is also going to LKML.
> >
> > The point of this patch
On Thursday 01 April 2010 05:52:18 am Joerg Roedel wrote:
> On Wed, Mar 31, 2010 at 05:08:38PM -0700, Tom Lyon wrote:
> > uio_pci_generic has previously been discussed on the KVM list, but this
> > patch has nothing to do with KVM, so it is also going to LKML.
>
> But since you send it to the KVM l
On Thursday 01 April 2010 02:09:09 am Avi Kivity wrote:
> On 04/01/2010 03:08 AM, Tom Lyon wrote:
> > uio_pci_generic has previously been discussed on the KVM list, but this
> > patch has nothing to do with KVM, so it is also going to LKML.
>
> (needs to go to lkml even if it was for kvm)
>
> > The
On Wed, Mar 31, 2010 at 05:08:38PM -0700, Tom Lyon wrote:
> uio_pci_generic has previously been discussed on the KVM list, but this patch
> has nothing to do with KVM, so it is also going to LKML.
But since you send it to the KVM list it should be suitable for KVM too,
no?
> The point of this pa
uio_pci_generic has previously been discussed on the KVM list, but this patch
has nothing to do with KVM, so it is also going to LKML.
The point of this patch is to beef up the uio_pci_generic driver so that a
non-privileged user process can run a user level driver for most PCIe
devices. This c
27 matches
Mail list logo