[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 00/15] vfio: VFIO migration support with vIOMMU
From: |
Joao Martins |
Subject: |
Re: [PATCH v4 00/15] vfio: VFIO migration support with vIOMMU |
Date: |
Thu, 7 Sep 2023 16:20:03 +0100 |
On 07/09/2023 13:40, Cédric Le Goater wrote:
> Hello Joao,
>
>> Cedric, you mentioned that you take a look at this after you come back, not
>> sure
>> if that's still the plan. But it's been a while since the last version, so
>> would
>> you have me repost/rebase on the latest (post your PR)?
>
> Yes please. That's next on the TODO list (after some downstream work
> regarding the postcopy crash). My rough plan for 8.2 is :
>
> * P2P
> * VIOMMU
> * dynamic MSI-X
> * fixes
>
Thanks for sharing
> I think it is a bit early for iommufd and I will probably lack time.
> The recent migration addition is requiring some attention in many
> areas.
>
>> Additionally, I should say that I have an alternative (as a single small
>> patch),
>> where vIOMMU usage is allowed ... but behind a VFIO command line option, and
>> as
>> soon as attempt *any* vIOMMU mapping we fail-to-start/block the migration. I
>> haven't posted that alternative as early in the dirty tracking work the idea
>> was
>> to avoid guest vIOMMU usage dependency to allow migration (which made this
>> patchset the way it is). But thought it was OK to remind, if it was only be
>> allowed if the admin explicitly states such its intent behind a x- command
>> line
>> option.
>
> I don't remember seeing it. It is worth resending as an RFC so that
> people can comment.
I haven't send it, largelly because in the first versions of dirty tracking the
situation revolved around whether or not we depend on guest vIOMMU usage
(passthrough or not) vs tracking something agnostic to guest (raw IOVA ranges).
In any case I can send out the patch and move the discussion there whether it's
a good idea or not (it's a simple patch)
Joao