[RFC] 2-stage translation emulation support for SMMUv3 on TCG

[RFC] 2-stage translation emulation support for SMMUv3 on TCG

[Evgeny Iakovlev]

Hi!


We are using qemu-tcg-aarch64 to run Hyper-V test and debug builds for 
arm. Besides some minor fixes that i have submitted over the last couple 
of weeks, one big compatibility item for us is SMMUv3 2-stage 
translations support. We can do fine without it right now, but having it 
would also allow us to test nested arm guests with SMMUv3, which is great.


One idea we have floating around is implementing 2-stage translations in 
SMMUv3 in Qemu. We can't make a commitment yet, but before we consider 
it i think it would be wise to ask the community about it, specifically:

* Do 2-stage translations sound like something qemu-arm would be keen on 
accepting? Are there any other use-cases for it besides an arguably wild 
corner case of nesting an EL2 hypervisor on software-emulated arm64?

* Is there anyone already working on it as we speak maybe?

* Were there any previous attempts to do this and if yes why they 
evidently didn't get through?


Thanks!

Re: [RFC] 2-stage translation emulation support for SMMUv3 on TCG

[Eric Auger]

Hi Evgeny,
On 1/16/23 16:37, Evgeny Iakovlev wrote:
> Hi!
>
>
> We are using qemu-tcg-aarch64 to run Hyper-V test and debug builds for
> arm. Besides some minor fixes that i have submitted over the last
> couple of weeks, one big compatibility item for us is SMMUv3 2-stage
> translations support. We can do fine without it right now, but having
> it would also allow us to test nested arm guests with SMMUv3, which is
> great.
>
>
> One idea we have floating around is implementing 2-stage translations
> in SMMUv3 in Qemu. We can't make a commitment yet, but before we
> consider it i think it would be wise to ask the community about it,
> specifically:
>
> * Do 2-stage translations sound like something qemu-arm would be keen
> on accepting? Are there any other use-cases for it besides an arguably
> wild corner case of nesting an EL2 hypervisor on software-emulated arm64?
Personally I don't have anything against. I guess we cannot prevent you
from adding a feature that is supported by the spec ;-) One concern I
have is the extra complexity it will bring to the device. At least I
would recommend you to try to isolate stage2 support at most from the
rest and make your utmost to keep the stage1 perf as close as possible
to what it is currently. Indeed the main "production" use case is S1
vSMMU with KVM acceleration. Currently in linux arm-smmuv3 driver, only
S1 is used. Out of curiosity how are the S2 and S1+S2 used with HyperV?

I am mostly involved in KVM accelerated use cases so I will let others
comment on potential use cases using S2.
>
> * Is there anyone already working on it as we speak maybe?
afaik I am not aware of anybody working on that at the moment
>
> * Were there any previous attempts to do this and if yes why they
> evidently didn't get through?
afaik there were no series sent publicly

Thanks

Eric
>
>
> Thanks!
>
>

Re: [RFC] 2-stage translation emulation support for SMMUv3 on TCG

[Evgeny Iakovlev]

On 1/17/2023 18:00, Eric Auger wrote:
> Hi Evgeny,
> On 1/16/23 16:37, Evgeny Iakovlev wrote:
>> Hi!
>>
>>
>> We are using qemu-tcg-aarch64 to run Hyper-V test and debug builds for
>> arm. Besides some minor fixes that i have submitted over the last
>> couple of weeks, one big compatibility item for us is SMMUv3 2-stage
>> translations support. We can do fine without it right now, but having
>> it would also allow us to test nested arm guests with SMMUv3, which is
>> great.
>>
>>
>> One idea we have floating around is implementing 2-stage translations
>> in SMMUv3 in Qemu. We can't make a commitment yet, but before we
>> consider it i think it would be wise to ask the community about it,
>> specifically:
>>
>> * Do 2-stage translations sound like something qemu-arm would be keen
>> on accepting? Are there any other use-cases for it besides an arguably
>> wild corner case of nesting an EL2 hypervisor on software-emulated arm64?
> Personally I don't have anything against. I guess we cannot prevent you
> from adding a feature that is supported by the spec ;-) One concern I
> have is the extra complexity it will bring to the device. At least I
> would recommend you to try to isolate stage2 support at most from the
> rest and make your utmost to keep the stage1 perf as close as possible
> to what it is currently. Indeed the main "production" use case is S1
> vSMMU with KVM acceleration. Currently in linux arm-smmuv3 driver, only
> S1 is used. Out of curiosity how are the S2 and S1+S2 used with HyperV?
>
> I am mostly involved in KVM accelerated use cases so I will let others
> comment on potential use cases using S2.


Hyper-V is using 2-stage xlate i think in the same scenario KVM/vfio 
does: to expose SMMU to the guest and allow it to program stage 1 tables 
and also support some nesting scenarious.


>> * Is there anyone already working on it as we speak maybe?
> afaik I am not aware of anybody working on that at the moment
>> * Were there any previous attempts to do this and if yes why they
>> evidently didn't get through?
> afaik there were no series sent publicly


Thanks for confirming, Eric!


>
> Thanks
>
> Eric
>>
>> Thanks!
>>
>>

Re: [RFC] 2-stage translation emulation support for SMMUv3 on TCG

[Richard Henderson]

On 1/16/23 05:37, Evgeny Iakovlev wrote:
> Hi!
> 
> 
> We are using qemu-tcg-aarch64 to run Hyper-V test and debug builds for arm. Besides some 
> minor fixes that i have submitted over the last couple of weeks, one big compatibility 
> item for us is SMMUv3 2-stage translations support. We can do fine without it right now, 
> but having it would also allow us to test nested arm guests with SMMUv3, which is great.
> 
> One idea we have floating around is implementing 2-stage translations in SMMUv3 in Qemu. 
> We can't make a commitment yet, but before we consider it i think it would be wise to ask 
> the community about it, specifically:
> 
> * Do 2-stage translations sound like something qemu-arm would be keen on accepting? Are 
> there any other use-cases for it besides an arguably wild corner case of nesting an EL2 
> hypervisor on software-emulated arm64?

I've recently been looking at the requirements for the full ARM Confidential Computing 
Architecture stack, outside of the core cpu architecture extension just posted.

While it appears as if Hyp (and therefore stage2) is not explicitly required, it certainly 
looks like the Realm Management Monitor should be using it (since the guest OS running 
underneath in Realm EL1 is not necessarily trusted), and I would be surprised if real 
hardware lacks any of this support.

I would be delighted to review any patches for missing smmu features, and coordinate 
filling in all of SMMUv3.3 plus RME.


r~