* For vhost, VIRTIO_F_IOMMU_PLATFORM means the backend support
> - * incremental memory mapping API via IOTLB API. For platform that
> - * does not have IOMMU, there's no need to enable this feature
> - * which may cause unnecessary IOTLB miss/update transactions.
> - */
> -if (vdev) {
> -return virtio_bus_device_iommu_enabled(vdev) &&
> -virtio_host_has_feature(vdev, VIRTIO_F_IOMMU_PLATFORM);
> -} else {
> -return false;
> -}
> -}
> -
> static void *vhost_memory_map(struct vhost_dev *dev, hwaddr addr,
>hwaddr *plen, bool is_write)
> {
Besides,
Tested-by: Eric Auger
Eric
Hi Michael,
On 11/29/22 16:44, Michael S. Tsirkin wrote:
> On Tue, Nov 29, 2022 at 10:52:29AM +0100, Eric Auger wrote:
>> Hi Jason,
>>
>> On 11/29/22 05:02, Jason Wang wrote:
>>> When vIOMMU is enabled, the vq->used_phys is actually the IOVA not
>>> GPA
Hi Peter
On 12/1/22 17:25, Peter Xu wrote:
> It seems not super clear on when iova_tree is used, and why. Add a rich
> comment above iova_tree to track why we needed the iova_tree, and when we
> need it.
>
> Suggested-by: Jason Wang
> Signed-off-by: Peter Xu
> ---
> include/hw/i386/intel_iommu
Hi Peter,
On 12/1/22 20:22, Peter Xu wrote:
> On Thu, Dec 01, 2022 at 07:17:41PM +0100, Eric Auger wrote:
>> Hi Peter
> Hi, Eric,
>
>> On 12/1/22 17:25, Peter Xu wrote:
>>> It seems not super clear on when iova_tree is used, and why. Add a rich
>>> comment
Hi Peter,
On 12/6/22 00:28, Peter Xu wrote:
> On Mon, Dec 05, 2022 at 12:23:20PM +0800, Jason Wang wrote:
>> On Fri, Dec 2, 2022 at 12:25 AM Peter Xu wrote:
>>> It seems not super clear on when iova_tree is used, and why. Add a rich
>>> comment above iova_tree to track why we needed the iova_tree
silently.
>
> Signed-off-by: Jason Wang
Reviewed-by: Eric Auger
Thanks
Eric
> ---
> hw/i386/intel_iommu.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> index a08ee85edf..9143376677 100644
> ---
y?
While thinking about those error handlings (including the SMMU ones)
nothing should really prevent you from registering a notifier that is
not signalled. Maybe we should add in the documentation that any attempt
to register an IOMMU notifier to an IOMMU MR that is not able to signal
it
On 12/6/22 17:05, Peter Xu wrote:
> On Tue, Dec 06, 2022 at 02:16:32PM +0100, Eric Auger wrote:
>> Hi Peter,
>> On 12/6/22 00:28, Peter Xu wrote:
>>> On Mon, Dec 05, 2022 at 12:23:20PM +0800, Jason Wang wrote:
>>>> On Fri, Dec 2, 2022 at 12:25 AM Peter Xu w
Hi Gavin,
On 8/2/22 08:45, Gavin Shan wrote:
> There are 3 highmem IO regions as below. They can be disabled in
> two situations: (a) The specific region is disabled by user. (b)
> The specific region doesn't fit in the PA space. However, the base
> address and highest_gpa are still updated no mat
Hi Gavin,
On 8/2/22 08:45, Gavin Shan wrote:
> When one specific high memory region is disabled due to the PA
> limit, it'd better to warn user about that. The warning messages
> help to identify the cause in some cases. For example, PCIe device
> that has large MMIO bar, to be covered by PCIE_MMI
Hi,
On 8/3/22 09:01, Marc Zyngier wrote:
> On Wed, 03 Aug 2022 04:01:04 +0100,
> Gavin Shan wrote:
>> Hi Eric,
>>
>> On 8/2/22 7:41 PM, Eric Auger wrote:
>>> On 8/2/22 08:45, Gavin Shan wrote:
>>>> There are 3 highmem IO regions as below. They ca
Hi Gavin,
On 8/3/22 05:01, Gavin Shan wrote:
> Hi Eric,
>
> On 8/2/22 7:41 PM, Eric Auger wrote:
>> On 8/2/22 08:45, Gavin Shan wrote:
>>> There are 3 highmem IO regions as below. They can be disabled in
>>> two situations: (a) The specific region is disabled by
Hi,
On 8/3/22 15:02, Gavin Shan wrote:
> Hi Marc,
>
> On 8/3/22 5:01 PM, Marc Zyngier wrote:
>> On Wed, 03 Aug 2022 04:01:04 +0100,
>> Gavin Shan wrote:
>>> On 8/2/22 7:41 PM, Eric Auger wrote:
>>>> On 8/2/22 08:45, Gavin Shan wrote:
>>>>
On 8/4/22 04:47, Gavin Shan wrote:
> Hi Eric,
>
> On 8/3/22 10:52 PM, Eric Auger wrote:
>> On 8/3/22 15:02, Gavin Shan wrote:
>>> On 8/3/22 5:01 PM, Marc Zyngier wrote:
>>>> On Wed, 03 Aug 2022 04:01:04 +0100,
>>>> Gavin Shan wrote:
>>>
Hi Gavin,
On 8/5/22 10:36, Gavin Shan wrote:
> Hi Eric,
>
> On 8/4/22 5:19 PM, Eric Auger wrote:
>> On 8/4/22 04:47, Gavin Shan wrote:
>>> On 8/3/22 10:52 PM, Eric Auger wrote:
>>>> On 8/3/22 15:02, Gavin Shan wrote:
>>>>> On 8/3/22 5:01 PM, Marc
a new mask being null. So if Coverity complains
round those ctz64/BIT_ULL with CID 1517772 this is a false
positive
Signed-off-by: Eric Auger
Fixes: 94df5b2180 ("virtio-iommu: Fix 64kB host page size VFIO device
assignment")
---
hw/virtio/virtio-iommu.c | 8 +---
1 file changed, 5 i
Introduce a new enum type property allowing to set an
IOMMU granule. Values are 4k, 8k, 16k, 64k and host.
This latter indicates the vIOMMU granule will match
the host page size.
A subsequent patch will add such a property to the
virtio-iommu device.
Signed-off-by: Eric Auger
Signed-off-by
History:
v4 -> v5:
- use -(n * KiB) (Philippe)
- remove code that can be automatically generated
and add the new enum in qapi/virtio.json (Philippe).
- Improve commit msg on last patch and collected Philippe's R-b
v3 -> v4:
- Add 8K granule (Richard)
v2 -> v3
- introduce a dedicated g
granule. But
until we get this upgraded, this new default is probably
better because I don't think anyone is currently interested in
running a 4KB page size guest with virtio-iommu on a 64KB host.
However supporting 64kB guest on 64kB host with virtio-iommu and
VFIO looks a more important
This allows to choose which granule will be used by
default by the virtio-iommu. Current page size mask
default is qemu_target_page_mask so this translates
into a 4K granule.
Signed-off-by: Eric Auger
---
v4 -> v5:
- use -(n * KiB) (Phild)
v3 -> v4:
- granule_mode introduction moved t
pe's R-b
v3 -> v4:
- Add 8K granule (Richard)
v2 -> v3
- introduce a dedicated granule option to handle the compat
Eric Auger (3):
qdev: Add a granule_mode property
virtio-iommu: Add a granule property
virtio-iommu: Change the default granule to the host page size
qapi/virti
Introduce a new enum type property allowing to set an
IOMMU granule. Values are 4k, 8k, 16k, 64k and host.
This latter indicates the vIOMMU granule will match
the host page size.
A subsequent patch will add such a property to the
virtio-iommu device.
Signed-off-by: Eric Auger
Signed-off-by
This allows to choose which granule will be used by
default by the virtio-iommu. Current page size mask
default is qemu_target_page_mask so this translates
into a 4K granule.
Signed-off-by: Eric Auger
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Zhenzhong Duan
---
v4 -> v5:
- use
granule. But
until we get this upgraded, this new default is probably
better because I don't think anyone is currently interested in
running a 4KB page size guest with virtio-iommu on a 64KB host.
However supporting 64kB guest on 64kB host with virtio-iommu and
VFIO looks a more important
Hi Zhenzhong,
On 2/26/24 08:36, Duan, Zhenzhong wrote:
>
>> -Original Message-
>> From: Eric Auger
>> Subject: Re: [PATCH rfcv2 14/18] intel_iommu: Add a framework to check
>> and sync host IOMMU cap/ecap
>>
>>
>>
>> On 2/1/24 08:28, Zh
Hi Cédric,
On 2/27/24 18:17, Cédric Le Goater wrote:
> Hello Eric,
>
> On 2/15/24 09:42, Eric Auger wrote:
>> Currently the default input range can extend to 64 bits. On x86,
>> when the virtio-iommu protects vfio devices, the physical iommu
>> may support only 39 bit
Hi,
On 2/27/24 18:17, Cédric Le Goater wrote:
> Hello Eric,
>
> On 2/15/24 09:42, Eric Auger wrote:
>> Currently the default input range can extend to 64 bits. On x86,
>> when the virtio-iommu protects vfio devices, the physical iommu
>> may support only 39 bits. Let&
Hi Igor,
On 2/29/24 10:20, Igor Mammedov wrote:
> On Thu, 15 Feb 2024 09:42:13 +0100
> Eric Auger wrote:
>
>> Currently the default input range can extend to 64 bits. On x86,
>> when the virtio-iommu protects vfio devices, the physical iommu
>> may support only 39 bit
granule. But
until we get this upgraded, this new default is probably
better because I don't think anyone is currently interested in
running a 4KB page size guest with virtio-iommu on a 64KB host.
However supporting 64kB guest on 64kB host with virtio-iommu and
VFIO looks a more important
This allows to choose which granule will be used by
default by the virtio-iommu. Current page size mask
default is qemu_target_page_mask so this translates
into a 4k granule on ARM and x86_64 where virtio-iommu
is supported.
Signed-off-by: Eric Auger
Reviewed-by: Philippe Mathieu-Daudé
Reviewed
aw-bits is a new option that allows to set the bit width of
the input address range. This value will be used as a default for
the device config input_range.end. By default it is set to 64 bits
which is the current value.
Signed-off-by: Eric Auger
Reviewed-by: Zhenzhong Duan
Reviewed-by: Cédric
Document the new aw-bits option.
Signed-off-by: Eric Auger
Reviewed-by: Cédric Le Goater
---
v4 -> v5
- tweek the aw-bits option description according to Cédric's
suggestion
---
qemu-options.hx | 3 +++
1 file changed, 3 insertions(+)
diff --git a/qemu-options.hx b/qemu-options.
Use %u format to trace domain_range limits.
Signed-off-by: Eric Auger
Reviewed-by: Zhenzhong Duan
Reviewed-by: Cédric Le Goater
---
hw/virtio/trace-events | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/virtio/trace-events b/hw/virtio/trace-events
index 77905d1994
Introduce a new enum type property allowing to set an
IOMMU granule. Values are 4k, 8k, 16k, 64k and host.
This latter indicates the vIOMMU granule will match
the host page size.
A subsequent patch will add such a property to the
virtio-iommu device.
Signed-off-by: Eric Auger
Signed-off-by
r instance on VTD). New default
usually match the host HW capability.
For more details please see the cover letter of [1] and [2].
This series can be found at:
https://github.com/eauger/qemu/tree/granule_aw_bits_v4
Eric Auger (9):
qdev: Add a granule_mode property
virtio-iommu: Add
We are missing an entry for the virtio-iommu-pci device. Add the
information on which machine it is currently supported and document
the new granule option.
Signed-off-by: Eric Auger
---
qemu-options.hx | 8
1 file changed, 8 insertions(+)
diff --git a/qemu-options.hx b/qemu
used to have a virtio-iommu default input range
of 64 bits.
Of course if aw-bits is set from the command line, the default
is overriden.
Signed-off-by: Eric Auger
---
v5 -> v6:
- split pc/arm settings
v3 -> v4:
- update the qos test to relax the check on the max input IOVA
v2 -> v
On ARM we set 48b as a default (matching SMMUv3 SMMU_IDR5.VAX == 0).
hw_compat_8_2 is used to handle the compatibility for machine types
before 9.0 (default was 64 bits).
Signed-off-by: Eric Auger
---
hw/arm/virt.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/hw/arm
Hi Zhenzhong,
On 3/6/24 04:15, Duan, Zhenzhong wrote:
> Hi Eric,
>
>> -Original Message-----
>> From: Eric Auger
>> Subject: [PATCH v6 7/9] hw/i386/q35: Set virtio-iommu aw-bits default
>> value to 39
>>
>> Currently the default input range can ext
On 3/6/24 04:25, Duan, Zhenzhong wrote:
>
>> -Original Message-
>> From: Eric Auger
>> Subject: [PATCH v6 8/9] hw/arm/virt: Set virtio-iommu aw-bits default value
>> to 48
>>
>> On ARM we set 48b as a default (matching SMMUv3 SMMU_IDR5.VAX == 0)
On ARM we set 48b as a default (matching SMMUv3 SMMU_IDR5.VAX == 0).
hw_compat_8_2 is used to handle the compatibility for machine types
before 9.0 (default was 64 bits).
Signed-off-by: Eric Auger
Reviewed-by: Zhenzhong Duan
---
v6 -> v7
turn arm_virt_compat and arm_virt_compat_len sta
Introduce a new enum type property allowing to set an
IOMMU granule. Values are 4k, 8k, 16k, 64k and host.
This latter indicates the vIOMMU granule will match
the host page size.
A subsequent patch will add such a property to the
virtio-iommu device.
Signed-off-by: Eric Auger
Signed-off-by
Use %u format to trace domain_range limits.
Signed-off-by: Eric Auger
Reviewed-by: Zhenzhong Duan
Reviewed-by: Cédric Le Goater
---
hw/virtio/trace-events | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/virtio/trace-events b/hw/virtio/trace-events
index 77905d1994
This allows to choose which granule will be used by
default by the virtio-iommu. Current page size mask
default is qemu_target_page_mask so this translates
into a 4k granule on ARM and x86_64 where virtio-iommu
is supported.
Signed-off-by: Eric Auger
Reviewed-by: Philippe Mathieu-Daudé
Reviewed
We are missing an entry for the virtio-iommu-pci device. Add the
information on which machine it is currently supported and document
the new granule option.
Signed-off-by: Eric Auger
---
qemu-options.hx | 8
1 file changed, 8 insertions(+)
diff --git a/qemu-options.hx b/qemu
used to have a virtio-iommu default input range
of 64 bits.
Of course if aw-bits is set from the command line, the default
is overriden.
Signed-off-by: Eric Auger
---
v6 -> v7:
- use static pc_q35_compat_defaults
- remove spurious header addition
- s/32/UINT32_MAX in the qtest
v5 -> v6:
aw-bits is a new option that allows to set the bit width of
the input address range. This value will be used as a default for
the device config input_range.end. By default it is set to 64 bits
which is the current value.
Signed-off-by: Eric Auger
Reviewed-by: Zhenzhong Duan
Reviewed-by: Cédric
Document the new aw-bits option.
Signed-off-by: Eric Auger
Reviewed-by: Cédric Le Goater
---
v4 -> v5
- tweek the aw-bits option description according to Cédric's
suggestion
---
qemu-options.hx | 3 +++
1 file changed, 3 insertions(+)
diff --git a/qemu-options.hx b/qemu-options.
granule. But
until we get this upgraded, this new default is probably
better because I don't think anyone is currently interested in
running a 4KB page size guest with virtio-iommu on a 64KB host.
However supporting 64kB guest on 64kB host with virtio-iommu and
VFIO looks a more important
r instance on VTD). New default
usually match the host HW capability.
For more details please see the cover letter of [1] and [2].
This series can be found at:
https://github.com/eauger/qemu/tree/granule_aw_bits_v7
History:
v6 -> v7:
- Made property static in virt and pc_q35. Fix qtest 32
Hi Philippe,
On 3/6/24 21:44, Philippe Mathieu-Daudé wrote:
> On 6/3/24 21:32, Eric Auger wrote:
>> We are missing an entry for the virtio-iommu-pci device. Add the
>> information on which machine it is currently supported and document
>> the new granule option.
>>
&
On 3/6/24 21:45, Philippe Mathieu-Daudé wrote:
> On 6/3/24 21:32, Eric Auger wrote:
>> aw-bits is a new option that allows to set the bit width of
>> the input address range. This value will be used as a default for
>> the device config input_range.end. By default it is se
On 3/6/24 21:48, Philippe Mathieu-Daudé wrote:
> On 6/3/24 21:32, Eric Auger wrote:
>> Document the new aw-bits option.
>>
>> Signed-off-by: Eric Auger
>> Reviewed-by: Cédric Le Goater
>>
>> ---
>>
>> v4 -> v5
>> - tweek the aw-bi
Hi Cédric,
On 3/6/24 14:34, Cédric Le Goater wrote:
> We will use the Error object to improve error reporting in the
> .log_global*() handlers of VFIO. Add documentation while at it.
>
> Reviewed-by: Philippe Mathieu-Daudé
> Signed-off-by: Cédric Le Goater
> ---
>
> Changes in v3:
>
> - Use
Hi Cédric,
On 3/6/24 14:34, Cédric Le Goater wrote:
> This allows to update the Error argument of the VFIO log_global_start()
> handler. Errors detected when device level logging is started will be
> propagated up to qemu_savevm_state_setup() when the ram save_setup()
> handler is executed.
>
> T
On 3/6/24 14:34, Cédric Le Goater wrote:
> This improves error reporting in the log_global_stop() VFIO handler.
>
> Reviewed-by: Philippe Mathieu-Daudé
> Signed-off-by: Cédric Le Goater
> ---
>
> Changes in v4:
>
> - Dropped log_global_stop() and log_global_sync() changes
>
> Changes
Hi Cédric,
On 3/6/24 14:34, Cédric Le Goater wrote:
> Add an Error** argument to vfio_migration_set_state() and adjust
> callers, including vfio_save_setup(). The error will be propagated up
> to qemu_savevm_state_setup() where the save_setup() handler is
> executed.
>
> Modify vfio_vmstate_chang
On 3/6/24 14:34, Cédric Le Goater wrote:
> Use vmstate_save_state_with_err() to improve error reporting in the
> callers and store a reported error under the migration stream. Add
> documentation while at it.
>
> Reviewed-by: Philippe Mathieu-Daudé
> Signed-off-by: Cédric Le Goater
> ---
> i
On 3/6/24 14:34, Cédric Le Goater wrote:
> Let the callers do the error reporting. Add documentation while at it.
>
> Signed-off-by: Cédric Le Goater
> ---
> include/hw/vfio/vfio-common.h | 4 +-
> include/hw/vfio/vfio-container-base.h | 17 +++-
> hw/vfio/common.c
On 3/6/24 14:34, Cédric Le Goater wrote:
> vfio_save_complete_precopy() currently returns before doing the trace
> event. Change that.
>
> Signed-off-by: Cédric Le Goater
> ---
> hw/vfio/migration.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/hw/vfio/migration.c b/hw/vfio/migr
Hi Cédric,
On 3/6/24 14:34, Cédric Le Goater wrote:
> vfio_set_migration_error() sets the 'return' error on the migration
> stream if a migration is in progress. To improve error reporting, add
> a new Error* argument to also set the Error object on the migration
> stream, if a migration is progre
: Cédric Le Goater
Reviewed-by: Eric Auger
Eric
> ---
>
> Changes in v4:
>
> - Fixed state name printed out in error returned by vfio_save_setup()
> - Fixed test on error returned by qemu_file_get_error()
>
> hw/vfio/migration.c | 15 ---
>
On 3/7/24 11:21, Philippe Mathieu-Daudé wrote:
> On 7/3/24 08:32, Eric Auger wrote:
>> Hi Philippe,
>>
>> On 3/6/24 21:44, Philippe Mathieu-Daudé wrote:
>>> On 6/3/24 21:32, Eric Auger wrote:
>>>> We are missing an entry for the virtio-iommu-pci device.
Introduce a new enum type property allowing to set an
IOMMU granule. Values are 4k, 8k, 16k, 64k and host.
This latter indicates the vIOMMU granule will match
the host page size.
A subsequent patch will add such a property to the
virtio-iommu device.
Signed-off-by: Eric Auger
Signed-off-by
aw-bits is a new option that allows to set the bit width of
the input address range. This value will be used as a default for
the device config input_range.end. By default it is set to 64 bits
which is the current value.
Signed-off-by: Eric Auger
Reviewed-by: Zhenzhong Duan
Reviewed-by: Cédric
This allows to choose which granule will be used by
default by the virtio-iommu. Current page size mask
default is qemu_target_page_mask so this translates
into a 4k granule on ARM and x86_64 where virtio-iommu
is supported.
Signed-off-by: Eric Auger
Reviewed-by: Philippe Mathieu-Daudé
Reviewed
used to have a virtio-iommu default input range
of 64 bits.
Of course if aw-bits is set from the command line, the default
is overriden.
Signed-off-by: Eric Auger
---
v6 -> v7:
- use static pc_q35_compat_defaults
- remove spurious header addition
- s/32/UINT32_MAX in the qtest
v5 -> v6:
We are missing an entry for the virtio-iommu-pci device. Add the
information on which machine it is currently supported and document
the new granule option.
Signed-off-by: Eric Auger
---
v7 -> v8
- precise x86_64 and ARM
---
qemu-options.hx | 8
1 file changed, 8 insertions(+)
d
bad aw-bits,
doc improvement
v6 -> v7:
- Made property static in virt and pc_q35. Fix qtest 32 limit.
Eric Auger (9):
qdev: Add a granule_mode property
virtio-iommu: Add a granule property
virtio-iommu: Change the default granule to the host page size
qemu-options.hx: Document the virtio-iom
Use %u format to trace domain_range limits.
Signed-off-by: Eric Auger
Reviewed-by: Zhenzhong Duan
Reviewed-by: Cédric Le Goater
---
hw/virtio/trace-events | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/virtio/trace-events b/hw/virtio/trace-events
index 77905d1994
Document the new aw-bits option.
Signed-off-by: Eric Auger
---
v7 -> v8:
- remove "it defaults"
- removed Cedric's R-b
v4 -> v5
- tweek the aw-bits option description according to Cédric's
suggestion
---
qemu-options.hx | 3 +++
1 file changed, 3 insertions(+)
di
granule. But
until we get this upgraded, this new default is probably
better because I don't think anyone is currently interested in
running a 4KB page size guest with virtio-iommu on a 64KB host.
However supporting 64kB guest on 64kB host with virtio-iommu and
VFIO looks a more important
On ARM we set 48b as a default (matching SMMUv3 SMMU_IDR5.VAX == 0).
hw_compat_8_2 is used to handle the compatibility for machine types
before 9.0 (default was 64 bits).
Signed-off-by: Eric Auger
Reviewed-by: Zhenzhong Duan
---
v6 -> v7
turn arm_virt_compat and arm_virt_compat_len sta
object_property_get_uint() call (Cédric)
- use VTD_HOST_AW_39BIT (Cédric)
v1 -> v2
- Limit aw to 48b on ARM
- Check aw is within [32,64]
- Use hw_compat_8_2
Eric Auger (4):
virtio-iommu: Add an option to define the input range width
virtio-iommu: Trace domain range limits as unsigned int
Use %u format to trace domain_range limits.
Signed-off-by: Eric Auger
Reviewed-by: Zhenzhong Duan
Reviewed-by: Cédric Le Goater
---
hw/virtio/trace-events | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/virtio/trace-events b/hw/virtio/trace-events
index 77905d1994
e use hw_compat_8_2 to handle the compatibility for machines
before 9.0 which used to have a virtio-iommu default input range
of 64 bits.
Of course if aw-bits is set from the command line, the default
is overriden.
Signed-off-by: Eric Auger
Reviewed-by: Zhenzhong Duan
Tested-by: Yanghang Liu
---
v3
We are missing an entry for the virtio-iommu-pci device. Add the
information on which machine it is currently supported and document
the new aw-bits option.
Signed-off-by: Eric Auger
---
qemu-options.hx | 8
1 file changed, 8 insertions(+)
diff --git a/qemu-options.hx b/qemu
aw-bits is a new option that allows to set the bit width of
the input address range. This value will be used as a default for
the device config input_range.end. By default it is set to 64 bits
which is the current value.
Signed-off-by: Eric Auger
Reviewed-by: Zhenzhong Duan
Reviewed-by: Cédric
static int decode_cd(SMMUTransCfg *cfg, CD *cd,
> SMMUEventInfo *event)
>
> cfg->oas = oas2bits(CD_IPS(cd));
> cfg->oas = MIN(oas2bits(SMMU_IDR5_OAS), cfg->oas);
> cfg->tbi = CD_TBI(cd);
> cfg->asid = CD_ASID(cd);
> +cfg->affd = CD_AFFD(cd);
>
> trace_smmuv3_decode_cd(cfg->oas);
>
> /* decode data dependent on TT */
> for (i = 0; i <= 1; i++) {
Besides, looks good to me
Reviewed-by: Eric Auger
Eric
We are missing an entry for the virtio-iommu-pci device. Add the
information on which machine it is currently supported and document
the new aw-bits option.
Signed-off-by: Eric Auger
---
v4 -> v5
- tweek the aw-bits option description according to Cédric's
suggestion
---
qemu-option
e use hw_compat_8_2 to handle the compatibility for machines
before 9.0 which used to have a virtio-iommu default input range
of 64 bits.
Of course if aw-bits is set from the command line, the default
is overriden.
Signed-off-by: Eric Auger
Reviewed-by: Zhenzhong Duan
Tested-by: Yanghang Liu
---
v3
on object_property_get_uint() call (Cédric)
- use VTD_HOST_AW_39BIT (Cédric)
v1 -> v2
- Limit aw to 48b on ARM
- Check aw is within [32,64]
- Use hw_compat_8_2
Eric Auger (4):
virtio-iommu: Add an option to define the input range width
virtio-iommu: Trace domain range limits as unsigned int
aw-bits is a new option that allows to set the bit width of
the input address range. This value will be used as a default for
the device config input_range.end. By default it is set to 64 bits
which is the current value.
Signed-off-by: Eric Auger
Reviewed-by: Zhenzhong Duan
Reviewed-by: Cédric
Use %u format to trace domain_range limits.
Signed-off-by: Eric Auger
Reviewed-by: Zhenzhong Duan
Reviewed-by: Cédric Le Goater
---
hw/virtio/trace-events | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/virtio/trace-events b/hw/virtio/trace-events
index 77905d1994
Hi Shaoqin,
On 2/1/24 09:51, Shaoqin Huang wrote:
> The KVM_ARM_VCPU_PMU_V3_FILTER provides the ability to let the VMM decide
> which PMU events are provided to the guest. Add a new option
> `kvm-pmu-filter` as -cpu sub-option to set the PMU Event Filtering.
> Without the filter, all PMU events ar
On 2/15/24 09:42, Eric Auger wrote:
> We are missing an entry for the virtio-iommu-pci device. Add the
> information on which machine it is currently supported and document
> the new aw-bits option.
>
> Signed-off-by: Eric Auger
argh forgot to add Cédric R-b collected on
Hi,
On 2/14/24 17:25, Joao Martins wrote:
> On 14/02/2024 15:40, Cédric Le Goater wrote:
>> Hello Joao,
>>
>> On 2/13/24 12:59, Joao Martins wrote:
>>> On 12/02/2024 13:56, Joao Martins wrote:
This small series adds support for Dirty Tracking in IOMMUFD backend.
The sole reason I still m
Hi Zhenzhong,
On 2/1/24 08:28, Zhenzhong Duan wrote:
> Either IOMMULegacyDevice or IOMMUFDDevice into VFIODevice, neither
> both.
>
> Signed-off-by: Zhenzhong Duan
> ---
> include/hw/vfio/vfio-common.h | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/include/hw/vfio/vfio-com
On 2/1/24 08:28, Zhenzhong Duan wrote:
> Either IOMMULegacyDevice or IOMMUFDDevice into VFIODevice, neither
> both.
>
> Signed-off-by: Zhenzhong Duan
> ---
> include/hw/vfio/vfio-common.h | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/include/hw/vfio/vfio-common.h b/incl
Hi Zhenzhong,
On 2/1/24 08:28, Zhenzhong Duan wrote:
> This callback will be used to initialize base and public elements
> in IOMMULegacyDevice.
>
> Signed-off-by: Zhenzhong Duan
> ---
> hw/vfio/container.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/hw/vfio/container.c b/hw/v
Hi Zhenzhong,
On 2/1/24 08:28, Zhenzhong Duan wrote:
> From: Yi Liu
>
> This adds pci_device_set/unset_iommu_device() to set/unset
> HostIOMMUDevice for a given PCIe device. Caller of set
> should fail if set operation fails.
>
> Extract out pci_device_get_iommu_bus_devfn() to facilitate
> implem
On 2/1/24 08:28, Zhenzhong Duan wrote:
> From: Yi Liu
>
> This adds set/unset_iommu_device() implementation in Intel vIOMMU.
> In set call, a pointer to host IOMMU device info is stored in hash
> table indexed by PCI BDF.
>
> Signed-off-by: Yi Liu
> Signed-off-by: Yi Sun
> Signed-off-by: Zhen
On 2/1/24 08:28, Zhenzhong Duan wrote:
> From: Yi Liu
>
> Add a framework to check and synchronize host IOMMU cap/ecap with
> vIOMMU cap/ecap.
>
> The sequence will be:
>
> vtd_cap_init() initializes iommu->cap/ecap.
> vtd_check_hdev() update iommu->cap/ecap based on host cap/ecap.
> iommu->cap
On 2/21/24 12:31, Jean-Philippe Brucker wrote:
> On Wed, Feb 21, 2024 at 11:41:57AM +0100, Eric Auger wrote:
>> Hi,
>>
>> On 2/13/24 13:00, Michael S. Tsirkin wrote:
>>> On Tue, Feb 13, 2024 at 12:24:22PM +0100, Eric Auger wrote:
>>>> Hi Michael,
>&
Hi,
On 2/13/24 13:00, Michael S. Tsirkin wrote:
> On Tue, Feb 13, 2024 at 12:24:22PM +0100, Eric Auger wrote:
>> Hi Michael,
>> On 2/13/24 12:09, Michael S. Tsirkin wrote:
>>> On Tue, Feb 13, 2024 at 11:32:13AM +0100, Eric Auger wrote:
>>>> Do you have an o
orting 64kB guest on 64kB host with virtio-iommu and
VFIO looks a more important feature.
Signed-off-by: Eric Auger
---
hw/core/machine.c| 1 +
hw/virtio/virtio-iommu.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/core/machine.c b/hw/core/machine.c
index 70ac9695
This allows to choose which granule will be used by
default by the virtio-iommu. Current default is 4K.
Signed-off-by: Eric Auger
---
hw/virtio/virtio-iommu.c | 24 +---
qemu-options.hx | 3 +++
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/hw
Introduce a new enum type property allowing to set an
IOMMU granule. Values are 4K, 16K, 64K and host. This
latter indicates the vIOMMU granule will matches the
host page size.
A subsequent patch will add such a property to the
virtio-iommu device.
Signed-off-by: Eric Auger
---
include/hw/qdev
ze_mask
https://lore.kernel.org/all/20240117132039.332273-1-eric.au...@redhat.com/
Applied on top of
[PATCH v5 0/4] VIRTIO-IOMMU: Introduce an aw-bits option
https://lore.kernel.org/all/20240215084315.863897-1-eric.au...@redhat.com/
History:
v2 -> v3
- introduce a dedicated granule option to handle the
Hi Richard,
On 2/21/24 22:58, Richard Henderson wrote:
> On 2/21/24 10:58, Eric Auger wrote:
>> Introduce a new enum type property allowing to set an
>> IOMMU granule. Values are 4K, 16K, 64K and host. This
>> latter indicates the vIOMMU granule will matches the
>&
701 - 800 of 4501 matches
Mail list logo
