From: "Alex Bennée" <alex.bennee@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
Xen-devel <xen-devel@lists.xenproject.org>,
Stewart Hildebrand <stewart.hildebrand@amd.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
Sergiy Kibrik <Sergiy_Kibrik@epam.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Vikram Garhwal <vikram.garhwal@amd.com>,
Stefano Stabellini <stefano.stabellini@amd.com>,
Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>,
Jonathan Cameron <jonathan.cameron@huawei.com>
Subject: Re: QEMU features useful for Xen development?
Date: Thu, 31 Aug 2023 10:37:45 +0100 [thread overview]
Message-ID: <87cyz3pmgz.fsf@linaro.org> (raw)
In-Reply-To: <CAFEAcA8Ziov9vA9dW+4vzFE=KkSUqfMNNMZOtvQhqCXyjRytzQ@mail.gmail.com>
Peter Maydell <peter.maydell@linaro.org> writes:
> On Thu, 31 Aug 2023 at 01:57, Stefano Stabellini <sstabellini@kernel.org> 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?
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?
We have sketched out the tasks for SMMUv3.2
(https://linaro.atlassian.net/browse/QEMU-558) with a view to whats
needed for RME guests to access hardware. However I think there is a lot
of other stuff needed specifically for RME including what we do about
modelling things like TDISP. Realistically it will be awhile before we
get to completing all of that.
>
> thanks
> -- PMM
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
next prev parent reply other threads:[~2023-08-31 9:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-30 16:11 QEMU features useful for Xen development? Alex Bennée
2023-08-31 0:56 ` Stefano Stabellini
2023-08-31 9:02 ` Peter Maydell
2023-08-31 9:37 ` Alex Bennée [this message]
2023-08-31 10:03 ` Peter Maydell
2023-08-31 10:27 ` Alex Bennée
2023-08-31 11:42 ` Peter Maydell
2023-08-31 10:32 ` Ayan Kumar Halder
2023-09-05 9:55 ` Alex Bennée
2023-10-20 15:15 ` Alex Bennée
2023-10-20 18:15 ` Ayan Kumar Halder
2024-02-19 11:50 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87cyz3pmgz.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=Sergiy_Kibrik@epam.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=jonathan.cameron@huawei.com \
--cc=marcin.juszkiewicz@linaro.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=sstabellini@kernel.org \
--cc=stefano.stabellini@amd.com \
--cc=stewart.hildebrand@amd.com \
--cc=vikram.garhwal@amd.com \
--cc=viresh.kumar@linaro.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.