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 wi
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 K
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? O
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 d
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 q
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 o
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
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
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 th
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 spoofing
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 s
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 c
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
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 i
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
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, pe
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"
> http://www.s
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 bac
18 matches
Mail list logo
