qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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


  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).