Re: [PATCH 1/1] hw/arm/sbsa-ref: use XHCI to replace EHCI

[Chen Baozi]

Hi Leif,

> On Jun 1, 2023, at 00:36, Leif Lindholm <quic_llindhol@quicinc.com> wrote:
> 
> On 2023-05-31 16:27, Peter Maydell wrote:
>> On Wed, 31 May 2023 at 15:58, Graeme Gregory <graeme@xora.org.uk> wrote:
>>>> The current sbsa-ref cannot use EHCI controller which is only
>>>> able to do 32-bit DMA, since sbsa-ref doesn't have RAM above 4GB.
>>>> Hence, this uses XHCI to provide a usb controller with 64-bit
>>>> DMA capablity instead of EHCI.
>>> 
>>> Should this be below 4G?
>> It would be pretty disruptive to try to rearrange the memory
>> map to put RAM below 4GB at this point, though in theory it's
>> possible I guess. (I have a vague recollection that there was
>> some reason the RAM was all put above 4GB, but can't find
>> anything about that in my email archives. Perhaps Leif remembers?)
> 
> I think Graeme was just pointing out a typo in Marcin's email.
> 
> Yeah, we're not changing the DRAM base at this stage.
> I think the reason we put no RAM below 4GB was simply that we had several 
> real-world platforms where that was true, and given the intended use-case for 
> the platform, we explicitly wanted to trigger issues those platforms might 
> encounter.
> 
>>> Also has EHCI never worked, or has it worked in some modes and so this
>>> change should be versioned?
>> AIUI, EHCI has never worked and can never have worked, because
>> this board's RAM is all above 4G and the QEMU EHCI controller
>> implementation only allows DMA descriptors with 32-bit addresses.
>> Looking back at the archives, it seems we discussed XHCI vs
>> EHCI when the sbsa-ref board went in, and the conclusion was
>> that XHCI would be better. But there wasn't a sysbus XHCI device
>> at that point, so we ended up committing the sbsa-ref board
>> with EHCI and a plan to switch to XHCI when the sysbus-xhci
>> device was done, which we then forgot about:
>> https://mail.gnu.org/archive/html/qemu-arm/2018-11/msg00638.html
> 
> Ah, thanks! That explains why we did the thing that made no sense :)
> 
> To skip the migration hazard, my prefernece is we just leave the EHCI device 
> in for now, and add a separate XHCI on PCIe. We can drop the
> EHCI device at some point in the future.

What about introducing another SMMU for all the platform devices on sbsa-ref? I 
was thinking over this solution for some time. If that can be feasible, we then 
also have a prototype of IOMMU for platform device.

Regards,

Baozi.