Hi Thomas,
On 19/07/2016 16:38, Thomas Gleixner wrote:
> On Tue, 19 Jul 2016, Eric Auger wrote:
>> msi_doorbell_pages sum up the number of iommu pages of a given order
>
> adding () to the function name would make it immediately clear that
> msi_doorbell_pages is a function.
>
>> +/**
>> + * msi_
Hi Thomas,
On 19/07/2016 16:22, Thomas Gleixner wrote:
> On Tue, 19 Jul 2016, Eric Auger wrote:
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +struct irqchip_doorbell {
>> +struct irq_chip_msi_doorbell_info info;
>> +struct list_head next;
>
> Again, please align the struct member
Hi Dennis
On 20/07/2016 11:56, Dennis Chen wrote:
> Hi Eric,
>
> On Tue, Jul 19, 2016 at 12:55:03PM +, Eric Auger wrote:
>> This series introduces the msi-iommu api used to:
>>
>> - allocate/free resources for MSI IOMMU mapping
>> - set the MSI iova window aperture
>> - map/unmap physical addr
Hi Thomas,
On 19/07/2016 16:38, Thomas Gleixner wrote:
> On Tue, 19 Jul 2016, Eric Auger wrote:
>> msi_doorbell_pages sum up the number of iommu pages of a given order
>
> adding () to the function name would make it immediately clear that
> msi_doorbell_pages is a function.
>
>> +/**
>> + * msi
Hi,
On 20/07/2016 10:12, Thomas Gleixner wrote:
> On Tue, 19 Jul 2016, Eric Auger wrote:
>> +bool msi_doorbell_safe(void)
>> +{
>> +struct irqchip_doorbell *db;
>> +bool irq_remapping = true;
>> +
>> +mutex_lock(&irqchip_doorbell_mutex);
>> +list_for_each_entry(db, &irqchip_doorbel
Hi Thomas,
On 22/07/2016 14:44, Thomas Gleixner wrote:
> On Thu, 21 Jul 2016, Auger Eric wrote:
>> On 20/07/2016 10:12, Thomas Gleixner wrote:
>>> On Tue, 19 Jul 2016, Eric Auger wrote:
>>>> +bool msi_doorbell_safe(void)
>>>> +{
>>>> + s
Hi,
On 12/09/2016 20:32, Tomasz Nowicki wrote:
> The series builds the PCI/MSI domain stack based on initial IORT driver
> which is added in first place. As a reference please see IORT spec:
> http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf
>
> Tested on
Hi Dennis,
On 20/07/2016 13:43, Dennis Chen wrote:
> Hi Eric,
> Some small questions/comments below:
>
> On Tue, Jul 19, 2016 at 12:55:07PM +, Eric Auger wrote:
>> iommu_get/put_msi_cookie allocates/frees the resource used to store
>> and ref count the MSI doorbell mappings. iommu_msi_set_ape
Hi Robin,
On 26/08/2016 03:17, Robin Murphy wrote:
> Hi Eric,
>
> On Fri, 26 Aug 2016 00:25:34 +0200
> Auger Eric wrote:
>
>> Hi Robin,
>>
>> On 23/08/2016 21:05, Robin Murphy wrote:
>>> When an MSI doorbell is located downstream of an IOMMU, att
Hi Baoyou,
On 01/09/2016 13:15, Baoyou Xie wrote:
> We get a few warnings when building kernel with W=1:
> drivers/vfio/platform/vfio_platform_common.c:76:5: warning: no previous
> prototype for 'vfio_platform_acpi_call_reset' [-Wmissing-prototypes]
> drivers/vfio/platform/vfio_platform_common.c:
Hi Diana,
On 05/08/2016 16:46, Diana Madalina Craciun wrote:
> Hi Eric,
>
> I have tested these patches in a VFIO PCI scenario (using the ITS
> emulation) on a NXP LS2080 board. It worked fine with one e1000 card
> assigned to the guest. However, when I tried to assign two cards to the
> guest I
Hi,
On 02/08/2016 19:23, Eric Auger wrote:
> This new flags member is meant to store additional information about
> the msi descriptor, starting with allocation status information.
>
> MSI_DESC_FLAG_ALLOCATED bit tells the associated base IRQ is allocated.
> This information is currently used at
Hi Robin,
On 23/08/2016 21:05, Robin Murphy wrote:
> When an MSI doorbell is located downstream of an IOMMU, attaching
> devices to a DMA ops domain and switching on translation leads to a rude
> shock when their attempt to write to the physical address returned by
> the irqchip driver faults (or
Hi Will,
On 17/08/2017 18:34, Will Deacon wrote:
> On Fri, Aug 11, 2017 at 03:45:28PM +0200, Eric Auger wrote:
>> When running a virtual SMMU on a guest we sometimes need to trap
>> all changes to the translation structures. This is especially useful
>> to integrate with VFIO. This patch adds a ne
Hi Michael,
On 18/08/2017 04:54, Michael S. Tsirkin wrote:
> On Thu, Aug 17, 2017 at 07:47:04PM +0200, Auger Eric wrote:
>> I will see with Peter and other potential users in the community whether
>> it is worth to pursue the efforts on upstreaming the QEMU vSMMUv3
>> device,
Hi Christoffer,
On 13/10/2017 19:56, Christoffer Dall wrote:
> On Fri, Oct 13, 2017 at 04:22:25PM +0200, Auger Eric wrote:
>> Hi,
>>
>> On 13/10/2017 15:16, Christoffer Dall wrote:
>>> On Wed, Sep 27, 2017 at 03:28:33PM +0200, Eric Auger wrote:
>>>> At
Hi Christoffer,
On 13/10/2017 19:54, Christoffer Dall wrote:
> On Fri, Oct 13, 2017 at 01:54:34PM +0200, Auger Eric wrote:
>> Hi Christoffer,
>> On 13/10/2017 13:44, Christoffer Dall wrote:
>>> On Fri, Oct 06, 2017 at 05:29:02PM +0200, Auger Eric wrote:
>>>&g
Hi Christoffer,
On 16/10/2017 11:26, Christoffer Dall wrote:
> Hi Eric,
>
> On Mon, Sep 25, 2017 at 03:34:36PM +0200, Eric Auger wrote:
>> When the GITS_BASER.Valid gets cleared, the data structures in
>> guest RAM are not provisionned anymore. The device, collection
>> and LPI lists stored in the
Hi Marc,
On 25/05/2017 20:05, Marc Zyngier wrote:
> Hi Eric,
>
> On Wed, May 24 2017 at 10:13:14 pm BST, Eric Auger
> wrote:
>> For direct EOI modality we will need to differentiate a userspace
>> masking from the IRQ handler auto-masking.
>>
>> Signed-off-by: Eric Auger
>> ---
>> drivers/vfi
Hi Marc,
On 25/05/2017 21:14, Marc Zyngier wrote:
> On Wed, May 24 2017 at 10:13:21 pm BST, Eric Auger
> wrote:
>> Virtual interrupts directly mapped to physical interrupts require
>> some special care. Their pending and active state must be observed
>> at distributor level and not in the list r
Hi,
On 25/05/2017 21:19, Marc Zyngier wrote:
> On Wed, May 24 2017 at 10:13:22 pm BST, Eric Auger
> wrote:
>> Implements kvm_vgic_[set|unset]_forwarding.
>>
>> Handle low-level VGIC programming and consistent irqchip
>> programming.
>>
>> Signed-off-by: Eric Auger
>>
>> ---
>> ---
>> include/k
Hi Marc,
On 30/05/2017 15:17, Marc Zyngier wrote:
> On 30/05/17 13:54, Auger Eric wrote:
>> Hi,
>>
>> On 25/05/2017 21:19, Marc Zyngier wrote:
>>> On Wed, May 24 2017 at 10:13:22 pm BST, Eric Auger
>>> wrote:
>>>> Implements kvm_vgic_[set
Hi Christoffer,
On 18/10/2017 00:10, Christoffer Dall wrote:
> On Tue, Oct 17, 2017 at 09:10:04AM +0200, Eric Auger wrote:
>> At the moment vgic_its_process_commands() does not
>> check the CBASER is valid before processing any command.
>> Let's fix that.
>>
>> Also rename cbaser local variable in
Hi Christoffer,
On 30/10/2017 07:20, Christoffer Dall wrote:
> Hi Eric,
>
> On Thu, Oct 26, 2017 at 05:23:02PM +0200, Eric Auger wrote:
>> This series fixes various bugs observed when saving/restoring the
>> ITS state before the guest writes the ITS registers (on first boot or
>> after reset/rebo
Hi Shameer,
On 12/01/18 17:45, Shameer Kolothum wrote:
> This allows the user-space to retrieve the supported IOVA
> range(s), excluding any reserved regions. The implementation
> is based on capability chains, added to VFIO_IOMMU_GET_INFO ioctl.
>
> Signed-off-by: Shameer Kolothum
> ---
> dri
Hi Shameer,
On 23/01/18 11:04, Shameerali Kolothum Thodi wrote:
> Hi Eric,
>
>> -Original Message-----
>> From: Auger Eric [mailto:eric.au...@redhat.com]
>> Sent: Tuesday, January 23, 2018 8:25 AM
>> To: Alex Williamson ; Shameerali Kolothum
>> Thodi
Hi Shameer,
On 23/01/18 13:16, Shameerali Kolothum Thodi wrote:
> Hi Eric,
>
>> -Original Message-----
>> From: Auger Eric [mailto:eric.au...@redhat.com]
>> Sent: Tuesday, January 23, 2018 8:32 AM
>> To: Alex Williamson ; Shameerali Kolothum
>> Thodi
Hi,
On 24/01/18 17:10, Sinan Kaya wrote:
> On 1/24/2018 11:09 AM, Hans de Goede wrote:
> There must be a middle ground somewhere.
One thing which comes to mind is to simply not allow building i2c as a
module
when ACPI is selected, something like this should work I think:
>
Hi Christoffer
On 11/01/18 19:55, Christoffer Dall wrote:
> On Mon, Jan 08, 2018 at 10:52:54AM +0100, Eric Auger wrote:
>> Commit 3d1ad640f8c94 ("KVM: arm/arm64: Fix GICv4 ITS initialization
>> issues") moved the vgic_supports_direct_msis() check in vgic_v4_init().
>> However when vgic_v4_init is
Hi Shameer,
On 18/01/18 01:04, Alex Williamson wrote:
> On Fri, 12 Jan 2018 16:45:27 +
> Shameer Kolothum wrote:
>
>> This introduces an iova list that is valid for dma mappings. Make
>> sure the new iommu aperture window is valid and doesn't conflict
>> with any existing dma mappings during
Hi Shameer,
On 18/01/18 01:04, Alex Williamson wrote:
> On Fri, 12 Jan 2018 16:45:28 +
> Shameer Kolothum wrote:
>
>> This retrieves the reserved regions associated with dev group and
>> checks for conflicts with any existing dma mappings. Also update
>> the iova list excluding the reserved
Hi Shameer,
On 12/01/18 17:45, Shameer Kolothum wrote:
> This checks and rejects any dma map request outside valid iova
> range.
>
> Signed-off-by: Shameer Kolothum
> ---
> drivers/vfio/vfio_iommu_type1.c | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/
Hi Peter,
On 05/03/18 17:31, Peter Maydell wrote:
> On 2 March 2018 at 12:26, Auger Eric wrote:
>> Hi Marc,
>> On 02/03/18 12:11, Marc Zyngier wrote:
>>> On Fri, 02 Mar 2018 10:44:48 +,
>>> Auger Eric wrote:
>>>> I understand the get/set is called
Hi Alex,
On 23/03/18 20:59, Alex Williamson wrote:
> On Fri, 23 Mar 2018 18:59:29 +0100
> Alvise Rigo wrote:
>
>> Update the sub-maintainer entry as Baptiste has moved.
>>
>> Add me and Eric Auger as sub-maintainers of the VFIO plaform driver.
>>
>> Signed-off-by: Alvise Rigo
>> ---
>> MAINTAI
Hi Jason,
On 11/04/18 15:44, Jason Wang wrote:
>
>
> On 2018年04月11日 21:30, Eric Auger wrote:
>> vhost_copy_to_user is used to copy vring used elements to userspace.
>> We should use VHOST_ADDR_USED instead of VHOST_ADDR_DESC.
>>
>> Fixes: f88949138058 ("vhost: introduce O(1) vq metadata cache")
Hi Geert, Philipp,
On 11/04/18 11:15, Geert Uytterhoeven wrote:
> Vfio-platform requires reset support, provided either by ACPI, or, on DT
> platforms, by a device-specific reset driver matching against the
> device's compatible value.
>
> On many SoCs, devices are connected to an SoC-internal re
Hi Geert,
On 12/04/18 13:32, Geert Uytterhoeven wrote:
> Hi Eric,
>
> On Thu, Apr 12, 2018 at 12:31 PM, Auger Eric wrote:
>> On 11/04/18 11:15, Geert Uytterhoeven wrote:
>>> Vfio-platform requires reset support, provided either by ACPI, or, on DT
>>> platforms,
Hi Christoffer,
> Hi Eric,
>
> On Tue, Mar 27, 2018 at 04:04:06PM +0200, Eric Auger wrote:
>> We introduce a new KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION attribute in
>> KVM_DEV_ARM_VGIC_GRP_ADDR group. It allows userspace to provide the
>> base address and size of a redistributor region
>>
>> Compare
Hi Geert, Philipp,
On 12/04/18 18:02, Geert Uytterhoeven wrote:
> Hi Philipp,
>
> On Thu, Apr 12, 2018 at 4:10 PM, Philipp Zabel wrote:
>> On Thu, 2018-04-12 at 15:12 +0200, Geert Uytterhoeven wrote:
>>> On Thu, Apr 12, 2018 at 2:36 PM, Sinan Kaya wrote:
>>>&
Hi Geert,On 10/04/18 16:54, Geert Uytterhoeven wrote:
> - Capitalize the first word of error messages,
> - Unwrap statements that fit on a single line,
> - Use "VFIO" instead of "vfio" as the error message prefix.
>
> Signed-off-by: Geert Uytterhoeven
> Reviewed-by: Eric Auger
Acked-by: Er
Hi Geert,
On 11/04/18 11:15, Geert Uytterhoeven wrote:
> If the IOMMU group setup fails, the reset module is not released.
>
> Fixes: b5add544d677d363 ("vfio, platform: make reset driver a requirement by
> default")
> Signed-off-by: Geert Uytterhoeven
> Reviewed-by: Eric Auger
> Reviewed-by: Si
Hi Geert,
On 11/04/18 11:24, Geert Uytterhoeven wrote:
> If a device is part of a PM Domain (e.g. power and/or clock domain), its
> power state is managed using Runtime PM. Without Runtime PM, the device
> may not be powered up, causing subtle failures, crashes, or system
> lock-ups when the devi
Hi Geert,
On 13/04/18 11:19, Geert Uytterhoeven wrote:
> Hi Eric,
>
> On Fri, Apr 13, 2018 at 11:14 AM, Auger Eric wrote:
>> On 11/04/18 11:24, Geert Uytterhoeven wrote:
>>> If a device is part of a PM Domain (e.g. power and/or clock domain), its
>>> power
Hi Philipp,
On 13/04/18 11:22, Philipp Zabel wrote:
[..]
> That also means it is impossible to use just one of the devices that
> share a reset line for vfio individually, while the other ones are still
> in use by the host. Currently the reset line is a shared resource
> similar to the iommu for
Hi Marc,
On 19/03/18 14:46, Marc Zyngier wrote:
> On 19/03/18 09:20, Eric Auger wrote:
>> in case kvm_vgic_map_resources() fails, typically if the vgic
>> distributor is not defined, __kvm_vgic_destroy will be called
>> several times. Indeed kvm_vgic_map_resources() is called on
>> first vcpu run.
Hi Marc,
On 19/03/18 15:15, Marc Zyngier wrote:
> On 19/03/18 09:20, Eric Auger wrote:
>> We introduce a new KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION attribute in
>> KVM_DEV_ARM_VGIC_GRP_ADDR group. It allows userspace to provide the
>> base address and size of a redistributor region
>>
>> Compared to
Hi Marc,
On 19/03/18 16:57, Marc Zyngier wrote:
> On 19/03/18 09:20, Eric Auger wrote:
>> To prepare for multiple RDIST regions, let's record the RDIST
>> Last bit field when registering the IO device.
>>
>> As a reminder the Last bit indicates whether the redistributor
>> is the highest one in a
Hi,
On 08/03/18 08:01, Shunyong Yang wrote:
> When resampling irqfds is enabled, level interrupt should be
> de-asserted when resampling happens. On page 4-47 of GIC v3
> specification IHI0069D, it said,
> "When the PE acknowledges an SGI, a PPI, or an SPI at the CPU
> interface, the IRI changes t
Hi Shunyong,
On 08/03/18 10:31, Yang, Shunyong wrote:
> Hi, Eric,
>
> First, please let me change Christoffer's email to cd...@kernel.org. I
> add more information about my test below, please check.
>
> On Thu, 2018-03-08 at 09:57 +0100, Auger Eric wrote:
>> Hi,
>
Hi Marc,
On 08/03/18 12:54, Marc Zyngier wrote:
> On 08/03/18 09:49, Marc Zyngier wrote:
>> [updated Christoffer's email address]
>>
>> Hi Shunyong,
>>
>> On 08/03/18 07:01, Shunyong Yang wrote:
>>> When resampling irqfds is enabled, level interrupt should be
>>> de-asserted when resampling happen
Hi Marc, Christoffer,
On 08/03/18 18:28, Marc Zyngier wrote:
> On Thu, 08 Mar 2018 16:19:00 +,
> Christoffer Dall wrote:
>>
>> On Thu, Mar 08, 2018 at 11:54:27AM +, Marc Zyngier wrote:
>>> On 08/03/18 09:49, Marc Zyngier wrote:
[updated Christoffer's email address]
Hi Shunyo
Hi Marc,
On 09/03/18 10:40, Marc Zyngier wrote:
> On 09/03/18 03:14, Yang, Shunyong wrote:
>
> [trimming things a bit]
>
static bool lr_signals_eoi_mi(u32 lr_val)
{
- return !(lr_val & GICH_LR_STATE) && (lr_val &
GICH_LR_EOI) &&
- !
Hi Marc,
On 09/03/18 10:12, Marc Zyngier wrote:
> On 08/03/18 18:12, Auger Eric wrote:
>> Hi Marc, Christoffer,
>>
>> On 08/03/18 18:28, Marc Zyngier wrote:
>>> On Thu, 08 Mar 2018 16:19:00 +,
>>> Christoffer Dall wrote:
>>>>
>>>&g
Hi Alex,
On 28/02/18 21:14, Alex Williamson wrote:
> This creates a common helper that we'll use for ioeventfd setup.
>
> Signed-off-by: Alex Williamson
Reviewed-by: Eric Auger
Thanks
Eric
> ---
> drivers/vfio/pci/vfio_pci_rdwr.c | 39
> ++
> 1 file cha
Hi,
On 08/02/18 02:22, Alexey Kardashevskiy wrote:
> On 08/02/18 01:12, Alex Williamson wrote:
>> On Wed, 7 Feb 2018 15:48:26 +1100
>> Alexey Kardashevskiy wrote:
>>
>>> On 07/02/18 15:25, Alex Williamson wrote:
On Wed, 7 Feb 2018 15:09:22 +1100
Alexey Kardashevskiy wrote:
> On 0
Hi Alex,
On 28/02/18 21:15, Alex Williamson wrote:
> The ioeventfd here is actually irqfd handling of an ioeventfd such as
> supported in KVM. A user is able to pre-program a device write to
> occur when the eventfd triggers. This is yet another instance of
> eventfd-irqfd triggering between KVM
Hi Geert,
On 11/13/18 2:15 PM, Geert Uytterhoeven wrote:
> Vfio-platform requires dedicated reset support, provided either by ACPI,
> or, on DT platforms, by a device-specific reset driver matching against
> the device's compatible value.
>
> On many SoCs, devices are connected to an SoC-internal
Hi Alex,
On 11/9/18 11:09 PM, Alex Williamson wrote:
> In commit 61d792562b53 ("vfio-pci: Use mutex around open, release, and
> remove") a mutex was added to freeze the refcnt for a device so that
> we can handle errors and perform bus resets on final close. However,
> bus resets can be rather sl
Hi Alex,
On 11/13/18 5:34 PM, Alex Williamson wrote:
> On Tue, 13 Nov 2018 15:42:49 +0100
> Auger Eric wrote:
>
>> Hi Alex,
>>
>> On 11/9/18 11:09 PM, Alex Williamson wrote:
>>> In commit 61d792562b53 ("vfio-pci: Use mutex around open, release, and
>
Hi Jacob,
On 9/21/18 12:06 AM, Jacob Pan wrote:
> On Tue, 18 Sep 2018 16:24:51 +0200
> Eric Auger wrote:
>
>> From: Jacob Pan
>>
>> Device faults detected by IOMMU can be reported outside IOMMU
>> subsystem for further processing. This patch intends to provide
>> a generic device fault data suc
Hi Jacob,
On 12/15/18 1:30 AM, Jacob Pan wrote:
> On Wed, 12 Dec 2018 09:21:43 +0100
> Auger Eric wrote:
>
>> Hi Jacob,
>>
>> On 9/21/18 12:06 AM, Jacob Pan wrote:
>>> On Tue, 18 Sep 2018 16:24:51 +0200
>>> Eric Auger wrote:
>>>
>
Hi Shameer,
On 12/3/20 7:42 PM, Shameerali Kolothum Thodi wrote:
> Hi Eric,
>
>> -Original Message-
>> From: kvmarm-boun...@lists.cs.columbia.edu
>> [mailto:kvmarm-boun...@lists.cs.columbia.edu] On Behalf Of Auger Eric
>> Sent: 01 December 2020 13:59
>>
Hi Kunkun,
On 4/1/21 2:37 PM, Kunkun Jiang wrote:
> Hi Eric,
>
> On 2021/2/24 4:56, Eric Auger wrote:
>> With nested stage support, soon we will need to invalidate
>> S1 contexts and ranges tagged with an unmanaged asid, this
>> latter being managed by the guest. So let's introduce 2 helpers
>> t
Hi Kunkun,
On 4/9/21 6:48 AM, Kunkun Jiang wrote:
> Hi Eric,
>
> On 2021/4/8 20:30, Auger Eric wrote:
>> Hi Kunkun,
>>
>> On 4/1/21 2:37 PM, Kunkun Jiang wrote:
>>> Hi Eric,
>>>
>>> On 2021/2/24 4:56, Eric Auger wrote:
>>>>
Hi,
On 05/22/2018 02:10 PM, kbuild test robot wrote:
> Hi Eric,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on kvmarm/next]
> [also build test WARNING on v4.17-rc6 next-20180517]
> [if your patch is applied to the wrong git tree, please drop us a note
Hi Shameer,
On 27/02/18 10:57, Shameerali Kolothum Thodi wrote:
>
>
>> -Original Message-----
>> From: Auger Eric [mailto:eric.au...@redhat.com]
>> Sent: Tuesday, February 27, 2018 8:27 AM
>> To: Alex Williamson
>> Cc: Shameerali Kolothum Tho
Hi Shameer,
On 28/02/18 10:25, Shameerali Kolothum Thodi wrote:
>
>
>> -Original Message-----
>> From: Auger Eric [mailto:eric.au...@redhat.com]
>> Sent: Wednesday, February 28, 2018 9:02 AM
>> To: Shameerali Kolothum Thodi ;
>> Alex Williamson
Hi Shameer,
On 28/02/18 14:39, Shameerali Kolothum Thodi wrote:
> Hi Eric,
>
>> -Original Message-----
>> From: Auger Eric [mailto:eric.au...@redhat.com]
>> Sent: Wednesday, February 28, 2018 11:53 AM
>> To: Shameerali Kolothum Thodi ;
>> Alex Williamson
Hi Marc,
On 27/03/18 19:10, Marc Zyngier wrote:
> On 27/03/18 15:04, Eric Auger wrote:
>> in case kvm_vgic_map_resources() fails, typically if the vgic
>> distributor is not defined, __kvm_vgic_destroy will be called
>> several times. Indeed kvm_vgic_map_resources() is called on
>> first vcpu run.
Hi Alex,
On 26/03/18 21:42, Alex Williamson wrote:
> Baptiste has changed positions and has not been active with
> vfio-platform, replace with the current, de-facto sub-maintainer
> Eric Auger. Also add Alvise Rigo as a designated reviewer.
>
> Cc: Eric Auger
> Cc: Alvise Rigo
> Signed-off-by:
Hi Peter,
On 28/03/18 20:55, Peter Maydell wrote:
> On 27 March 2018 at 15:04, Eric Auger wrote:
>> Now all the internals are ready to handle multiple redistributor
>> regions, let's allow the userspace to register them.
>>
>> Signed-off-by: Eric Auger
>> ---
>> virt/kvm/arm/vgic/vgic-kvm-devic
Hi Christoffer,
On 04/26/2018 12:06 PM, Christoffer Dall wrote:
> On Thu, Apr 26, 2018 at 10:29:35AM +0200, Auger Eric wrote:
>> Hi Christoffer,
>> On 04/24/2018 11:07 PM, Christoffer Dall wrote:
>>> On Fri, Apr 13, 2018 at 10:20:53AM +0200, Eric Auger wrote:
>>&
Hi,
On 04/27/2018 04:06 PM, Eric Auger wrote:
> At the moment the KVM VGICv3 only supports a single redistributor
> region (whose base address is set through the GICv3 kvm device
> KVM_DEV_ARM_VGIC_GRP_ADDR/KVM_VGIC_V3_ADDR_TYPE_REDIST). There,
> all the redistributors are laid out contiguously. T
Hi Christoffer,
On 04/24/2018 11:06 PM, Christoffer Dall wrote:
> On Fri, Apr 13, 2018 at 10:20:57AM +0200, Eric Auger wrote:
>> Now all the internals are ready to handle multiple redistributor
>> regions, let's allow the userspace to register them.
>>
>> Signed-off-by: Eric Auger
>>
>> ---
>>
>>
Hi Geert,
On 05/18/2018 12:55 PM, Geert Uytterhoeven wrote:
> If a device is part of a PM Domain (e.g. power and/or clock domain), its
> power state is managed using Runtime PM. Without Runtime PM, the device
> may not be powered up or clocked, causing subtle failures, crashes, or
> system lock-u
Hi Dan,
On 05/28/2018 09:47 AM, Dan Carpenter wrote:
> This cast is confusing... The "start" variable is an unsigned int. We
> absolutely do not want to cast it to a negative int so why is the cast
> there? It turns out, when you look at the context, it's a no-op and we
> can just remove it.
>
Hi Geert,
On 05/28/2018 05:26 PM, Geert Uytterhoeven wrote:
> If a device is part of a PM Domain (e.g. power and/or clock domain), its
> power state is managed using Runtime PM. Without Runtime PM, the device
> may not be powered up or clocked, causing subtle failures, crashes, or
> system lock-u
Hi Christoffer, Peter,
On 04/24/2018 06:50 PM, Peter Maydell wrote:
> On 24 April 2018 at 17:46, Christoffer Dall wrote:
>> On Fri, Apr 13, 2018 at 10:20:48AM +0200, Eric Auger wrote:
>>> --- a/Documentation/virtual/kvm/devices/arm-vgic-v3.txt
>>> +++ b/Documentation/virtual/kvm/devices/arm-vgic-
Hi Christoffer,
On 04/24/2018 06:47 PM, Christoffer Dall wrote:
> On Fri, Apr 13, 2018 at 10:20:52AM +0200, Eric Auger wrote:
>> We introduce a new helper that creates and inserts a new redistributor
>> region into the rdist region list. This helper both handles the case
>> where the redistributor
Hi Christoffer,
On 04/24/2018 11:07 PM, Christoffer Dall wrote:
> On Fri, Apr 13, 2018 at 10:20:50AM +0200, Eric Auger wrote:
>> We introduce vgic_v3_rdist_free_slot to help identifying
>> where we can place a new 2x64KB redistributor.
>>
>> Signed-off-by: Eric Auger
>> ---
>> virt/kvm/arm/vgic/v
Hi Christoffer,
On 04/24/2018 11:07 PM, Christoffer Dall wrote:
> On Fri, Apr 13, 2018 at 10:20:53AM +0200, Eric Auger wrote:
>> We introduce a new helper to check there is no overlap between
>> dist region (if set) and registered rdist regions. This both
>> handles the case of legacy single rdist
Hi Christoffer,
On 04/24/2018 11:07 PM, Christoffer Dall wrote:
> On Fri, Apr 13, 2018 at 10:20:54AM +0200, Eric Auger wrote:
>> As we are going to register several redist regions,
>> vgic_register_all_redist_iodevs() may be called several times. We need
>> to register a redist_iodev for a given v
On 04/24/2018 11:08 PM, Christoffer Dall wrote:
> On Fri, Apr 13, 2018 at 10:20:55AM +0200, Eric Auger wrote:
>> On vcpu first run, we eventually know the actual number of vcpus.
>> This is a synchronization point to check all redistributors regions
>> were assigned.
>
> Isn't it the other way a
Hi Jacob
On 4/24/19 1:31 AM, Jacob Pan wrote:
> Move domainer helper to header to be used by SVA code.
s/domainer/domain
>
> Signed-off-by: Jacob Pan
Reviewed-by: Eric Auger
Eric
> ---
> drivers/iommu/intel-iommu.c | 6 --
> include/linux/intel-iommu.h | 6 ++
>
Hi Jacob,
On 4/24/19 1:31 AM, Jacob Pan wrote:
> From: Lu Baolu
>
> If Intel IOMMU runs in caching mode, a.k.a. virtual IOMMU, the
> IOMMU driver should rely on the emulation software to allocate
> and free PASID IDs.
Do we make the decision depending on the CM or depending on the VCCAP_REG?
VC
Hi Jacob,
On 4/24/19 1:31 AM, Jacob Pan wrote:
> Make use of generic IOASID code to manage PASID allocation,
> free, and lookup.
>
> Signed-off-by: Jacob Pan
> ---
> drivers/iommu/Kconfig | 1 +
> drivers/iommu/intel-iommu.c | 9 -
> drivers/iommu/intel-pasid.c | 36
Hi Alex,
On 1/11/19 10:30 PM, Alex Williamson wrote:
> On Tue, 8 Jan 2019 11:26:14 +0100
> Eric Auger wrote:
>
>> From: "Liu, Yi L"
>>
>> In any virtualization use case, when the first translation stage
>> is "owned" by the guest OS, the host IOMMU driver has no knowledge
>> of caching structu
Hi Alex,
On 1/11/19 11:44 PM, Alex Williamson wrote:
> On Tue, 8 Jan 2019 11:26:15 +0100
> Eric Auger wrote:
>
>> On ARM, MSI are translated by the SMMU. An IOVA is allocated
>> for each MSI doorbell. If both the host and the guest are exposed
>> with SMMUs, we end up with 2 different IOVAs allo
Hi Alex,
On 1/11/19 11:44 PM, Alex Williamson wrote:
> On Tue, 8 Jan 2019 11:26:15 +0100
> Eric Auger wrote:
>
>> On ARM, MSI are translated by the SMMU. An IOVA is allocated
>> for each MSI doorbell. If both the host and the guest are exposed
>> with SMMUs, we end up with 2 different IOVAs all
Hi Bjorn, Alex,
On 3/30/19 3:41 PM, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> Use dev_printk() when possible to make messages consistent with other
> device-related messages.
>
> Signed-off-by: Bjorn Helgaas
For the vfio-platform part:
Acked-by: Eric Auger
For the rest:
Reviewed-by: Eri
Hi Alex,
On 4/2/19 6:15 PM, Alex Williamson wrote:
> Memory backed DMA mappings are accounted against a user's locked
> memory limit, including multiple mappings of the same memory. This
> accounting bounds the number of such mappings that a user can create.
> However, DMA mappings that are not b
Hi Vincent,
On 2/25/19 3:22 PM, Vincent Stehlé wrote:
> Hi Eric,
>
> On Mon, Feb 18, 2019 at 02:55:00PM +0100, Eric Auger wrote:
>> This patch registers a fault handler which records faults in
>> a circular buffer and then signals an eventfd. This buffer is
>> exposed within the fault region.
>>
Hi Keqian,
On 2/2/21 8:14 AM, Keqian Zhu wrote:
> Hi Eric,
>
> On 2020/11/18 19:21, Eric Auger wrote:
>> When nested stage translation is setup, both s1_cfg and
>> s2_cfg are set.
>>
>> We introduce a new smmu domain abort field that will be set
>> upon guest stage1 configuration passing.
>>
>> a
Hi Keqian,
On 2/2/21 9:03 AM, Keqian Zhu wrote:
> Hi Eric,
>
> On 2020/11/18 19:21, Eric Auger wrote:
>> On attach_pasid_table() we program STE S1 related info set
>> by the guest into the actual physical STEs. At minimum
>> we need to program the context descriptor GPA and compute
>> whether the
Hi Keqian,
On 2/1/21 12:52 PM, Keqian Zhu wrote:
> Hi Eric,
>
> On 2020/11/18 19:21, Eric Auger wrote:
>> On ARM, MSI are translated by the SMMU. An IOVA is allocated
>> for each MSI doorbell. If both the host and the guest are exposed
>> with SMMUs, we end up with 2 different IOVAs allocated by
Hi Vivek,
On 2/12/21 11:58 AM, Vivek Gautam wrote:
> Add a vendor specific structure for domain nesting info for
> arm smmu-v3, and necessary info fields required to populate
> stage1 page tables.
>
> Signed-off-by: Vivek Gautam
> ---
> include/uapi/linux/iommu.h | 31 +--
Hi Vivek,
On 2/12/21 11:58 AM, Vivek Gautam wrote:
> Update nested domain information required for stage1 page table.
s/reuqired/required in the commit title
>
> Signed-off-by: Vivek Gautam
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 16 ++--
> 1 file changed, 14 insertio
Hi Vivek,
On 2/12/21 11:58 AM, Vivek Gautam wrote:
> Update nested domain information required for stage1 page table.
>
> Signed-off-by: Vivek Gautam
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/d
Hi Shenming,
On 2/23/21 1:45 PM, Shenming Lu wrote:
>> +static int vfio_pci_dma_fault_init(struct vfio_pci_device *vdev)
>> +{
>> +struct vfio_region_dma_fault *header;
>> +struct iommu_domain *domain;
>> +size_t size;
>> +bool nested;
>> +int ret;
>> +
>> +domain = iommu_g
Hi Keqian,
On 2/18/21 9:43 AM, Keqian Zhu wrote:
> Hi Eric,
>
> On 2021/2/12 16:55, Auger Eric wrote:
>> Hi Keqian,
>>
>> On 2/1/21 12:52 PM, Keqian Zhu wrote:
>>> Hi Eric,
>>>
>>> On 2020/11/18 19:21, Eric Auger wrote:
>>>> On
1 - 100 of 609 matches
Mail list logo
