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:
We still have classic
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 can't
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 necessary for VFIO
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 INTx.
But if
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 vs. kvm device
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 path as well.
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, I think it's
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
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
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 previous
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 like vfio.
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 like old
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.
Thanks.
And
13 matches
Mail list logo
