Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-09-10 Thread Alexey Kardashevskiy
On 29/08/17 12:58, Alexey Kardashevskiy wrote: > On 21/08/17 12:47, Alexey Kardashevskiy wrote: >> Folks, >> >> Ok, people did talk, exchanged ideas, lovely :) What happens now? Do I >> repost this or go back to PCI bus flags or something else? Thanks. > > > Anyone, any help? How do we proceed

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-09-10 Thread Alexey Kardashevskiy
On 29/08/17 12:58, Alexey Kardashevskiy wrote: > On 21/08/17 12:47, Alexey Kardashevskiy wrote: >> Folks, >> >> Ok, people did talk, exchanged ideas, lovely :) What happens now? Do I >> repost this or go back to PCI bus flags or something else? Thanks. > > > Anyone, any help? How do we proceed

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-28 Thread Alexey Kardashevskiy
On 21/08/17 12:47, Alexey Kardashevskiy wrote: > Folks, > > Ok, people did talk, exchanged ideas, lovely :) What happens now? Do I > repost this or go back to PCI bus flags or something else? Thanks. Anyone, any help? How do we proceed with this? Thanks. > > > > On 14/08/17 19:45, Alexey

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-28 Thread Alexey Kardashevskiy
On 21/08/17 12:47, Alexey Kardashevskiy wrote: > Folks, > > Ok, people did talk, exchanged ideas, lovely :) What happens now? Do I > repost this or go back to PCI bus flags or something else? Thanks. Anyone, any help? How do we proceed with this? Thanks. > > > > On 14/08/17 19:45, Alexey

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-20 Thread Alexey Kardashevskiy
Folks, Ok, people did talk, exchanged ideas, lovely :) What happens now? Do I repost this or go back to PCI bus flags or something else? Thanks. On 14/08/17 19:45, Alexey Kardashevskiy wrote: > Folks, > > Is there anything to change besides those compiler errors and David's > comment in 5/5?

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-20 Thread Alexey Kardashevskiy
Folks, Ok, people did talk, exchanged ideas, lovely :) What happens now? Do I repost this or go back to PCI bus flags or something else? Thanks. On 14/08/17 19:45, Alexey Kardashevskiy wrote: > Folks, > > Is there anything to change besides those compiler errors and David's > comment in 5/5?

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-17 Thread Alex Williamson
On Thu, 17 Aug 2017 10:56:35 + David Laight wrote: > From: Alex Williamson > > Sent: 16 August 2017 17:56 > ... > > Firmware pissing match... Processors running with 8k or less page size > > fall within the recommendations of the PCI spec for register alignment >

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-17 Thread Alex Williamson
On Thu, 17 Aug 2017 10:56:35 + David Laight wrote: > From: Alex Williamson > > Sent: 16 August 2017 17:56 > ... > > Firmware pissing match... Processors running with 8k or less page size > > fall within the recommendations of the PCI spec for register alignment > > of MMIO regions of the

RE: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-17 Thread David Laight
From: Alex Williamson > Sent: 16 August 2017 17:56 ... > Firmware pissing match... Processors running with 8k or less page size > fall within the recommendations of the PCI spec for register alignment > of MMIO regions of the device and this whole problem becomes less of an > issue. Actually if

