From: "Alex Bennée" <alex.bennee@linaro.org>
To: Srivatsa Vaddagiri <quic_svaddagi@quicinc.com>
Cc: Philippe Mathieu-Daud? <philmd@linaro.org>,
peter.maydell@linaro.org, qemu-devel@nongnu.org,
qemu-arm@nongnu.org, quic_tsoni@quicinc.com,
quic_pheragu@quicinc.com, quic_eberman@quicinc.com,
quic_yvasi@quicinc.com, quic_cvanscha@quicinc.com,
quic_mnalajal@quicinc.com, Brian Cain <bcain@quicinc.com>,
Mark Burton <mburton@qti.qualcomm.com>
Subject: Re: [RFC/PATCH v0 12/12] gunyah: Documentation
Date: Thu, 12 Oct 2023 15:55:59 +0100 [thread overview]
Message-ID: <87ttqvnazo.fsf@linaro.org> (raw)
In-Reply-To: <20231012123338.GF1130358@quicinc.com>
Srivatsa Vaddagiri <quic_svaddagi@quicinc.com> writes:
> * Philippe Mathieu-Daud? <philmd@linaro.org> [2023-10-12 06:52:04]:
>
>> > +Limitations
>> > +-----------
>> > +
>> > +Below features are not yet supported.
>> > +
>> > +* virtio-pci (support for which in Qemu seems to rely heavily on KVM, which
>> > + needs to be made multi-hypervisor friendly).
>>
>> Is QUIC interested in working on that? My work introducing
>> AccelCPUState to make CPUState accel-agnostic was done in that
>> direction, but I didn't notice much interest in the community
>> so I unprioritized it.
>
> Hi Phil,
> We do want to see Gunyah support merged in Qemu at the earliest (as soon
> as the kernel driver is merged upstream that is), so any dependent change in
> Qemu for Gunyah would be of much interest to us! I am not sure though if Quic
> can sign up for the entire "make cpustate accel agnostic" work. Can you point
> to your ongoing work that I could take a look at? Would that address virtio-pci
> becoming accelerator agnostic?
Why wouldn't virtio-pci be accelerator agnostic?
It works with KVM and TCG for example. There are I suppose complications
if you want to share emulated devices with a real PCI bus rather than
emulating it all within QEMU.
>
> Thanks!
> vatsa
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
next prev parent reply other threads:[~2023-10-12 14:58 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-11 16:52 [RFC/PATCH v0 00/12] Gunyah hypervisor support Srivatsa Vaddagiri
2023-10-11 16:52 ` [RFC/PATCH v0 01/12] hw/arm/virt: Avoid NULL pointer de-reference Srivatsa Vaddagiri
2023-10-12 4:30 ` Philippe Mathieu-Daudé
2023-10-12 5:02 ` Markus Armbruster
2023-10-12 12:24 ` Srivatsa Vaddagiri
2023-10-11 16:52 ` [RFC/PATCH v0 02/12] update-linux-headers: Include gunyah.h Srivatsa Vaddagiri
2023-10-11 16:57 ` Srivatsa Vaddagiri
2023-11-29 16:44 ` Alex Bennée
2023-12-01 10:35 ` Srivatsa Vaddagiri
2023-10-11 16:52 ` [RFC/PATCH v0 03/12] gunyah: Basic support Srivatsa Vaddagiri
2023-10-12 4:33 ` Philippe Mathieu-Daudé
2023-10-12 11:32 ` Alex Bennée
2023-10-12 12:24 ` Srivatsa Vaddagiri
2023-11-29 16:56 ` Alex Bennée
2023-12-01 10:33 ` Srivatsa Vaddagiri
2023-10-11 16:52 ` [RFC/PATCH v0 04/12] gunyah: Add VM properties Srivatsa Vaddagiri
2023-10-11 16:52 ` [RFC/PATCH v0 05/12] gunyah: Support memory assignment Srivatsa Vaddagiri
2023-10-11 16:52 ` [RFC/PATCH v0 06/12] gunyah: Add IRQFD and IOEVENTFD functions Srivatsa Vaddagiri
2023-10-11 16:52 ` [RFC/PATCH v0 07/12] gunyah: Add gicv3 interrupt controller Srivatsa Vaddagiri
2023-10-11 16:52 ` [RFC/PATCH v0 08/12] gunyah: Specific device-tree location Srivatsa Vaddagiri
2023-10-12 4:35 ` Philippe Mathieu-Daudé
2023-10-11 16:52 ` [RFC/PATCH v0 09/12] gunyah: Customize device-tree Srivatsa Vaddagiri
2023-10-12 4:36 ` Philippe Mathieu-Daudé
2023-10-11 16:52 ` [RFC/PATCH v0 10/12] gunyah: CPU execution loop Srivatsa Vaddagiri
2023-10-12 4:43 ` Philippe Mathieu-Daudé
2023-10-12 12:25 ` Srivatsa Vaddagiri
2023-10-11 16:52 ` [RFC/PATCH v0 11/12] gunyah: Workarounds (NOT FOR MERGE) Srivatsa Vaddagiri
2023-10-11 16:52 ` [RFC/PATCH v0 12/12] gunyah: Documentation Srivatsa Vaddagiri
2023-10-12 4:52 ` Philippe Mathieu-Daudé
2023-10-12 12:33 ` Srivatsa Vaddagiri
2023-10-12 14:55 ` Alex Bennée [this message]
2023-10-17 9:21 ` Srivatsa Vaddagiri
2023-10-18 15:54 ` Alex Bennée
2023-10-18 16:40 ` [RFC/PATCH v0 00/12] Gunyah hypervisor support Paolo Bonzini
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=87ttqvnazo.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=bcain@quicinc.com \
--cc=mburton@qti.qualcomm.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=quic_cvanscha@quicinc.com \
--cc=quic_eberman@quicinc.com \
--cc=quic_mnalajal@quicinc.com \
--cc=quic_pheragu@quicinc.com \
--cc=quic_svaddagi@quicinc.com \
--cc=quic_tsoni@quicinc.com \
--cc=quic_yvasi@quicinc.com \
/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.