Forgive me if this discussion is not relative here, but I thought it is.
How is VFIO restricting devices from writing to MSI/MSI-X,
Is all the vector area is mapped by VFIO to trap the accesses. I am asking
this because we might need to emulate ITS somewhere either in KVM or VFIO to
provide
When I say emulating ITS, I mean translating guest ITS commands to physical ITS
commands and placing them in physical queue.
Regards,
Tirumalesh.
-Original Message-
From: kvmarm-boun...@lists.cs.columbia.edu
[mailto:kvmarm-boun...@lists.cs.columbia.edu] On Behalf Of Chalamarla
Sorry there was a type,
The question is:
How is VFIO restricting software from writing to MSI/MSI-X vectors
of the device.
-Original Message-
From: Chalamarla, Tirumalesh
Sent: Thursday, June 26, 2014 11:16 AM
To: Chalamarla, Tirumalesh; Joerg Roedel; Will Deacon
Cc: k
ssage-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Thursday, June 26, 2014 12:00 PM
To: Chalamarla, Tirumalesh
Cc: Joerg Roedel; Will Deacon; k...@vger.kernel.org; open list;
stuart.yo...@freescale.com; io...@lists.linux-foundation.org;
t...@virtualopensystems.com
[mailto:will.dea...@arm.com]
Sent: Friday, June 27, 2014 1:47 AM
To: Alex Williamson
Cc: Chalamarla, Tirumalesh; Joerg Roedel; k...@vger.kernel.org; open list;
stuart.yo...@freescale.com; io...@lists.linux-foundation.org;
t...@virtualopensystems.com; kvm...@lists.cs.columbia.edu; moderated
> On May 22, 2015, at 1:26 AM, Marc Zyngier wrote:
>
> On 20/05/15 13:48, Robert Richter wrote:
>> Mark,
>>
>> thanks for review, also of the other patches of this series.
>>
>> See below
>>
>> On 20.05.15 13:11:38, Marc Zyngier wrote:
- dev_alias->dev_id = alias;
+ dev_alias->dev
looks good. possible to describe the chip we have.
> On Jul 23, 2015, at 9:52 AM, Mark Rutland wrote:
>
> Currently msi-parent is used by a few bindings to describe the
> relationship between a PCI root complex and a single MSI controller, but
> this property does not have a generic binding docum
the discussion on the generic cpu seems to be stuck, is there a possibility to
take this patch. so that Thunder has a chance to run some KVM.
Thanks,
Tirumalesh.
> On Jun 29, 2015, at 10:11 AM, Marc Zyngier wrote:
>
> On 29/06/15 18:06, Chalamarla, Tirumalesh wrote:
>>
>
On 4/17/17, 12:35 AM, "Imran Khan" wrote:
On 4/12/2017 7:30 PM, Chalamarla, Tirumalesh wrote:
>
>
> On 4/11/17, 10:13 PM, "linux-arm-kernel on behalf of Imran Khan"
wrote:
>
> On 4/7/2017 7:36 AM, Ganesh Mahendran wrote:
On 4/11/17, 10:13 PM, "linux-arm-kernel on behalf of Imran Khan"
wrote:
On 4/7/2017 7:36 AM, Ganesh Mahendran wrote:
> 2017-04-06 23:58 GMT+08:00 Catalin Marinas :
>> On Thu, Apr 06, 2017 at 12:52:13PM +0530, Imran Khan wrote:
>>> On 4/5/2017 10:13 AM, Imran Khan wrote:
>>>
On 2/27/17, 11:02 AM, "David Daney" wrote:
On 02/14/2017 07:07 AM, Bjorn Helgaas wrote:
> On Mon, Feb 13, 2017 at 09:44:57PM -0700, Alex Williamson wrote:
>> On Sat, 30 Jan 2016 01:33:58 +0530
>> Manish Jaggi wrote:
>>
>>> Cavium devices matching this quirk do not perfo
Hi Eric,
Does this series supports gicv3-its emulation?
Do we have a tree with all the dependent patches
Thanks,
Tirumalesh.
On 5/4/16, 8:18 AM, "linux-arm-kernel on behalf of Eric Auger"
wrote:
>This series implements the MSI address mapping/unmapping in the MSI layer.
>IOMMU binding hap
On 5/4/16, 4:54 AM, "linux-arm-kernel on behalf of Eric Auger"
wrote:
>On x86 IRQ remapping is abstracted by the IOMMU. On ARM this is abstracted
>by the msi controller. vfio_safe_irq_domain allows to check whether
>interrupts are "safe" for a given device. They are if the device does
>not
On 5/4/16, 4:54 AM, "linux-arm-kernel on behalf of Eric Auger"
wrote:
>The user is allowed to register a reserved MSI IOVA range by using the
>DMA MAP API and setting the new flag: VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA.
>This region is stored in the vfio_dma rb tree. At that point the iova
>r
On 5/9/16, 12:48 AM, "Eric Auger" wrote:
>Hi Chalarmala,
>On 05/05/2016 07:44 PM, Chalamarla, Tirumalesh wrote:
>> Hi Eric,
>>
>> Does this series supports gicv3-its emulation?
>> Do we have a tree with all the dependent patches
>GICv3 ITS emu
On 5/10/16, 12:34 AM, "Eric Auger" wrote:
>Hi Chalamarla,
>> On 5/9/16, 12:48 AM, "Eric Auger" wrote:
>>
>>> Hi Chalarmala,
>>> On 05/05/2016 07:44 PM, Chalamarla, Tirumalesh wrote:
>>>> Hi Eric,
>>>>
>>&g
On 3/16/16, 2:32 AM, "linux-arm-kernel on behalf of Ganesh Mahendran"
wrote:
>Reverts commit 97303480753e ("arm64: Increase the max granular size").
>
>The commit 97303480753e ("arm64: Increase the max granular size") will
>degrade system performente in some cpus.
>
>We test wifi network th
On 3/21/16, 10:33 AM, "Catalin Marinas" wrote:
>On Mon, Mar 21, 2016 at 05:23:01PM +, Will Deacon wrote:
>> On Mon, Mar 21, 2016 at 05:14:03PM +, Catalin Marinas wrote:
>> > diff --git a/arch/arm64/include/asm/cache.h
>> > b/arch/arm64/include/asm/cache.h
>> > index 5082b30bc2c0..4b
Hi Marc,
Any feed back on this.
Do you want me to submit this as a separate patch?so that it is easy for
getting acceptance.
Thanks,
Tirumalesh.
> On Sep 24, 2014, at 8:37 AM, Robert Richter wrote:
>
> From: Tirumalesh Chalamarla
>
> The PCIe host controller uses MSIs provided by GICv3 I
> On Jun 29, 2015, at 1:53 AM, Marc Zyngier wrote:
>
> On 26/06/15 20:51, Tirumalesh Chalamarla wrote:
>> In order to allow KVM to run on Thunder implementations, add the
>> minimal support required.
>>
>> Signed-off-by: Tirumalesh Chalamarla
>
> CCing the KVM/ARM maintainers should be the fi
Hi Catalin,
is it possible to pull this for 4.2?
Thanks,
Tirumalesh.
> On Jun 26, 2015, at 12:12 PM, Tirumalesh Chalamarla
> wrote:
>
> From: Tirumalesh Chalamarla
>
> The PCIe host controller uses MSIs provided by GICv3 ITS. Enable it on
> Thunder SoCs by adding an entry to DT.
>
> Signe
21 matches
Mail list logo