RE: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-17 Thread David Laight
From: Alex Williamson > Sent: 16 August 2017 17:56 ... > Firmware pissing match... Processors running with 8k or less page size > fall within the recommendations of the PCI spec for register alignment > of MMIO regions of the device and this whole problem becomes less of an > issue. Actually if

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-16 Thread Benjamin Herrenschmidt
On Wed, 2017-08-16 at 10:56 -0600, Alex Williamson wrote: > > > WTF Alex, can you stop once and for all with all that "POWER is > > not standard" bullshit please ? It's completely wrong. > > As you've stated, the MSI-X vector table on POWER is currently updated > via a hypercall. POWER is

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-16 Thread Benjamin Herrenschmidt
On Wed, 2017-08-16 at 10:56 -0600, Alex Williamson wrote: > > > WTF Alex, can you stop once and for all with all that "POWER is > > not standard" bullshit please ? It's completely wrong. > > As you've stated, the MSI-X vector table on POWER is currently updated > via a hypercall. POWER is

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-16 Thread Alex Williamson
On Wed, 16 Aug 2017 10:35:49 +1000 Benjamin Herrenschmidt wrote: > On Tue, 2017-08-15 at 10:37 -0600, Alex Williamson wrote: > > Of course I don't think either of those are worth imposing a > > performance penalty where we don't otherwise need one. However, if we > >

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-16 Thread Alex Williamson
On Wed, 16 Aug 2017 10:35:49 +1000 Benjamin Herrenschmidt wrote: > On Tue, 2017-08-15 at 10:37 -0600, Alex Williamson wrote: > > Of course I don't think either of those are worth imposing a > > performance penalty where we don't otherwise need one. However, if we > > look at a VM scenario where

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-15 Thread Benjamin Herrenschmidt
On Tue, 2017-08-15 at 10:37 -0600, Alex Williamson wrote: > Of course I don't think either of those are worth imposing a > performance penalty where we don't otherwise need one. However, if we > look at a VM scenario where the guest is following the PCI standard for > programming MSI-X interrupts

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-15 Thread Benjamin Herrenschmidt
On Tue, 2017-08-15 at 10:37 -0600, Alex Williamson wrote: > Of course I don't think either of those are worth imposing a > performance penalty where we don't otherwise need one. However, if we > look at a VM scenario where the guest is following the PCI standard for > programming MSI-X interrupts

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-15 Thread Alex Williamson
On Mon, 14 Aug 2017 14:12:33 +0100 Robin Murphy wrote: > On 14/08/17 10:45, Alexey Kardashevskiy wrote: > > Folks, > > > > Is there anything to change besides those compiler errors and David's > > comment in 5/5? Or the while patchset is too bad? Thanks. > > While I now

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-15 Thread Alex Williamson
On Mon, 14 Aug 2017 14:12:33 +0100 Robin Murphy wrote: > On 14/08/17 10:45, Alexey Kardashevskiy wrote: > > Folks, > > > > Is there anything to change besides those compiler errors and David's > > comment in 5/5? Or the while patchset is too bad? Thanks. > > While I now understand it's not

RE: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-15 Thread David Laight
From: Benjamin Herrenschmidt > Sent: 15 August 2017 02:34 > On Tue, 2017-08-15 at 09:16 +0800, Jike Song wrote: > > > Taking a step back, though, why does vfio-pci perform this check in the > > > first place? If a malicious guest already has control of a device, any > > > kind of interrupt

