Hi Peter,
On 08/03/18 19:37, Peter Maydell wrote:
> On 17 February 2018 at 18:46, Eric Auger wrote:
>> Now we have relevant helpers for queue and irq
>> management, let's implement MMIO write operations.
>>
>> Signed-off-by: Eric Auger
>>
>> ---
>>
>> v7 -> v8:
>> - precise in the commit message
Hi Peter,
On 08/03/18 19:28, Peter Maydell wrote:
> On 17 February 2018 at 18:46, Eric Auger wrote:
>> We introduce helpers to read/write into the command and event
>> circular queues.
>>
>> smmuv3_write_eventq and smmuv3_cmq_consume will become static
>> in subsequent patches.
>>
>> Invalidation
Hi Peter,
On 08/03/18 19:39, Peter Maydell wrote:
> On 17 February 2018 at 18:46, Eric Auger wrote:
>> Let's introduce a helper function aiming at recording an
>> event in the event queue.
>>
>> Signed-off-by: Eric Auger
>>
>> ---
>>
>> v8 -> v9:
>> - add SMMU_EVENT_STRING
>>
>> v7 -> v8:
>> - u
Hi Peter,
On 08/03/18 20:06, Peter Maydell wrote:
> On 17 February 2018 at 18:46, Eric Auger wrote:
>> At the moment, the SMMUv3 does not support notification on
>> TLB invalidation. So let's abort as soon as such notifier gets
>> enabled.
>>
>> Signed-off-by: Eric Auger
>> ---
>> hw/arm/smmuv3.
Hi Peter,
On 12/03/18 12:10, Peter Maydell wrote:
> On 12 March 2018 at 10:53, Eric Auger wrote:
>> Hi Peter,
>>
>> On 09/03/18 18:59, Peter Maydell wrote:
>>> On 9 March 2018 at 17:53, Auger Eric wrote:
>>>> Hi Peter,
>>>> On 08/03/18 20:06
Hi Peter,
On 12/03/18 13:56, Peter Maydell wrote:
> On 17 February 2018 at 18:46, Eric Auger wrote:
>> The new machine type exposes a new "iommu" virt machine option.
>> The SMMUv3 IOMMU is instantiated using -machine virt,iommu=smmuv3.
>>
>> Signed-off-by: Eric Auger
>>
>> ---
>> v7 -> v8:
>> -
Hi Peter,
On 12/03/18 13:46, Peter Maydell wrote:
> On 17 February 2018 at 18:46, Eric Auger wrote:
>> From: Prem Mallappa
>>
>> Add code to instantiate an smmuv3 in virt machine. A new iommu
>> integer member is introduced in VirtMachineState to store the type
>> of the iommu in use.
>>
>> Sign
Hi Peter,
On 12/03/18 12:59, Peter Maydell wrote:
> On 17 February 2018 at 18:46, Eric Auger wrote:
>> In case the MSI is translated by an IOMMU we need to fixup the
>> MSI route with the translated address.
>>
>> Signed-off-by: Eric Auger
>>
>> ---
>>
>> v5 -> v6:
>> - use IOMMUMemoryRegionClass
Hi Peter,
On 12/03/18 13:58, Peter Maydell wrote:
> On 28 February 2018 at 08:44, Auger Eric wrote:
>> On 27/02/18 20:02, Peter Maydell wrote:
>>> On 17 February 2018 at 18:46, Eric Auger wrote:
>>>> This series implements the emulation code for ARM SMMUv3.
>
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 Alex,
On 28/02/18 21:45, Alex Williamson wrote:
> This is the QEMU counterpart to https://lkml.org/lkml/2018/2/28/1222
>
> As described in the third patch, we have a use case for taking
> advantage of existing KVM ioeventfd support for accelerating the
> MSI-ACK behavior of NVIDIA GPUs. This s
Hi Alex,
On 13/03/18 17:56, Alex Williamson wrote:
> [Cc +Eric]
>
> On Tue, 13 Mar 2018 15:53:19 +1100
> Alexey Kardashevskiy wrote:
>
>> On 7/3/18 1:17 pm, Alexey Kardashevskiy wrote:
>>> On 26/02/18 19:36, Alexey Kardashevskiy wrote:
On 19/02/18 13:46, Alexey Kardashevskiy wrote:
>>>
Hi Paolo,
On 13/03/18 14:37, Paolo Bonzini wrote:
> On 12/03/2018 16:16, Auger Eric wrote:
>>> It is still unclear to me if we need to register an IOMMUNotifier
>>> to handle any change in the MSI doorbell which would occur behind
>>> the scene and
Hi Alexey,
On 15/12/17 07:29, 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 Drew,
On 13/02/18 13:24, Andrew Jones wrote:
> On Mon, Feb 12, 2018 at 06:58:20PM +, Eric Auger wrote:
>> This patch builds the virtio-iommu node in the ACPI IORT table.
>> The dt node creation function fills the information used by
>> the IORT table generation function (base address, base i
Hi Geert,
On 09/02/18 16:17, Geert Uytterhoeven wrote:
> Allow the instantation of generic dynamic sysbus devices again, without
> the need to create a new device-specific vfio type.
>
> This is a partial revert of commit 6f2062b9758ebc64 ("hw/arm/virt:
> Allow only supported dynamic sysbus devic
Hi Geert,
On 09/02/18 16:17, Geert Uytterhoeven wrote:
> Allow the instantiation of a Renesas R-Car Gen3 GPIO controller device
> from the QEMU command line:
>
> -device vfio-platform,host=,manufacturer=renesas,model=rcar-gen3-gpio
> -device
> vfio-platform,sysfsdev=,manufacturer=renesas,model=r
Hi,
On 05/04/18 04:17, Alex Williamson wrote:
> On Thu, 5 Apr 2018 10:53:38 +1000
> Alexey Kardashevskiy wrote:
>
>> On 5/4/18 9:09 am, Alex Williamson wrote:
>>> On Wed, 4 Apr 2018 22:30:50 +0200
>>> Eric Auger wrote:
>>>
The 567b5b309abe ("vfio/pci: Relax DMA map errors for MMIO regi
Hi Peter,
On 13/04/18 15:27, Peter Maydell wrote:
> On 27 March 2018 at 15:15, Eric Auger wrote:
>> In the prospect to support multiple redistributor regions,
>> let's introduce a GICv3RDISTRegion struct datatype and a
>> statically sized array of those. For the time being, only
>> one redistribu
Hi Peter,
On 13/04/18 15:34, Peter Maydell wrote:
> On 27 March 2018 at 15:15, Eric Auger wrote:
>> This patch defines and implements the register_redist_region() API
>> for both arm_gicv3 and arm_gicv3_kvm. Virt machine now directly calls
>> the function to set the single redistributor region. Th
Hi Peter,
On 13/04/18 15:36, Peter Maydell wrote:
> On 27 March 2018 at 15:15, Eric Auger wrote:
>> This patch adds the GICState handle in the virtual machine state and
>> allows to create a GIC device tree node advertising multiple redistributor
>> regions.
>>
>> There is one range per distribut
Hi Drew,
On 13/04/18 15:47, Andrew Jones wrote:
> On Tue, Mar 27, 2018 at 04:15:21PM +0200, Eric Auger wrote:
>> In case multiple redistributor regions were registered,
>> let's add the corresponding GICR structures in the MADT
>> ACPI table.
>>
>> Signed-off-by: Eric Auger
>> ---
>> hw/arm/virt
Hi Peter,
On 13/04/18 15:46, Peter Maydell wrote:
> On 13 April 2018 at 14:44, Auger Eric wrote:
>> Actually this is an API provided to the machine and not the device
>> itself directly playing with the mapping.
>>
>> If not acceptable, I need to match the existing n
Hi Peter,
On 13/04/18 15:41, Peter Maydell wrote:
> On 27 March 2018 at 15:15, Eric Auger wrote:
>> With KVM acceleration and if KVM VGICV3 supports to set multiple
>> redistributor regions, we now allow up to 512 vcpus.
>>
>> Signed-off-by: Eric Auger
>> ---
>> hw/arm/virt.c | 17 +
Hi Peter,
On 13/04/18 16:06, Peter Maydell wrote:
> On 13 April 2018 at 15:01, Auger Eric wrote:
>> On 13/04/18 15:41, Peter Maydell wrote:
>>> I think it would be better to explicitly check "do we have
>>> support for split redistributors" rather than l
Hi Igor,
On 12/04/18 18:40, Igor Mammedov wrote:
> platform-bus were using machine_done notifier to get and map
> (assign irq/mmio resources) dynamically added sysbus devices
> after all '-device' options had been processed.
> That however creates non obvious dependencies on ordering of
> machine_
Hi Jintack,
On 21/02/18 05:03, Jintack Lim wrote:
> Hi,
>
> I'm using vhost with the virtual intel-iommu, and this page[1] shows
> the QEMU command line example.
>
> qemu-system-x86_64 -M q35,accel=kvm,kernel-irqchip=split -m 2G \
>-device intel-iommu,intremap=on,device-iotlb
Hi,
On 22/02/18 13:42, Igor Mammedov wrote:
> next patch will need it before it gets to piix4/lpc branches
> that initializes 'obj' now.
>
> Signed-off-by: Igor Mammedov
Reviewed-by: Eric Auger
Eric
> ---
> hw/i386/acpi-build.c | 4 +---
> 1 file chang
Hi Igor,
On 22/02/18 13:42, Igor Mammedov wrote:
> Drop duplicate in form of Acpi20GenericAddress and reuse
> AcpiGenericAddress.
>
> Signed-off-by: Igor Mammedov
Reviewed-by: Eric Auger
Eric
> ---
> include/hw/acpi/acpi-defs.h | 17 +++--
> 1 file changed
Hi,
On 22/02/18 13:42, Igor Mammedov wrote:
> SeaBIOS blob which is currently shipped with QEMU
> doesn't need acpi-dsdt.aml nor is able to use it
> and code that loaded it QEMU was removed by
as code that loaded it in QEMU was removed by?
> (commit 9fb7aaaf4c "pc: drop external DSDT loading")
> i
Hi,
On 22/02/18 13:42, Igor Mammedov wrote:
> it will help to add Generic Address Structure to ACPI tables
> without using packed C structures and avoid endianness
> issues as API doesn't need an explicit conversion.
>
> Signed-off-by: Igor Mammedov
Reviewed-by: Eric Auger
Thanks
Eric
> ---
>
Hi Igor,
On 22/02/18 13:42, Igor Mammedov wrote:
> move FADT data initialization out of fadt_setup() into dedicated
> init_fadt_data() that will set common for pc/q35 values in
> AcpiFadtData structure and acpi_get_pm_info() will complement
> it with pc/q35 specific values initialization.
acpi_get
Hi Igor,
On 22/02/18 13:42, Igor Mammedov wrote:
> build_append_foo() API doesn't need explicit endianness
> conversions which eliminates a source of errors and
> it makes build_fadt() look like declarative definition of
> FADT table in ACPI spec, which makes it easy to review.
> Also it allows ea
On 22/02/18 13:42, Igor Mammedov wrote:
> it will be extended and reused in follow up patch by ARM target
>
> Signed-off-by: Igor Mammedov
Reviewed-by: Eric Auger
Eric
> ---
> include/hw/acpi/aml-build.h | 3 ++
> hw/acpi/aml-bui
On 22/02/18 13:42, Igor Mammedov wrote:
> Extend generic build_fadt() to support rev5.1 FADT
> and reuse it for 'virt' board, it would allow to
> phase out usage of AcpiFadtDescriptorRev5_1 and
> later ACPI_FADT_COMMON_DEF.
>
> Signed-off-by: Igor Mammedov
Re
Hi Igor,
On 22/02/18 13:42, Igor Mammedov wrote:
> Extend generic build_fadt() to support rev5.1 FADT
> and reuse it for 'virt' board, it would allow to
> phase out usage of AcpiFadtDescriptorRev5_1 and
> later ACPI_FADT_COMMON_DEF.
Oups sorry sent the R-b to fast. Some small comments below.
>
> S
Hi Peter,
On 27/02/18 20:02, Peter Maydell wrote:
> On 17 February 2018 at 18:46, Eric Auger wrote:
>> This series implements the emulation code for ARM SMMUv3.
>>
>> SMMUv3 gets instantiated by adding ",iommu=smmuv3" to the virt
>> machine option.
>>
>> VHOST integration will be handled in a sep
Hi,
On 28/02/18 15:23, Igor Mammedov wrote:
> ACPI_PORT_SMI_CMD is alias for APM_CNT_IOPORT,
> so make it really one instead of duplicating its value.
>
> Signed-off-by: Igor Mammedov
Reviewed-by: Eric Auger
Eric
> ---
> include/hw/isa/apm.h | 3 +++
> hw/i386/acpi-bui
dataset.
>
> Signed-off-by: Igor Mammedov
> ---
> v2:
> changes requested by Auger Eric
suggested ;-)
> - s/pm1_/pm1a_/
> - s/c2_latency/plvl2_lat/
> - s/c3_latency/plvl3_lat/
> - cleanup ACPI_PORT_SMI_CMD TODO, move it to hw/isa/apm.h
> -
e check coverage,
> ARM was only slightly tested.
Tested-by: Eric Auger
on AArch64 with a rhel guest.
Thanks
Eric
>
> git tree for testing:
> https://github.com/imammedo/qemu.git fadt_refactoring_v2
>
> CC: "Michael S. Tsirkin"
> CC: Shannon Zhao
&g
Hi,
On 28/02/18 15:23, Igor Mammedov wrote:
> Extend generic build_fadt() to support rev5.1 FADT
> and reuse it for 'virt' board, it would allow to
> phase out usage of AcpiFadtDescriptorRev5_1 and
> later ACPI_FADT_COMMON_DEF.
>
> Signed-off-by: Igor Mammedov
> ---
> v2:
> - update comment to
piFadtDescriptorRev3/
> ACPI_FADT_COMMON_DEF which have no users left.
>
> Signed-off-by: Igor Mammedov
My only comment is you could have removed include/hw/acpi/acpi-defs.h
defs in a separate subsequent patch after updating the test stuff. Besides,
Reviewed-by: Eric Auger
Eric
> ---
>
On 01/03/18 10:21, Igor Mammedov wrote:
> On Thu, 1 Mar 2018 09:51:14 +0100
> Auger Eric wrote:
>
>> Hi,
>> On 28/02/18 15:23, Igor Mammedov wrote:
>>> Extend generic build_fadt() to support rev5.1 FADT
>>> and reuse it for 'virt'
Hi Alexey,
On 09/02/18 08:55, Alexey Kardashevskiy wrote:
> At the moment if vfio_memory_listener is registered in the system memory
> address space, it maps/unmaps every RAM memory region for DMA.
> It expects system page size aligned memory sections so vfio_dma_map
> would not fail and so far th
Hi Shannon,
On 19/03/18 15:32, Shannon Zhao wrote:
>
>
> On 2018/3/12 20:48, Peter Maydell wrote:
>> On 17 February 2018 at 18:46, Eric Auger wrote:
>>> From: Prem Mallappa
>>>
>>> This patch builds the smmuv3 node in the ACPI IORT table.
>>>
>>> The RID space of the root complex, which spans
Hi Shannon,
On 20/03/18 08:26, Shannon Zhao wrote:
> It forgot to increase clroffset during the loop. So it only clear the
> first 4 bytes.
Fixes 367b9f527becdd20ddf116e17a3c0c2bbc486920
("hw/intc/arm_gicv3_kvm: Implement get/put functions")
>
> Signed-off-by: Shannon Zhao
Reviewed-by: Eric Au
Hi Shannon,
On 20/03/18 08:26, Shannon Zhao wrote:
> While we skip the GIC_INTERNAL irqs, we don't change the register offset
> accordingly. This will overlap the GICR registers value and leave the
> last GIC_INTERNAL irq's registers out of update.
>
> Fix this by skipping the registers banked by
Hi Alexey,
On 22/03/18 08:45, Alexey Kardashevskiy wrote:
> On 22/3/18 2:29 am, Alex Williamson wrote:
>> On Mon, 19 Mar 2018 21:49:58 +0100
>> Auger Eric wrote:
>>
>>> Hi Alexey,
>>>
>>> On 09/02/18 08:55, Alexey Kardashevskiy wrote:
>>>
Hi,
I observe a regression on KVM accelerated qemu-system-aarch64:
Unexpected error in kvm_device_access() at
/home/augere/UPSTREAM/qemu/accel/kvm/kvm-all.c:2164:
2018-03-23T09:59:59.629439Z qemu-system-aarch64: KVM_GET_DEVICE_ATTR
failed: Group 6 attr 0xc664: Device or resource busy
Hi,
On 23/03/18 11:26, Peter Maydell wrote:
> On 23 March 2018 at 10:24, Auger Eric wrote:
>> Hi,
>>
>> I observe a regression on KVM accelerated qemu-system-aarch64:
>>
>> Unexpected error in kvm_device_access() at
>> /home/augere/UPSTREAM/qemu/accel/
Hi,
On 23/03/18 13:11, Peter Maydell wrote:
> On 23 March 2018 at 12:01, Auger Eric wrote:
>> Hi,
>>
>> On 23/03/18 11:26, Peter Maydell wrote:
>>> On 23 March 2018 at 10:24, Auger Eric wrote:
>>>> Hi,
>>>>
>>>> I observe a regre
Hi Peter,
On 23/03/18 13:19, Peter Xu wrote:
> On Fri, Mar 23, 2018 at 01:01:43PM +0100, Auger Eric wrote:
>> Hi,
>>
>> On 23/03/18 11:26, Peter Maydell wrote:
>>> On 23 March 2018 at 10:24, Auger Eric wrote:
>>>> Hi,
>>>>
>>>
Hi,
On 28/03/18 03:19, Tiwei Bie wrote:
> This macro isn't used by any VFIO code. And its name is
> too generic. The vfio-common.h (in include/hw/vfio) can
> be included by other modules in QEMU. It can introduce
> conflicts.
>
> Signed-off-by: Tiwei Bie
Reviewed-by: Eric Auger
Thanks
Eric
>
Hi Peter,
On 28/03/18 04:03, Peter Xu wrote:
> On Fri, Mar 23, 2018 at 01:36:36PM +0100, Auger Eric wrote:
>> Hi,
>>
>> On 23/03/18 13:11, Peter Maydell wrote:
>>> On 23 March 2018 at 12:01, Auger Eric wrote:
>>>> Hi,
>>>>
>>>> On
Hi Shannon,
On 28/03/18 06:02, Shannon Zhao wrote:
>
>
> On 2018/3/27 22:15, Eric Auger wrote:
>> With KVM acceleration and if KVM VGICV3 supports to set multiple
>> redistributor regions, we now allow up to 512 vcpus.
>>
>> Signed-off-by: Eric Auger
>> ---
>> hw/arm/virt.c | 17 ++
Hi Peter,
On 28/03/18 09:21, Peter Xu wrote:
> On Wed, Mar 28, 2018 at 08:49:59AM +0200, Auger Eric wrote:
>> Hi Peter,
>>
>> On 28/03/18 04:03, Peter Xu wrote:
>>> On Fri, Mar 23, 2018 at 01:36:36PM +0100, Auger Eric wrote:
>>>> Hi,
>>>>
&g
Hi Alexey, Alex,
On 22/03/18 09:18, Alexey Kardashevskiy wrote:
> The 567b5b309abe ("vfio/pci: Relax DMA map errors for MMIO regions") added
> an error message if a passed memory section address or size is not aligned
> to the minimal IOMMU page size. However although it checks
> offset_within_addr
Hi Alexey,
On 29/03/18 03:55, Alexey Kardashevskiy wrote:
> On 29/3/18 8:03 am, Auger Eric wrote:
>> Hi Alexey, Alex,
>> On 22/03/18 09:18, Alexey Kardashevskiy wrote:
>>> The 567b5b309abe ("vfio/pci: Relax DMA map errors for MMIO regions") added
>>>
Hi Alex,
On 29/03/18 00:13, Alex Williamson wrote:
> On Wed, 28 Mar 2018 23:03:23 +0200
> Auger Eric wrote:
>
>> Hi Alexey, Alex,
>> On 22/03/18 09:18, Alexey Kardashevskiy wrote:
>>> The 567b5b309abe ("vfio/pci: Relax DMA map errors for MMIO regions"
Hi Alexey,
On 03/04/18 05:30, Alexey Kardashevskiy wrote:
> I get the point that it might be confusing and not matching "lspci -vb" but
> still - what is not correct about it? At the time when the message
> appeared, BAR was 0x100a.
Yes they were correct at the time the BAR was located at 0x1
Hi Laszlo, Ard,
On 05/02/2018 04:23 PM, Ard Biesheuvel wrote:
> On 2 May 2018 at 15:54, Laszlo Ersek wrote:
>> On 05/02/18 14:34, Ard Biesheuvel wrote:
>>> On 2 May 2018 at 13:31, Laszlo Ersek wrote:
>>>> On 05/01/18 17:59, Auger Eric wrote:
>>>>&g
Hi Alex,
On 05/01/2018 06:43 PM, Alex Williamson wrote:
> The NVIDIA BAR0 quirks virtualize the PCI config space mirrors found
> in device MMIO space. Normally PCI config space is considered a slow
> path and further optimization is unnecessary, however NVIDIA uses a
> register here to enable the
Hi Alex,
On 05/01/2018 06:43 PM, Alex Williamson wrote:
> With vfio ioeventfd support, we can program vfio-pci to perform a
> specified BAR write when an eventfd is triggered. This allows the
> KVM ioeventfd to be wired directly to vfio-pci, entirely avoiding
> userspace handling for these events
asonably
> need to use, given the right hardware on the right host, but it's an
> unsupported option because we cannot programatically validate it.
> Support rests with the individual user, if it doesn't work, don't use
> it, if it helps, great. Here we have options that are
Hi,
On 05/03/2018 11:45 PM, Alex Williamson wrote:
> The NVIDIA BAR0 quirks virtualize the PCI config space mirrors found
> in device MMIO space. Normally PCI config space is considered a slow
> path and further optimization is unnecessary, however NVIDIA uses a
> register here to enable the MSI
Hi,
On 05/03/2018 11:45 PM, Alex Williamson wrote:
> With vfio ioeventfd support, we can program vfio-pci to perform a
> specified BAR write when an eventfd is triggered. This allows the
> KVM ioeventfd to be wired directly to vfio-pci, entirely avoiding
> userspace handling for these events. On
Hi Peter,
On 05/04/2018 06:51 PM, Peter Maydell wrote:
> On 25 April 2018 at 15:15, Eric Auger wrote:
>> This series implements the emulation code for ARM SMMUv3.
>>
>> SMMUv3 gets instantiated by adding ",iommu=smmuv3" to the virt
>> machine option.
>>
>> Only stage 1 and AArch64 PTW are support
Hi Peter,
On 05/04/2018 07:58 PM, Peter Maydell wrote:
> On 4 May 2018 at 18:15, Peter Maydell wrote:
>> target-arm queue: Eric's SMMUv3 patchset, and an array
>> of minor bugfixes and improvements from various others.
>>
>> thanks
>> -- PMM
>>
>> The following changes since commit c8b7e627b4269a
Hi Peter,
On 09/10/17 19:45, Peter Maydell wrote:
> On 1 September 2017 at 18:21, Eric Auger wrote:
>> This patch implements the IOMMU Memory Region translate()
>> callback. Most of the code relates to the translation
>> configuration decoding and check (STE, CD).
>>
>> Signed-off-by: Eric Auger
Hi,
On 05/02/18 15:53, no-re...@patchew.org wrote:
> Hi,
>
> This series failed docker-mingw@fedora build test. Please find the testing
> commands and
> their output below. If you have Docker installed, you can probably reproduce
> it
> locally.
>
> Type: series
> Message-id: 1517837972-1904-1
Hi Peter,
On 06/02/18 13:43, Peter Maydell wrote:
> On 6 February 2018 at 12:19, Auger Eric wrote:
>> On 09/10/17 19:45, Peter Maydell wrote:
>>> Incidentally, the spec requires us to perform memory accesses as
>>> at least 64-bit single-copy atomic (see 3.21.3) -- d
Hi,
On 07/02/18 10:56, Dr. David Alan Gilbert wrote:
> * Michael S. Tsirkin (m...@redhat.com) wrote:
>> On Tue, Feb 06, 2018 at 03:39:33PM +0800, Peter Xu wrote:
>>> In the past, we prioritized IOMMU migration so that we have such a
>>> priority order:
>>>
>>> IOMMU > PCI Devices
>>>
>>> When
Hi Alex,
On 07/02/18 01:08, 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 Alex,
On 07/02/18 01:26, Alex Williamson wrote:
> This will later be used to include list initialization
>
> Signed-off-by: Alex Williamson
> ---
> hw/vfio/pci-quirks.c | 48 +---
> 1 file changed, 21 insertions(+), 27 deletions(-)
>
> diff --git
Hi Alex,
On 07/02/18 01:26, Alex Williamson wrote:
> Record data writes that come through the NVIDIA BAR0 quirk, if we get
> enough in a row that we're only passing through, automatically enable
> an ioeventfd for it. The primary target for this is the MSI-ACK
> that NVIDIA uses to allow the MSI
Hi Alex,
On 07/02/18 01:26, Alex Williamson wrote:
> We might wish to handle some quirks via ioeventfds, add a list of
> ioeventfds to the quirk.
The commit title is a bit misleading as we only add the data type and
deletion function.
>
> Signed-off-by: Alex Williamson
> ---
> hw/vfio/pci-quirk
Hi Alex,
On 08/02/18 12:10, Auger Eric wrote:
> Hi Alex,
>
> On 07/02/18 01:26, Alex Williamson wrote:
>> Record data writes that come through the NVIDIA BAR0 quirk, if we get
>> enough in a row that we're only passing through, automatically enable
>> an ioeventfd
Hi Alex,
On 07/02/18 01:26, Alex Williamson wrote:
> With vfio ioeventfd support, we can program vfio-pci to perform a
> specified BAR write when an eventfd is triggered. This allows the
> KVM ioeventfd to be wired directly to vfio-pci, entirely avoiding
> userspace handling for these events. On
Hi Alex,
On 07/02/18 17:57, Alex Williamson wrote:
> On Wed, 7 Feb 2018 16:46:19 +0100
> Auger Eric wrote:
>
>> Hi Alex,
>>
>> On 07/02/18 01:08, Alex Williamson wrote:
>>> The ioeventfd here is actually irqfd handling of an ioeventfd such as
>>> sup
Hi Alex,
On 08/02/18 19:24, Alex Williamson wrote:
> On Thu, 8 Feb 2018 12:10:02 +0100
> Auger Eric wrote:
>
>> Hi Alex,
>>
>> On 07/02/18 01:26, Alex Williamson wrote:
>>> Record data writes that come through the NVIDIA BAR0 quirk, if we get
>>> en
Hi Alex,
On 08/02/18 19:33, Alex Williamson wrote:
> On Thu, 8 Feb 2018 12:11:57 +0100
> Auger Eric wrote:
>
>> Hi Alex,
>>
>> On 07/02/18 01:26, Alex Williamson wrote:
>>> We might wish to handle some quirks via ioeventfds, add a list of
>>> ioeven
Hi Peter,
On 06/03/18 15:08, Peter Maydell wrote:
> On 17 February 2018 at 18:46, Eric Auger wrote:
>> We enumerate all the PCI devices attached to the SMMU and
>> initialize an associated IOMMU memory region and address space.
>> This happens on SMMU base instance init.
>>
>> Those info are stor
Hi Peter,
On 06/03/18 13:09, Peter Maydell wrote:
> On 17 February 2018 at 18:46, Eric Auger wrote:
>> The patch introduces the smmu base device and class for the ARM
>> smmu. Devices for specific versions will be derived from this
>> base device.
>>
>> We also introduce some important datatypes.
Hi Peter,
On 06/03/18 20:43, Peter Maydell wrote:
> On 17 February 2018 at 18:46, Eric Auger wrote:
>> This patch implements the page table walk for VMSAv8-64.
>>
>> Signed-off-by: Eric Auger
>>
>> ---
>> v8 -> v9:
>> - remove guest error log on PTE fetch fault
>> - rename trace functions
>> -
Hi Peter,
On 07/03/18 17:35, Peter Maydell wrote:
> On 7 March 2018 at 16:23, Auger Eric wrote:
>> Hi Peter,
>>
>> On 06/03/18 20:43, Peter Maydell wrote:
>>> On 17 February 2018 at 18:46, Eric Auger wrote:
>
>>>> +int smmu_ptw(SMMUTransCfg
Hi Kirti,
On 3/18/20 8:41 PM, Kirti Wankhede wrote:
> - Defined MIGRATION region type and sub-type.
>
> - Defined vfio_device_migration_info structure which will be placed at the
> 0th offset of migration region to get/set VFIO device related
> information. Defined members of structure and us
Hi Kirti,
On 3/18/20 8:41 PM, Kirti Wankhede wrote:
> vfio_pfn.ref_count is always updated by holding iommu->lock, using atomic
> variable is overkill.
>
> Signed-off-by: Kirti Wankhede
> Reviewed-by: Neo Jia
> ---
> drivers/vfio/vfio_iommu_type1.c | 9 +
> 1 file changed, 5 insertions
Hi,
On 3/19/20 2:09 PM, Alex Williamson wrote:
> On Thu, 19 Mar 2020 01:05:54 -0400
> Yan Zhao wrote:
>
>> On Thu, Mar 19, 2020 at 11:49:26AM +0800, Alex Williamson wrote:
>>> On Wed, 18 Mar 2020 21:17:03 -0400
>>> Yan Zhao wrote:
>>>
On Thu, Mar 19, 2020 at 03:41:08AM +0800, Kirti Wank
Hi Kirti,
On 3/19/20 9:16 PM, Kirti Wankhede wrote:
> - Defined MIGRATION region type and sub-type.
>
> - Defined vfio_device_migration_info structure which will be placed at the
> 0th offset of migration region to get/set VFIO device related
> information. Defined members of structure and us
Hi Kirti,
On 3/19/20 9:16 PM, Kirti Wankhede wrote:
> vfio_pfn.ref_count is always updated by holding iommu->lock, using atomic
> variable is overkill.
>
> Signed-off-by: Kirti Wankhede
> Reviewed-by: Neo Jia
Reviewed-by: Eric Auger
Thanks
Eric
> ---
> drivers/vfio/vfio_iommu_type1.c | 9 ++
Hi Kirti,
On 3/19/20 9:16 PM, Kirti Wankhede wrote:
> IOMMU container maintains a list of all pages pinned by vfio_pin_pages API.
> All pages pinned by vendor driver through this API should be considered as
> dirty during migration. When container consists of IOMMU capable device and
> all pages a
Hi Shameer,
On 3/25/20 12:35 PM, Shameerali Kolothum Thodi wrote:
> Hi Eric,
>
>> -Original Message-
>> From: Eric Auger [mailto:eric.au...@redhat.com]
>> Sent: 20 March 2020 16:58
>> To: eric.auger@gmail.com; eric.au...@redhat.com;
>> qemu-devel@nongnu.org; qemu-...@nongnu.org; peter
Hi Zenghui,
On 3/25/20 9:10 AM, Zenghui Yu wrote:
> Hi Eric,
>
> On 2020/3/20 17:24, Eric Auger wrote:
>> Introduce an helper functions to register
>> - a new device, characterized by its device id and the
>> max number of event IDs that dimension its ITT (Interrupt
>> Translation Table).
Hi
On 2/25/20 12:48 PM, Paolo Bonzini wrote:
> From: Igor Mammedov
>
> It will be possible for main RAM to come from memory-backend
> and we should check that size specified in -m matches the size
> of the backend and [MachineState::]ram_size also matches
> backend's size.
>
> However -m parsin
Hi Shameer,
On 3/18/20 1:37 PM, Shameer Kolothum wrote:
> This adds support for memory hot remove on arm/virt that
> uses acpi ged device.
I gave this a try and it works fine if the PCDIMM slot was initially
hotplugged:
(QEMU) object-add qom-type=memory-backend-ram id=mem1 props.size=4294967296
{
ady reverted by commit 2a7b18a3205b,
> so revert remaining initialization of above machine fields to make
> virt_kvm_type() work as it used to.
Oh I did not notice set_memory_options() change was already reverted.
>
> Signed-off-by: Igor Mammedov
> Reported-by: Auger Eric
Reviewed-b
Hi Shameer,
On 3/26/20 12:14 PM, Shameerali Kolothum Thodi wrote:
> Hi Eric,
>
>> -Original Message-----
>> From: Auger Eric [mailto:eric.au...@redhat.com]
>> Sent: 26 March 2020 11:01
>> To: Shameerali Kolothum Thodi ;
>> qemu-devel@nongnu.org; qemu-...@n
Hi Bharat
On 3/23/20 9:46 AM, Bharat Bhushan wrote:
> This patch implements the PROBE request. Currently supported
> page size mask per endpoint is returned. Also append a NONE
> property in the end.
>
> Signed-off-by: Bharat Bhushan
> Signed-off-by: Eric Auger
> ---
> include/standard-headers
601 - 700 of 1369 matches
Mail list logo
