On 4/17/25 6:19 AM, Sairaj Kodilkar wrote:
On 4/17/2025 3:47 AM, Alejandro Jimenez wrote:
On 4/16/25 8:14 AM, Sairaj Kodilkar wrote:
+
+ /* DMA address translation */
+ bool dma_remap;
I think you should use this flag in the remapping path as well.
I am aware that you are using it later in this series to switch the
address space, but current patch will make things inconsistent for
emulated and vfio devices (possibly breaking the bisect).
The change in behavior happens only if the user explicitly sets dma-
remap=on property in the command line, which is why I made it off by
default.
To eliminate the possibility of using dma-remap=on before all the
infrastructure to support it is in place, I will move this patch and
[5/18] to the end of the series. Does that address your concern?
Yep, That works for me. Its always better to introduce flags at the end
of the series when we have the infrastructure ready !
Also, is it a good idea to have default value for dma_remap=false ?
Consider the guest which is not aware of HATDis bit. Things will
break if such guest boots with iommu.passthrough=0 (recreating the pt=on
scenario).
That is not new, that is the current behavior that this series is
trying to fix by adding the missing functionality.
As far as the default value for dma-remap property, I think it must be
set to 0/false (i.e. current behavior unchanged) until we deem the DMA
remapping feature stable enough to be made available for guests.
On that topic, maybe it should be an experimental feature for now i.e.
"x-dma-remap".
But the current behaviour for the emulated (virtio devices) is to have
dma-remapping on by default... I still think its better to have this
flag = on.
Honestly, I am confused here...
The dma-remap property is meant to be the global on/off switch that
controls whether any/all the code changes in this series have any
effect. It is off by default, so the new code doesn't run and behavior
stays the same.
This example case you mention:
> guest boots with iommu.passthrough=0
is already broken today if you are using the AMD vIOMMU with VFIO
devices. We cannot stop guests from doing invalid things if they choose
to do so. Following up from what you said above:
> Its always better to introduce flags at the end
> of the series when we have the infrastructure ready !
and we only enable new features by default once we have sufficiently
verified them, otherwise we risk regressions when launching guests that
have not changed their configuration (i.e. explicitly opted in to the
new feature) but are now running the new code/feature.
Perhaps I missed a different scenario that you are warning about, in
which case please expand...
Alejandro
Regards
Sairaj Kodilkar
