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
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
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 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
Hi Sebastian,
On Fri, Aug 11, 2017 at 07:02:36PM +0200, Sebastian Ott wrote:
> ..but I found the bug, actually 2 bugs:
>
> * That patch embedded a struct iommu_device within struct zpci_dev but
> the iommu_device has a release function (via its class) - so when
> the release function gets called
Hi,
We're working with a number of platforms based on Intel Apollo Lake
and there are some clues suggesting that the IR-PCI-MSI irqchip
functionality would be able to get us out of a tricky situation
described at:
ath9k hardware corrupts MSI Message Data, raises wrong interrupt
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,
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"
>
On 14/08/17 09:27, Tian, Kevin wrote:
>> * First, since the IOMMU is paravirtualized, the device can expose some
>> properties of the physical topology to the guest, and let it allocate
>> resources more efficiently. For example, when the virtio-iommu manages
>> both physical and emulated
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Saturday, August 5, 2017 2:19 AM
>
> This is the continuation of my proposal for virtio-iommu, the para-
> virtualized IOMMU. Here is a summary of the changes since last time [1]:
>
> * The virtio-iommu document now
> From: Raj, Ashok
> Sent: Saturday, August 12, 2017 12:25 AM
>
> On Fri, Aug 04, 2017 at 10:42:41AM +0100, Jean-Philippe Brucker wrote:
> > Hi Kevin,
> >
> >
> > Consider the situation where a userspace driver (no virtualization) is
> > built in a client-server fashion: the server controls a
> From: valmiki [mailto:valmiki...@gmail.com]
> Sent: Saturday, August 12, 2017 8:11 PM
>
> On 8/7/2017 4:01 PM, Jean-Philippe Brucker wrote:
> > On 05/08/17 06:14, valmiki wrote:
> > [...]
> >> Hi Jean, Thanks a lot, now i understood the flow. From vfio kernel
> >> documentation we fill vaddr
12 matches
Mail list logo
