Re: [PATCH v3 0/2] kvm: level irqfd and new eoifd

2012-07-16 Thread Avi Kivity
On 07/16/2012 05:03 PM, Alex Williamson wrote: >> >> This is what I meant, except I forgot that we already do direct path for >> MSI. > > Ok, vfio now does it for the unmask irqfd-line interface too. Except > when we re-inject from eoifd we have to do the eventfd_signal from a > work queue as we

Re: [PATCH v3 0/2] kvm: level irqfd and new eoifd

2012-07-16 Thread Alex Williamson
On Sun, 2012-07-15 at 13:09 +0300, Avi Kivity wrote: > On 07/12/2012 08:38 PM, Alex Williamson wrote: > > On Thu, 2012-07-12 at 10:19 -0600, Alex Williamson wrote: > >> On Thu, 2012-07-12 at 12:35 +0300, Avi Kivity wrote: > >> > On 07/11/2012 10:57 PM, Alex Williamson wrote: > >> > >> > >> > >> >

Re: [PATCH v3 0/2] kvm: level irqfd and new eoifd

2012-07-16 Thread Alex Williamson
On Sun, 2012-07-15 at 11:33 +0300, Avi Kivity wrote: > On 07/12/2012 07:19 PM, Alex Williamson wrote: > > On Thu, 2012-07-12 at 12:35 +0300, Avi Kivity wrote: > >> On 07/11/2012 10:57 PM, Alex Williamson wrote: > >> >> > >> >> > We still have classic KVM device assignment to provide fast-path INTx

Re: [PATCH v3 0/2] kvm: level irqfd and new eoifd

2012-07-15 Thread Avi Kivity
On 07/12/2012 08:38 PM, Alex Williamson wrote: > On Thu, 2012-07-12 at 10:19 -0600, Alex Williamson wrote: >> On Thu, 2012-07-12 at 12:35 +0300, Avi Kivity wrote: >> > On 07/11/2012 10:57 PM, Alex Williamson wrote: >> > >> >> > >> > We still have classic KVM device assignment to provide fast-path

Re: [PATCH v3 0/2] kvm: level irqfd and new eoifd

2012-07-15 Thread Avi Kivity
On 07/12/2012 07:19 PM, Alex Williamson wrote: > On Thu, 2012-07-12 at 12:35 +0300, Avi Kivity wrote: >> On 07/11/2012 10:57 PM, Alex Williamson wrote: >> >> >> >> > We still have classic KVM device assignment to provide fast-path INTx. >> >> > But if we want to replace it midterm, I think it's ne

Re: [PATCH v3 0/2] kvm: level irqfd and new eoifd

2012-07-12 Thread Alex Williamson
On Thu, 2012-07-12 at 10:19 -0600, Alex Williamson wrote: > On Thu, 2012-07-12 at 12:35 +0300, Avi Kivity wrote: > > On 07/11/2012 10:57 PM, Alex Williamson wrote: > > >> > > >> > We still have classic KVM device assignment to provide fast-path INTx. > > >> > But if we want to replace it midterm,

Re: [PATCH v3 0/2] kvm: level irqfd and new eoifd

2012-07-12 Thread Alex Williamson
On Thu, 2012-07-12 at 12:35 +0300, Avi Kivity wrote: > On 07/11/2012 10:57 PM, Alex Williamson wrote: > >> > >> > We still have classic KVM device assignment to provide fast-path INTx. > >> > But if we want to replace it midterm, I think it's necessary for VFIO to > >> > be able to provide such a

Re: [PATCH v3 0/2] kvm: level irqfd and new eoifd

2012-07-12 Thread Avi Kivity
On 07/11/2012 10:57 PM, Alex Williamson wrote: >> >> > We still have classic KVM device assignment to provide fast-path INTx. >> > But if we want to replace it midterm, I think it's necessary for VFIO to >> > be able to provide such a path as well. >> >> I would like VFIO to have no regressions v

Re: [PATCH v3 0/2] kvm: level irqfd and new eoifd

2012-07-11 Thread Alex Williamson
On Wed, 2012-07-11 at 14:51 +0300, Avi Kivity wrote: > On 07/11/2012 02:23 PM, Jan Kiszka wrote: > >> > >> I'd appreciate a couple of examples for formality's sake. > > > > From the top of my head: NVIDIA FX3700 (granted, legacy by now), Atheros > > AR9287. For others, I need to check. > > Thank

Re: [PATCH v3 0/2] kvm: level irqfd and new eoifd

2012-07-11 Thread Avi Kivity
On 07/11/2012 02:23 PM, Jan Kiszka wrote: >> >> I'd appreciate a couple of examples for formality's sake. > > From the top of my head: NVIDIA FX3700 (granted, legacy by now), Atheros > AR9287. For others, I need to check. Thanks. >> >>> And then there is not easily replaceable legacy hardware

Re: [PATCH v3 0/2] kvm: level irqfd and new eoifd

2012-07-11 Thread Jan Kiszka
On 2012-07-11 12:49, Avi Kivity wrote: > On 07/11/2012 01:18 PM, Jan Kiszka wrote: >> On 2012-07-11 11:53, Avi Kivity wrote: >>> On 07/03/2012 10:21 PM, Alex Williamson wrote: Here's the latest iteration of adding an interface to assert and de-assert level interrupts from external drivers

Re: [PATCH v3 0/2] kvm: level irqfd and new eoifd

2012-07-11 Thread Avi Kivity
On 07/11/2012 01:18 PM, Jan Kiszka wrote: > On 2012-07-11 11:53, Avi Kivity wrote: >> On 07/03/2012 10:21 PM, Alex Williamson wrote: >>> Here's the latest iteration of adding an interface to assert and >>> de-assert level interrupts from external drivers like vfio. These >>> apply on top of the pr

Re: [PATCH v3 0/2] kvm: level irqfd and new eoifd

2012-07-11 Thread Jan Kiszka
On 2012-07-11 11:53, Avi Kivity wrote: > On 07/03/2012 10:21 PM, Alex Williamson wrote: >> Here's the latest iteration of adding an interface to assert and >> de-assert level interrupts from external drivers like vfio. These >> apply on top of the previous argument cleanup, documentation, and >> s

Re: [PATCH v3 0/2] kvm: level irqfd and new eoifd

2012-07-11 Thread Avi Kivity
On 07/03/2012 10:21 PM, Alex Williamson wrote: > Here's the latest iteration of adding an interface to assert and > de-assert level interrupts from external drivers like vfio. These > apply on top of the previous argument cleanup, documentation, and > sanitization patches for irqfd. It would be g

[PATCH v3 0/2] kvm: level irqfd and new eoifd

2012-07-03 Thread Alex Williamson
Here's the latest iteration of adding an interface to assert and de-assert level interrupts from external drivers like vfio. These apply on top of the previous argument cleanup, documentation, and sanitization patches for irqfd. It would be great to get this queued in next for linux 3.6. I belie