Hi Peter,
On 13/03/2017 18:58, Peter Maydell wrote:
> On 6 March 2017 at 12:48, Eric Auger wrote:
>> We need to handle both registers and ITS tables. While
>> register handling is standard, ITS table handling is more
>> challenging since the kernel API is devised so that the
>> tables are flushed
Hi Peter,
On 13/03/2017 19:03, Peter Maydell wrote:
> On 6 March 2017 at 12:48, Eric Auger wrote:
>> We change the restoration priority of both the GICv3 and ITS. The
>> GICv3 must be restored before the ITS and the ITS needs to be restored
>> before PCIe devices since it translates their MSI tra
Hi Peter,
On 12/08/2016 16:19, Peter Maydell wrote:
> On 2 August 2016 at 19:07, Eric Auger wrote:
>> From: Pavel Fedin
>>
>> Introduce global kvm_arm_msi_use_devid flag and pass device IDs in
>> kvm_arch_fixup_msi_route(). Device IDs are required by the ITS.
>>
>> Signed-off-by: Pavel Fedin
>>
Hi Peter,
On 12/08/2016 16:12, Peter Maydell wrote:
> On 2 August 2016 at 19:07, Eric Auger wrote:
>> From: Pavel Fedin
>>
>> This is the basic skeleton for both KVM and software-emulated ITS.
>> Since we already prepare status structure, we also introduce complete
>> VMState description. But, b
Hi Peter,
On 12/08/2016 16:03, Peter Maydell wrote:
> On 2 August 2016 at 19:07, Eric Auger wrote:
>> From: Pavel Fedin
>>
>> The ITS control frame is in-kernel emulated while accesses to the
>> GITS_TRANSLATER are mediated through the KVM_SIGNAL_MSI ioctl (MSI
>> direct MSI injection advertised
Hi Shanker,
Adding Alex in CC for (*)
On 14/08/2016 17:42, Shanker Donthineni wrote:
> This patch introduces the Qualcomm Technologies, Inc HIDMA device and
> allows passthrough the host HIDMA device to a guest machine using the
> vfio-platform framework.
>
> A platform device tree node is creat
Hi Alex,
On 19/08/2016 00:35, Alexander Graf wrote:
>
>> On 18 Aug 2016, at 05:37, Auger Eric wrote:
>>
>> Hi Shanker,
>>
>> Adding Alex in CC for (*)
>>
>> On 14/08/2016 17:42, Shanker Donthineni wrote:
>>> This patch introduces the
Hi Peter,
On 20/01/2017 16:52, Peter Maydell wrote:
> On 10 October 2016 at 17:35, Andrew Jones wrote:
>> We should avoid exposing new hardware (through DT and ACPI) on older
>> machine types. This patch keeps 2.7 and older from changing, despite
>> the introduction of ITS support for 2.8.
>>
>>
Hi,
On 13/06/2017 15:31, Eric Auger wrote:
> This series implements INTx to gsi routing for ARM VIRT/GPEX. This is
> a respin of [1] which was lost in limbo.
>
> ARM virt uses GPEX PCIe bridge. This latter does not implement INTx
> to GSI routing. PCIe/INTx assignment works but the consequence is
Hi Bharat,
On 04/07/2017 11:13, Bharat Bhushan wrote:
> Hi Eric,
>
>> -Original Message-
>> From: Eric Auger [mailto:eric.au...@redhat.com]
>> Sent: Wednesday, June 07, 2017 9:31 PM
>> To: eric.auger@gmail.com; eric.au...@redhat.com;
>> peter.mayd...@linaro.org; alex.william...@redhat
Hi Bharat,
On 05/07/2017 10:23, Bharat Bhushan wrote:
> Hi Eric,
>
>> -Original Message-----
>> From: Auger Eric [mailto:eric.au...@redhat.com]
>> Sent: Monday, June 26, 2017 1:25 PM
>> To: Bharat Bhushan ;
>> eric.auger@gmail.com; peter.mayd...@linar
Hello Bharat, Jean-Philippe,
On 06/07/2017 12:02, Jean-Philippe Brucker wrote:
> On 05/07/17 09:49, Bharat Bhushan wrote:>>> Also when setup msi-route
> kvm_irqchip_add_msi_route() we needed to
>>> provide the translated address.
According to my understanding this is required because kernel do
Hi Bharat,
On 06/07/2017 13:24, Bharat Bhushan wrote:
>
>
>> -Original Message-
>> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
>> Sent: Thursday, July 06, 2017 3:33 PM
>> To: Bharat Bhushan ; Auger Eric
>> ; eric.auger@gm
On 07/07/2017 08:25, Bharat Bhushan wrote:
> Hi Eric,
>
>> -Original Message-----
>> From: Auger Eric [mailto:eric.au...@redhat.com]
>> Sent: Friday, July 07, 2017 2:47 AM
>> To: Bharat Bhushan ; Jean-Philippe Brucker
>> ; eric.auger@gmail.com;
>&
Hi,
On 06/07/2017 23:11, Auger Eric wrote:
> Hello Bharat, Jean-Philippe,
> On 06/07/2017 12:02, Jean-Philippe Brucker wrote:
>> On 05/07/17 09:49, Bharat Bhushan wrote:>>> Also when setup msi-route
>> kvm_irqchip_add_msi_route() we needed to
>>>> provide
Hi Peter,
On 30/05/2017 17:56, Peter Maydell wrote:
> On 13 May 2017 at 18:43, Eric Auger wrote:
>> Introduces the base device and class for the ARM smmu.
>> Implements VMSAv8-64 table lookup and translation. VMSAv8-32
>> is not yet implemented.
>>
>> For VFIO integration we will need to notify m
Hi Peter,
On 30/05/2017 18:01, Peter Maydell wrote:
> On 13 May 2017 at 18:43, Eric Auger wrote:
>> From: Prem Mallappa
>>
>> Introduces the SMMUv3 derived model. This is based on
>> System MMUv3 specification (v17).
>>
>> Signed-off-by: Prem Mallappa
>> Signed-off-by: Eric Auger
>>
>> ---
>> v
Hi Peter,
On 30/05/2017 18:04, Peter Maydell wrote:
> On 13 May 2017 at 18:43, Eric Auger wrote:
>> The new machine type allows smmuv3 instantiation. A new option
>> is introduced to turn the feature on/off (off by default).
>
> Should we go for default-on, or would that break guests?
> For othe
Hi Peter,
On 30/05/2017 18:09, Peter Maydell wrote:
> On 13 May 2017 at 18:43, Eric Auger wrote:
>> This series introduces the emulation code for ARM SMMUv3.
>> This is the continuation of Prem's work [1].
>>
>> This v4 is yet another visibility step as many restrictions apply
>> to the model at
Hi Bharat,
On 14/07/2017 09:25, Bharat Bhushan wrote:
> Translate msi address if device is behind virtio-iommu.
> This logic is similar to vSMMUv3/Intel iommu emulation.
Why Intel?
>
> This RFC patch does not handle the case where both vsmmuv3 and
> virtio-iommu are available.
I think this should
Hi Bharat,
On 14/07/2017 09:25, Bharat Bhushan wrote:
> This patch allows virtio-iommu protection for PCI
> device-passthrough.
>
> MSI region is mapped by current version of virtio-iommu driver.
> This MSI region mapping in not getting pushed on hw iommu
> vfio_get_vaddr() allows only ram-region
Hi Linu, Jean,
On 17/08/2017 15:39, Jean-Philippe Brucker wrote:
> Hi Linu,
>
> On 17/08/17 12:26, Linu Cherian wrote:
>> Hi Eric,
>>
>> On Tue Aug 01, 2017 at 11:33:06AM +0200, Eric Auger wrote:
>>> This series implements the virtio-iommu device.
>>>
>>> This v3 mostly is a rebase on top of v2.1
Hi Linu,
On 23/08/2017 06:24, Linu Cherian wrote:
> Hi Eric,
>
>
> On Fri Aug 11, 2017 at 04:22:33PM +0200, Eric Auger wrote:
>> This patch allows doing PCIe passthrough with a guest exposed
>> with a vSMMUv3. It implements the replay and notify_flag_changed
>> iommu ops. Also on TLB and data st
Hi Bharat,
On 21/08/2017 12:48, Bharat Bhushan wrote:
> This V3 version is mainly about rebasing on v3 version on Virtio-iommu device
> framework from Eric Augur and addresing review comments.
s/Augur/Auger ;-)
>
> This patch series allows PCI pass-through using virtio-iommu.
>
> This series i
Hi Geetha, Tomasz,
On 12/07/2017 19:24, Geetha Akula wrote:
> Hi Eric
>
>
>> This series implements the emulation code for ARM SMMUv3.
>> This is the continuation of Prem's work [1].
>>
>> This v5 mainly brings VFIO integration in DT mode. On guest kernel
>> side, this requires a quirk [1] to fo
Hi Diana,
On 23/05/2017 13:12, Diana Craciun wrote:
> Device IDs are required by the ARM GICv3 ITS for IRQ remapping.
> Currently, for PCI devices, the requester ID was used as device
> ID in the virt machine. If the system has multiple masters that
if the system has multiple root complex?
> use MS
Hi Diana,
On 23/05/2017 13:12, Diana Craciun wrote:
> The PCI requester ID field is 16 bits. The requester_id field
> from MemTxAttrs is used for MSIs to specify the device ID for
> the platforms where this device ID is needed (e.g virt machine + GICv3
> ITS). However, if more entities that uses MS
Hi Tomasz,
On 13/07/2017 14:57, Tomasz Nowicki wrote:
> Hi Eric,
>
> On 09.07.2017 22:51, Eric Auger wrote:
>> From: Prem Mallappa
>>
>> Introduces the SMMUv3 derived model. This is based on
>> System MMUv3 specification (v17).
>>
>> Signed-off-by: Prem Mallappa
>> Signed-off-by: Eric Auger
>>
Hi Tomasz,
On 13/07/2017 14:00, Tomasz Nowicki wrote:
> Hi Eric,
>
> On 09.07.2017 22:51, Eric Auger wrote:
>> From: Prem Mallappa
>>
>> Introduces the SMMUv3 derived model. This is based on
>> System MMUv3 specification (v17).
>>
>> Signed-off-by: Prem Mallappa
>> Signed-off-by: Eric Auger
>>
Hi Tomasz,
On 25/07/2017 14:12, Tomasz Nowicki wrote:
> Hi Eric,
>
> I found out what is going on regarding vhost-net outgoing packet's
> payload corruption. My packets were corrupted because of inconsistent
> IOVA to HVA translation in IOTLB. Please see below.
>
> On 09.07.2017 22:51, Eric Auge
Hi Peter, Bharat,
On 17/07/2017 03:28, Peter Xu wrote:
> On Fri, Jul 14, 2017 at 06:40:34AM +, Bharat Bhushan wrote:
>> Hi Peter,
>>
>>> -Original Message-
>>> From: Peter Xu [mailto:pet...@redhat.com]
>>> Sent: Friday, July 14, 2017 7:48 AM
>>> To: Eric Auger
>>> Cc: eric.auger@g
Hi Tomasz,
On 01/08/2017 13:01, Tomasz Nowicki wrote:
> Hi Eric,
>
> Just letting you know that I am facing another issue with the following
> setup:
> 1. host (4.12 kernel & 64K page) and VM (4.12 kernel & 64K page)
> 2. QEMU + -netdev type=tap,ifname=tap,id=net0 -device
> virtio-net-pci,netdev=n
Hi Tomasz,
On 03/08/2017 12:11, Tomasz Nowicki wrote:
> Hi Eric,
>
> On 01.08.2017 15:07, Auger Eric wrote:
>> Hi Tomasz,
>> On 01/08/2017 13:01, Tomasz Nowicki wrote:
>>> Hi Eric,
>>>
>>> Just letting you know that I am facing another issue with t
Hi Drew,
On 07/08/2017 09:06, Andrew Jones wrote:
> On Fri, Aug 04, 2017 at 06:42:54PM +0100, Peter Maydell wrote:
>> Hi; I noticed today that the virt board doesn't have a virt-2.10
>> machine type defined. Do we need to add it before release?
>>
>> (I don't know if there have in fact been any cha
Hi Michael,
On 27/07/2017 03:30, Michael Roth wrote:
> DEVICE_DEL is currently emitted when a Device is unparented, as
> opposed to when it is finalized. The main design motivation for this
> seems to be that after unparent()/unrealize(), the Device is no
> longer visible to the guest, and thus th
Hi Michael,
On 27/07/2017 03:30, Michael Roth wrote:
> This series was motivated by the discussion in this thread:
>
> https://www.redhat.com/archives/libvir-list/2017-June/msg01370.html
>
> The issue this series addresses is that when libvirt unplugs a VFIO PCI
> device,
> it may attempt to
Hi Alexey,
On 23/01/18 02:22, Alexey Kardashevskiy wrote:
> This makes use of a new VFIO_REGION_INFO_CAP_MSIX_MAPPABLE capability
> which tells that a region with MSIX data can be mapped entirely, i.e.
> the VFIO PCI driver won't prevent MSIX vectors area from being mapped.
>
> With this change, a
Hi Alex,
On 23/01/18 20:56, Alex Williamson wrote:
> On Fri, 19 Jan 2018 14:15:43 +0100
> Auger Eric wrote:
>
>> Hi,
>>
>> On 19/01/18 04:25, Alex Williamson wrote:
>>> On Fri, 19 Jan 2018 13:41:41 +1100
>>> Alexey Kardashevskiy wrote:
>>
Hi Alex,
On 23/01/18 20:55, Alex Williamson wrote:
> On Tue, 23 Jan 2018 16:34:34 +0100
> Auger Eric wrote:
>
>> Hi Alexey,
>> On 23/01/18 02:22, Alexey Kardashevskiy wrote:
>>> This makes use of a new VFIO_REGION_INFO_CAP_MSIX_MAPPABLE capability
>>> which
Hi Alex,
On 24/01/18 16:02, Alex Williamson wrote:
> On Wed, 24 Jan 2018 15:13:06 +0100
> Auger Eric wrote:
>
>> Hi Alex,
>> On 23/01/18 20:55, Alex Williamson wrote:
>>> On Tue, 23 Jan 2018 16:34:34 +0100
>>> Auger Eric wrote:
>>>
>>>
evskiy
Reviewed-by: Eric Auger
Eric
> ---
> hw/vfio/common.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> index b77be3a..3d652c8 100644
> --- a/hw/vfio/common.c
> +++ b/hw/vfio/common.c
> @@ -435,7 +435,6 @@ static void
Hi Alexey,
On 25/01/18 05:22, Alexey Kardashevskiy wrote:
> This makes use of a new VFIO_REGION_INFO_CAP_MSIX_MAPPABLE capability
> which tells that a region with MSIX data can be mapped entirely, i.e.
> the VFIO PCI driver won't prevent MSIX vectors area from being mapped.
>
> With this change,
Hi,
On 25/01/18 14:56, Auger Eric wrote:
> Hi Alexey,
>
> On 25/01/18 05:22, Alexey Kardashevskiy wrote:
>> This makes use of a new VFIO_REGION_INFO_CAP_MSIX_MAPPABLE capability
>> which tells that a region with MSIX data can be mapped entirely, i.e.
>> the VFIO PC
Hi Alexey,
On 29/01/18 04:55, Alexey Kardashevskiy wrote:
> On 26/01/18 00:56, Auger Eric wrote:
>> Hi Alexey,
>>
>> On 25/01/18 05:22, Alexey Kardashevskiy wrote:
>>> This makes use of a new VFIO_REGION_INFO_CAP_MSIX_MAPPABLE capability
>>> which tells tha
Hi Linu,
On 04/10/2017 13:49, Linu Cherian wrote:
> Hi Eric,
>
>
> On Wed Sep 27, 2017 at 11:24:01AM +0200, Auger Eric wrote:
>> Hi Linu,
>>
>> On 27/09/2017 11:21, Linu Cherian wrote:
>>> On Wed Sep 27, 2017 at 10:55:07AM +0200, Auger Eric wrote:
>
Hi Linu,
On 05/10/2017 12:46, Auger Eric wrote:
> Hi Linu,
> On 04/10/2017 13:49, Linu Cherian wrote:
>> Hi Eric,
>>
>>
>> On Wed Sep 27, 2017 at 11:24:01AM +0200, Auger Eric wrote:
>>> Hi Linu,
>>>
>>> On 27/09/2017 11:21, Linu Cherian w
Hi Linu,
On 05/10/2017 13:54, Auger Eric wrote:
> Hi Linu,
> On 05/10/2017 12:46, Auger Eric wrote:
>> Hi Linu,
>> On 04/10/2017 13:49, Linu Cherian wrote:
>>> Hi Eric,
>>>
>>>
>>> On Wed Sep 27, 2017 at 11:24:01AM +0200, Auger Eric wrote:
>
Hi Linu,
On 05/10/2017 14:13, Auger Eric wrote:
> Hi Linu,
>
> On 05/10/2017 13:54, Auger Eric wrote:
>> Hi Linu,
>> On 05/10/2017 12:46, Auger Eric wrote:
>>> Hi Linu,
>>> On 04/10/2017 13:49, Linu Cherian wrote:
>>>> Hi Eric,
>>>>
Hi Bharat,
On 06/10/2017 05:46, Bharat Bhushan wrote:
>
>
Thanks
Eric
>
> However you should be allowed to map 1 sg element of 5 pages and
> then notify the host about this event I think. Still looking at the
> code...
>
> I still can't reproduce the issue
Hi Bharat,
On 10/10/2017 08:42, Bharat Bhushan wrote:
> Hi Alex, Eric,
>
>> -Original Message-
>> From: Qemu-devel [mailto:qemu-devel-
>> bounces+bharat.bhushan=nxp@nongnu.org] On Behalf Of Bharat
>> Bhushan
>> Sent: Friday, October 06, 2017 9:16
Hi Peter,
On 09/10/2017 20:17, Peter Maydell wrote:
> On 27 September 2017 at 15:56, Eric Auger wrote:
>> At the moment the ITS is not properly reset. On System reset or
>> reboot, previous ITS register values and caches are left
>> unchanged. Some of the registers might point to some guest RAM
>
Hi Peter,
On 11/10/2017 16:56, Peter Maydell wrote:
> On 19 September 2017 at 08:46, Eric Auger wrote:
>> This series implements the virtio-iommu device.
>>
>> This v4 is an upgrade to v0.4 spec [1] and applies on QEMU v2.10.0.
>> - probe request support although no reserved region is returned at
Hi Peter,
On 12/10/2017 11:54, Peter Maydell wrote:
> On 11 October 2017 at 17:08, Auger Eric wrote:
>> Hi Peter,
>>
>> On 11/10/2017 16:56, Peter Maydell wrote:
>>> On 19 September 2017 at 08:46, Eric Auger wrote:
>>>> This series implements the vi
Hi Kevin,
On 13/10/2017 09:01, Tian, Kevin wrote:
>> From: Auger Eric [mailto:eric.au...@redhat.com]
>> Sent: Thursday, October 12, 2017 6:10 PM
>>
>> Hi Peter,
>>
>> On 12/10/2017 11:54, Peter Maydell wrote:
>>> On 11 October 2017 at 17:08, Auger E
Hi Alex,
On 05/12/17 22:09, Alex Williamson wrote:
> Commit 8c37faa475f3 ("vfio-pci, ppc64/spapr: Reorder group-to-container
> attaching") moved registration of groups with the vfio-kvm device from
> vfio_get_group() to vfio_connect_container(), but it missed the case
> where a group is attached t
Hi Shameer,
On 06/12/17 11:30, Shameerali Kolothum Thodi wrote:
> Hi Alex,
>
>> -Original Message-
>> From: Shameerali Kolothum Thodi
>> Sent: Monday, November 20, 2017 4:31 PM
>> To: 'Alex Williamson'
>> Cc: eric.au...@redhat.com; Zhuyijun ; qemu-
>> a...@nongnu.org; qemu-devel@nongnu.o
Hi Shameer,
On 06/12/17 15:38, Shameerali Kolothum Thodi wrote:
> Hi Eric,
>
>> -Original Message-----
>> From: Auger Eric [mailto:eric.au...@redhat.com]
>> Sent: Wednesday, December 06, 2017 2:01 PM
>> To: Shameerali Kolothum Thodi ;
>> Alex Williamson
&
Hi Yi L,
On 14/11/2017 14:59, Liu, Yi L wrote:
> On Tue, Nov 14, 2017 at 09:53:07AM +0100, Auger Eric wrote:
> Hi Eric,
>
>> Hi Yi L,
>>
>> On 13/11/2017 10:58, Liu, Yi L wrote:
>>> On Mon, Nov 13, 2017 at 04:56:01PM +1100, David Gibson wrote:
>>>&g
Hi Peter,
On 23/11/17 16:19, Peter Maydell wrote:
> On 23 November 2017 at 14:56, Eric Auger wrote:
>> At the moment the ITS is not properly reset. On System reset or
>> reboot, previous ITS register values and caches are left
>> unchanged. Some of the registers might point to some guest RAM
>> t
Hi Cornelia, Peter,
On 23/11/17 18:14, Cornelia Huck wrote:
> On Thu, 23 Nov 2017 17:01:32 +
> Peter Maydell wrote:
>
>> On 23 November 2017 at 16:05, Auger Eric wrote:
>>> When using update-linux-headers.sh I get suspicious errors at the end:
>>> grep
Hi,
On 23/11/17 19:01, Christian Borntraeger wrote:
>
>
> On 11/23/2017 06:44 PM, Auger Eric wrote:
>> Hi Cornelia, Peter,
>>
>> On 23/11/17 18:14, Cornelia Huck wrote:
>>> On Thu, 23 Nov 2017 17:01:32 +
>>> Peter Maydell wrote:
>>>
Hi Peter,
On 24/11/17 11:11, Peter Maydell wrote:
> On 24 November 2017 at 09:43, Eric Auger wrote:
>> Add virt-2.11 machine type.
>>
>> Signed-off-by: Eric Auger
>>
>> ---
>
> Argh, did we forget this again?
Yes we did, please apologize for that.
I think we should just
> make a rule that we
Hi Peter,
On 24/11/17 14:34, Peter Maydell wrote:
> On 24 November 2017 at 13:30, Eric Auger wrote:
>> At the moment the ITS is not properly reset and this causes
>> various bugs on save/restore. We implement a minimalist reset
>> through individual register writes but for kernel versions
>> befor
Hi Peter,
On 24/11/17 14:38, Peter Maydell wrote:
> On 24 November 2017 at 13:30, Eric Auger wrote:
>> Update headers against post v4.14 and pre v4.15-rc0.
>>
>> Signed-off-by: Eric Auger
>> ---
>> include/standard-headers/asm-s390/virtio-ccw.h | 1 +
>> include/standard-headers/asm-x86/h
Hi Peter,
On 24/11/17 15:20, Peter Maydell wrote:
> On 24 November 2017 at 14:18, Eric Auger wrote:
>> At the moment the ITS is not properly reset. On System reset or
>> reboot, previous ITS register values and caches are left
>> unchanged. Some of the registers might point to some guest RAM
>> t
Hi Peter,
On 24/11/17 15:35, Peter Maydell wrote:
> On 24 November 2017 at 14:32, Auger Eric wrote:
>> On 24/11/17 15:20, Peter Maydell wrote:
>>> Thanks. My remaining question is: how important it is to
>>> put some of this into 2.11? We're getting quite clo
Hi Alexey,
On 16/01/18 06:17, Alexey Kardashevskiy wrote:
> On 06/01/18 02:29, Alex Williamson wrote:
>> On Fri, 5 Jan 2018 10:48:07 +0100
>> Auger Eric wrote:
>>
>>> Hi Alexey,
>>>
>>> On 15/12/17 07:29, Alexey Kardashevskiy wrote:
>>>>
Hi Alex,
On 10/01/18 20:02, Alex Williamson wrote:
> Recently proposed vfio-pci kernel changes (v4.16) remove the
> restriction preventing userspace from mmap'ing PCI BARs in areas
> overlapping the MSI-X vector table. This change is primarily intended
> to benefit host platforms which make use o
Hi Alex,
On 10/01/18 20:01, Alex Williamson wrote:
> v1: https://lists.gnu.org/archive/html/qemu-devel/2017-12/msg03350.html
>
> See patch 5/5 for a thorough description. v2 changes the 'auto'
> behavior as we've determined that there's no algorithm which has even
> a likely chance of success. I
;>>> On 06/01/18 02:29, Alex Williamson wrote:
>>>>> On Fri, 5 Jan 2018 10:48:07 +0100
>>>>> Auger Eric wrote:
>>>>>
>>>>>> Hi Alexey,
>>>>>>
>>>>>> On 15/12/17 07:29, Alexey Kardashevski
Hi Alex,
On 19/01/18 16:23, Alex Williamson wrote:
> Hi Eric,
>
> On Fri, 19 Jan 2018 10:50:53 +0100
> Auger Eric wrote:
>
>> Hi Alex,
>>
>> On 10/01/18 20:02, Alex Williamson wrote:
>>> Recently proposed vfio-pci kernel changes (v4.16) remove the
Hi Peter,
On 13/03/2017 19:03, Peter Maydell wrote:
> On 6 March 2017 at 12:48, Eric Auger wrote:
>> We change the restoration priority of both the GICv3 and ITS. The
>> GICv3 must be restored before the ITS and the ITS needs to be restored
>> before PCIe devices since it translates their MSI tran
Hi Edgar,
removing Prem's address which is not valid anymore
On 27/03/2017 13:44, Edgar E. Iglesias wrote:
> On Wed, Mar 08, 2017 at 06:46:13PM +0100, Auger Eric wrote:
>> Hi,
>> On 22/08/2016 18:17, Prem Mallappa wrote:
>>> v1 -> v2:
>>>
Hi Peter,
On 28/03/2017 13:29, Peter Maydell wrote:
> On 28 March 2017 at 12:22, Prakash B wrote:
>> Qemu master or v2.9.0-rc1 doesn't launch guest when host kernel
>> version 4.10 or lower on Aarch64 (cavium ThunderX), its failing with
>> abort "qemu-system-aarch64: KVM_GET_DEVICE_ATTR failed
Adding Prakash B in cc too, sorry.
Vijaya, please let me know if I missed something in your original patch.
I tested GICv3 KVM save/restore with v4.11-rc4 and Prakash B use case
with 4.10 kernel.
Thanks
Eric
On 28/03/2017 15:58, Eric Auger wrote:
> KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS needs to be
Hi Vijay,
On 28/03/2017 17:08, Vijay Kilari wrote:
> Hi Eric,
>
> On Tue, Mar 28, 2017 at 7:28 PM, Eric Auger wrote:
>> KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS needs to be checked before
>> attempting to read ICC_CTLR_EL1; otherwise kernel versions not
>> exposing this kvm device group will be incompat
Hi Alex,
On 28/03/2017 19:24, Alexander Graf wrote:
> On 02/23/2017 07:37 PM, Peter Maydell wrote:
>> On 23 February 2017 at 11:51, wrote:
>>> From: Vijaya Kumar K
>>>
>>> Reset CPU interface registers of GICv3 when CPU is reset.
>>> For this, ARMCPRegInfo struct is registered with one ICC
>>>
Hi Juan,
On 28/03/2017 21:45, Juan Quintela wrote:
> Eric Auger wrote:
>> We need to handle both registers and ITS tables. While
>> register handling is standard, ITS table handling is more
>> challenging since the kernel API is devised so that the
>> tables are flushed into guest RAM and not in
Hi Juan,
On 28/03/2017 21:47, Juan Quintela wrote:
> Eric Auger wrote:
>> We change the restoration priority of both the GICv3 and ITS. The
>> GICv3 must be restored before the ITS and the ITS needs to be restored
>> before PCIe devices since it translates their MSI transactions.
>>
>> Signed-off
Hi Juan,
On 28/03/2017 21:45, Juan Quintela wrote:
> Eric Auger wrote:
>> We need to handle both registers and ITS tables. While
>> register handling is standard, ITS table handling is more
>> challenging since the kernel API is devised so that the
>> tables are flushed into guest RAM and not in
Hi Radha,
On 01/04/2017 02:56, Radha Mohan wrote:
> Hi Eric
>
> On Thu, Mar 30, 2017 at 12:42 PM, Eric Auger wrote:
>> This series introduces the emulation code for ARM SMMUv3.
>> This is the continuation of Prem's work [1].
>>
>> At the moment only AArch64 translation format is supported, ie.
>
Hi Peter,
On 06/04/2017 09:08, Peter Xu wrote:
> In this patch, IOMMUNotifier.{start|end} are introduced to store section
> information for a specific notifier. When notification occurs, we not
> only check the notification type (MAP|UNMAP), but also check whether the
> notified iova range overlaps
Hi Peter,
On 06/04/2017 09:08, Peter Xu wrote:
> Reviewed-by: David Gibson
> Signed-off-by: Peter Xu
Even if the commit message is obvious it may be requested?
Reviewed-by: Eric Auger
> ---
> include/exec/memory.h | 3 +++
> memory.c | 4 ++--
> 2 files changed, 5 insertions(+),
Hi Peter,
On 06/04/2017 09:08, Peter Xu wrote:
> This is an "global" version of exising memory_region_iommu_replay() - we
s/exising/existing
> announce the translations to all the registered notifiers, instead of a
> specific one.
>
> Reviewed-by: David Gibson
> Signed-off-by: Peter Xu
> ---
>
Hi Peter,
On 06/04/2017 09:08, Peter Xu wrote:
> Generalizing the notify logic in memory_region_notify_iommu() into a
> single function. This can be further used in customized replay()
> functions for IOMMUs.
>
> Reviewed-by: David Gibson
> Signed-off-by: Peter Xu
Reviewed-by: Eric Auger
Thank
Hi Peter,
On 06/04/2017 09:08, Peter Xu wrote:
> Originally we have one memory_region_iommu_replay() function, which is
> the default behavior to replay the translations of the whole IOMMU
> region. However, on some platform like x86, we may want our own replay
> logic for IOMMU regions. This patc
Hi,
On 06/04/2017 13:12, Peter Xu wrote:
> On Thu, Apr 06, 2017 at 12:45:59PM +0200, Auger Eric wrote:
>> Hi Peter,
>> On 06/04/2017 09:08, Peter Xu wrote:
>>> Reviewed-by: David Gibson
>>> Signed-off-by: Peter Xu
>> Even if the commit message is obviou
Hi Alex,
On 12/4/18 5:26 PM, Alex Williamson wrote:
> Create properties to be able to define speeds and widths for PCIe
> links. The only tricky bit here is that our get and set callbacks
> translate from the fixed QAPI automagic enums to those we define
> in PCI code to represent the actual regi
Hi Markus,
On 12/5/18 3:16 PM, Markus Armbruster wrote:
> Auger Eric writes:
>
>> Hi Alex,
>>
>> On 12/4/18 5:26 PM, Alex Williamson wrote:
>>> Create properties to be able to define speeds and widths for PCIe
>>> links. The only tricky bit here is th
Hi
On 12/4/18 5:26 PM, Alex Williamson wrote:
> In preparation for reporting higher virtual link speeds and widths,
> create enums and macros to help us manage them.
>
> Cc: Michael S. Tsirkin
> Cc: Marcel Apfelbaum
> Tested-by: Geoffrey McRae
> Signed-off-by: Alex Williamson
Reviewed-by: Eri
Hi,
On 12/4/18 5:26 PM, Alex Williamson wrote:
> Add fields allowing the PCIe link speed and width of a PCIESlot to
> be configured, with an instance_post_init callback on the root port
> parent class to set defaults. This allows child classes to set these
> via properties or via their own instan
Hi Alex,
On 12/4/18 5:26 PM, Alex Williamson wrote:
> Make use of the PCIESlot speed and width fields to update link
> information beyond those configured in pcie_cap_v1_fill(). This is
> only called for devices supporting a version 2 capability and
> automatically skips any non-PCIESlot devices.
Hi Alex,
On 12/4/18 5:26 PM, Alex Williamson wrote:
> The PCIe link speed and width between a downstream device and its
> upstream port is negotiated on real hardware and susceptible to
> dynamic changes due to signal issues and power management. In the
> emulated device case there is no real har
Hi
On 12/4/18 5:27 PM, Alex Williamson wrote:
> Now that the downstream port will virtually negotiate itself to the
> link status of the downstream devie, we can remove this emulation.
s/devie/device
> It's not clear that it was every terribly useful anyway.
>
> Tested-by: Geoffrey McRae
> Signed
Hi,
On 12/4/18 5:27 PM, Alex Williamson wrote:
> Including all machine types that might have a pcie-root-port.
>
> Cc: Peter Maydell
> Cc: Michael S. Tsirkin
> Cc: Marcel Apfelbaum
> Cc: Paolo Bonzini
> Cc: Richard Henderson
> Cc: Eduardo Habkost
> Acked-by: David Gibson
> Signed-off-by: A
Hi
On 12/4/18 5:27 PM, Alex Williamson wrote:
> Change the default speed and width for new machine types to the
> fastest and widest currently supported. This should be compatible to
> the PCIe 4.0 spec. Pre-QEMU-4.0 machine types remain at 2.5GT/s, x1
> width.
>
> Cc: Michael S. Tsirkin
> Cc:
Hi,
On 12/4/18 5:26 PM, Alex Williamson wrote:
> Allow users to experimentally specify speed and width values for the
> generic PCIe root port. Defaults remain at 2.5GT/s & x1 for
> compatiblity with the intent to only support changing defaults via
> machine types for now.
>
> Note for libvirt t
Hi Alex,
On 12/6/18 5:00 PM, Alex Williamson wrote:
> On Thu, 6 Dec 2018 12:08:09 +0100
> Auger Eric wrote:
>
>> Hi Alex,
>>
>> On 12/4/18 5:26 PM, Alex Williamson wrote:
>>> Make use of the PCIESlot speed and width fields to update link
>&g
Hi Jean,
On 11/14/18 5:01 PM, Jean-Philippe Brucker wrote:
> On 09/11/2018 11:29, Eric Auger wrote:
>> +static void create_virtio_iommu(VirtMachineState *vms,
>> +const char *pciehb_nodename, PCIBus *bus)
>> +{
>> +const char compat[] = "virtio,pci-iommu";
>> +
Hi Jean, Bharat,
On 11/14/18 5:41 PM, Auger Eric wrote:
> Hi Jean,
>
> On 11/14/18 5:01 PM, Jean-Philippe Brucker wrote:
>> On 09/11/2018 11:29, Eric Auger wrote:
>>> +static void create_virtio_iommu(VirtMachineState *vms,
>>> +co
201 - 300 of 1369 matches
Mail list logo
