qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: 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>
Cc: 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: QEMU features useful for Xen development?
Date: Wed, 30 Aug 2023 17:11:02 +0100	[thread overview]
Message-ID: <87y1hspiyh.fsf@linaro.org> (raw)


Dear Xen community,

Linaro is significantly invested in QEMU development, with a special
focus on Arm-related aspects. We recognize the value of QEMU as a
readily available software reference platform for projects that need to
test their software well before the availability of real hardware.

The primary focus of our effort is on adding core architectural elements
to the CPU emulation. For an overview of the current feature set, please
see:

  https://qemu.readthedocs.io/en/master/system/arm/emulation.html

Besides the -cpu max, providing an approximation of a v9.0 baseline CPU,
we have also recently added several specific CPU types like the
Neoverse-N1 and V1 processor types as well as numerous Cortex CPU
models.

Our most utilized machine model is "virt", which is primarily designed
for guest operation and therefore has minimal resemblance to actual
hardware. "sbsa-ref" was implemented to more closely simulate a real
machine that aligns with Arm's SBSA specification.

In our work on VirtIO, we often use QEMU. Most of our rust-vmm
vhost-device backends, for instance, were initially tested on QEMU.

Now that everyone is up-to-date, I would welcome any feedback from the
Xen community on features that would increase QEMU's usefulness as a
development target.

Do you have interest in any upcoming Arm CPU features? For example, we
recently added FEAT_RME support for Arm's new confidential computing,
but currently do not implement FEAT_NV/NV2.

How about the HW emulation in QEMU? Is the PCI emulation reliable enough
to ensure confidence while testing changes to Xen's PCI management? What
about the few peripherals that the hypervisor accesses directly?

Are there other development features you consider essential? Have you
noticed any limitations with gdbstub? Does anyone use the record/replay
or reverse debug functions? Has anyone tried TCG plugins for analysing
the behavior of the hypervisor?

While I cannot promise to implement every wish-list item (performance
counter emulation, for example, as we are not a uArch simulator), I am
eager to gather feedback on how QEMU could be improved to help the Xen
community deliver it's roadmap faster.

Thank you for your time and I look forward to any feedback :-)

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro


             reply	other threads:[~2023-08-30 16:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-30 16:11 Alex Bennée [this message]
2023-08-31  0:56 ` QEMU features useful for Xen development? Stefano Stabellini
2023-08-31  9:02   ` Peter Maydell
2023-08-31  9:37     ` Alex Bennée
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=87y1hspiyh.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=qemu-devel@nongnu.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).