Re: QEMU features useful for Xen development?

[Peter Maydell <peter.maydell@xxxxxxxxxx>]

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/
>
> > 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