From: Srivatsa Vaddagiri <quic_svaddagi@quicinc.com>
To: Alex Benn?e <alex.bennee@linaro.org>
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: Tue, 17 Oct 2023 14:51:52 +0530 [thread overview]
Message-ID: <20231017092152.GA689217@quicinc.com> (raw)
In-Reply-To: <87ttqvnazo.fsf@linaro.org>
* Alex Benn?e <alex.bennee@linaro.org> [2023-10-12 15:55:59]:
> > 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?
I checked usage of few KVM APIs in virtio-pci.c. I think most of them are to do
with use of MSI and IRQFD. If lets say we are not supporting MSI, then I *think*
current virtio-pci should work just fine. It would use virtio_pci_notify ->
pci_set_irq -> .. -> qemu_set_irq, which should land in
gunyah_arm_gicv3_set_irq [Patch 7/12] AFAICT. Let me try getting virtio-pci
working and then I can update this thread again!
- vatsa
next prev parent reply other threads:[~2023-10-17 9:22 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
2023-10-17 9:21 ` Srivatsa Vaddagiri [this message]
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=20231017092152.GA689217@quicinc.com \
--to=quic_svaddagi@quicinc.com \
--cc=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_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.