Re: QEMU features useful for Xen development?

[Ayan Kumar Halder <ayankuma@xxxxxxx>]

Hi Peter/Alex,

Appreciate your help. :)

On 31/08/2023 11:03, Peter Maydell wrote:
> CAUTION: This message has originated from an External Source. Please use proper 
> judgment and caution when opening attachments, clicking links, or responding to 
> this email.
>
>
> On Thu, 31 Aug 2023 at 10:53, Alex Bennée <alex.bennee@xxxxxxxxxx> wrote:
> > Peter Maydell <peter.maydell@xxxxxxxxxx> writes:
> >
> > > On Thu, 31 Aug 2023 at 01:57, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
> > > > As Xen is gaining R52 and R82 support, it would be great to be able to
> > > > use QEMU for development and testing there as well, but I don't think
> > > > QEMU can emulate EL2 properly for the Cortex-R architecture. We would
> > > > need EL2 support in the GIC/timer for R52/R82 as well.
> > > We do actually have a Cortex-R52 model which at least in theory
> > > should include EL2 support, though as usual with newer QEMU
> > > stuff it quite likely has lurking bugs; I'm not sure how much
> > > testing it's had. Also there is currently no board model which
> > > will work with the Cortex-R52 so it's a bit tricky to use in practice.
> > > (What sort of board model would Xen want to use it with?)
> > We already model a bunch of the mps2/mps3 images so I'm assuming adding
> > the mps3-an536 would be a fairly simple step to do (mps2tz.c is mostly
> > tweaking config values). The question is would it be a useful target for
> > Xen?
> All our MPS2/MPS3 boards are M-profile. That means we have the
> device models for all the interesting devices on the board, but
> it would be simpler to write the an536 board model separately.
> (In particular, the M-profile boards are wrappers around an
> "ARMSSE" sort-of-like-an-SoC component; there's no equivalent
> for the Cortex-R52.)
>
> >    https://developer.arm.com/documentation/dai0536/latest/
Yes, it will be helpful if Qemu can model this board. We have a 
downstream port of Xen on R52 (upstreaming is in progress).
So, we can test the Qemu model with Xen.

Also if all works fine, we might consider adding this to the upstream 
Xen CI docker.
Out of curiosity, are you planning to add Qemu R52 SoC support to Zephyr ?

- Ayan

> > > The Cortex-R82 would be more work, because (unlike the R52) it's
> > > AArch64, and we don't have Armv8-R AArch64 support yet, only the AArch32.
> > >
> > > I haven't looked at whether GIC on R-profile requires any changes
> > > from the A-profile GIC; on A-profile obviously we emulate the
> > > virtualization support already.
> > >
> > > > On Cortex-As, in addition to a PCI root complex and an arbitrary PCI
> > > > device, SMMUv3 emulation (both stages) and GICv3 ITS are needed to be
> > > > able to test PCI Passthrough.
> > We have ITS emulation support and it was recently plumbed into the
> > "sbsa-ref" board as it is needed for higher level SBSA compliance.
> >
> > > > However, if I recall correctly SMMUv3
> > > > emulation in QEMU might not be complete enough to enable us to use it.
> > > Yeah, at the moment the SMMU emulation supports stage 1 and stage 2,
> > > but not both at the same time. This is good enough for PCI passthrough
> > > with a Linux guest using KVM to pass a device through to a nested
> > > Linux guest.
> > Is this a missing feature for SMMUv3 or something introduced in the
> > later revisions?
> It's a missing feature. The SMMUv3 spec allows an implementation
> to implement stage 1, stage 2 or both. We started with just a
> stage-1-only implementation because Linux doesn't need any more.
> Stage-2-only just landed recently. Nobody's looked at both-stages yet.
>
> thanks
> -- PMM