RE: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-15 Thread David Laight
From: Benjamin Herrenschmidt > Sent: 15 August 2017 02:34 > On Tue, 2017-08-15 at 09:16 +0800, Jike Song wrote: > > > Taking a step back, though, why does vfio-pci perform this check in the > > > first place? If a malicious guest already has control of a device, any > > > kind of interrupt

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-14 Thread Benjamin Herrenschmidt
On Mon, 2017-08-14 at 14:12 +0100, Robin Murphy wrote: > On the other hand, if the check is not so much to mitigate malicious > guests attacking the system as to prevent dumb guests breaking > themselves (e.g. if some or all of the MSI-X capability is actually > emulated), then allowing things to

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-14 Thread Benjamin Herrenschmidt
On Mon, 2017-08-14 at 14:12 +0100, Robin Murphy wrote: > On the other hand, if the check is not so much to mitigate malicious > guests attacking the system as to prevent dumb guests breaking > themselves (e.g. if some or all of the MSI-X capability is actually > emulated), then allowing things to

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-14 Thread Benjamin Herrenschmidt
On Tue, 2017-08-15 at 09:47 +0800, Jike Song wrote: > On 08/15/2017 09:33 AM, Benjamin Herrenschmidt wrote: > > On Tue, 2017-08-15 at 09:16 +0800, Jike Song wrote: > > > > Taking a step back, though, why does vfio-pci perform this check in the > > > > first place? If a malicious guest already has

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-14 Thread Benjamin Herrenschmidt
On Tue, 2017-08-15 at 09:47 +0800, Jike Song wrote: > On 08/15/2017 09:33 AM, Benjamin Herrenschmidt wrote: > > On Tue, 2017-08-15 at 09:16 +0800, Jike Song wrote: > > > > Taking a step back, though, why does vfio-pci perform this check in the > > > > first place? If a malicious guest already has

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-14 Thread Benjamin Herrenschmidt
On Tue, 2017-08-15 at 09:16 +0800, Jike Song wrote: > > Taking a step back, though, why does vfio-pci perform this check in the > > first place? If a malicious guest already has control of a device, any > > kind of interrupt spoofing it could do by fiddling with the MSI-X > > message address/data

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-14 Thread Benjamin Herrenschmidt
On Tue, 2017-08-15 at 09:16 +0800, Jike Song wrote: > > Taking a step back, though, why does vfio-pci perform this check in the > > first place? If a malicious guest already has control of a device, any > > kind of interrupt spoofing it could do by fiddling with the MSI-X > > message address/data

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-14 Thread Jike Song
On 08/14/2017 09:12 PM, Robin Murphy wrote: > On 14/08/17 10:45, Alexey Kardashevskiy wrote: >> Folks, >> >> Is there anything to change besides those compiler errors and David's >> comment in 5/5? Or the while patchset is too bad? Thanks. > > While I now understand it's not the low-level thing I

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-14 Thread Jike Song
On 08/14/2017 09:12 PM, Robin Murphy wrote: > On 14/08/17 10:45, Alexey Kardashevskiy wrote: >> Folks, >> >> Is there anything to change besides those compiler errors and David's >> comment in 5/5? Or the while patchset is too bad? Thanks. > > While I now understand it's not the low-level thing I

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-14 Thread Jike Song
On 08/15/2017 09:33 AM, Benjamin Herrenschmidt wrote: > On Tue, 2017-08-15 at 09:16 +0800, Jike Song wrote: >>> Taking a step back, though, why does vfio-pci perform this check in the >>> first place? If a malicious guest already has control of a device, any >>> kind of interrupt spoofing it could

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-14 Thread Jike Song
On 08/15/2017 09:33 AM, Benjamin Herrenschmidt wrote: > On Tue, 2017-08-15 at 09:16 +0800, Jike Song wrote: >>> Taking a step back, though, why does vfio-pci perform this check in the >>> first place? If a malicious guest already has control of a device, any >>> kind of interrupt spoofing it could

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-14 Thread Robin Murphy
On 14/08/17 10:45, Alexey Kardashevskiy wrote: > Folks, > > Is there anything to change besides those compiler errors and David's > comment in 5/5? Or the while patchset is too bad? Thanks. While I now understand it's not the low-level thing I first thought it was, so my reasoning has changed,

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-14 Thread Robin Murphy
On 14/08/17 10:45, Alexey Kardashevskiy wrote: > Folks, > > Is there anything to change besides those compiler errors and David's > comment in 5/5? Or the while patchset is too bad? Thanks. While I now understand it's not the low-level thing I first thought it was, so my reasoning has changed,

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-14 Thread Alexey Kardashevskiy
Folks, Is there anything to change besides those compiler errors and David's comment in 5/5? Or the while patchset is too bad? Thanks. On 07/08/17 17:25, Alexey Kardashevskiy wrote: > This is a followup for "[PATCH kernel v4 0/6] vfio-pci: Add support for > mmapping MSI-X table" >

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-14 Thread Alexey Kardashevskiy
Folks, Is there anything to change besides those compiler errors and David's comment in 5/5? Or the while patchset is too bad? Thanks. On 07/08/17 17:25, Alexey Kardashevskiy wrote: > This is a followup for "[PATCH kernel v4 0/6] vfio-pci: Add support for > mmapping MSI-X table" >

[RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-07 Thread Alexey Kardashevskiy
This is a followup for "[PATCH kernel v4 0/6] vfio-pci: Add support for mmapping MSI-X table" http://www.spinics.net/lists/kvm/msg152232.html This time it is using "caps" in IOMMU groups. The main question is if PCI bus flags or IOMMU domains are still better (and which one). Here is some

[RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

2017-08-07 Thread Alexey Kardashevskiy
This is a followup for "[PATCH kernel v4 0/6] vfio-pci: Add support for mmapping MSI-X table" http://www.spinics.net/lists/kvm/msg152232.html This time it is using "caps" in IOMMU groups. The main question is if PCI bus flags or IOMMU domains are still better (and which one). Here is some