From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: "Julien Grall" <julien@xen.org>,
"Stewart Hildebrand" <stewart.hildebrand@amd.com>,
"Oleksandr Andrushchenko" <Oleksandr_Andrushchenko@epam.com>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"George Dunlap" <george.dunlap@citrix.com>,
"Jan Beulich" <jbeulich@suse.com>, "Wei Liu" <wl@xen.org>,
"Roger Pau Monné" <roger.pau@citrix.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v10 13/17] vpci: add initial support for virtual PCI bus topology
Date: Fri, 17 Nov 2023 14:09:45 +0000 [thread overview]
Message-ID: <87a5rc4gk7.fsf@epam.com> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2311161651090.773207@ubuntu-linux-20-04-desktop>
Hi Stefano,
Stefano Stabellini <sstabellini@kernel.org> writes:
> On Fri, 17 Nov 2023, Volodymyr Babchuk wrote:
>> > I still think, no matter the BDF allocation scheme, that we should try
>> > to avoid as much as possible to have two different PCI Root Complex
>> > emulators. Ideally we would have only one PCI Root Complex emulated by
>> > Xen. Having 2 PCI Root Complexes both of them emulated by Xen would be
>> > tolerable but not ideal.
>>
>> But what is exactly wrong with this setup?
>
> [...]
>
>> > The worst case I would like to avoid is to have
>> > two PCI Root Complexes, one emulated by Xen and one emulated by QEMU.
>>
>> This is how our setup works right now.
>
> If we have:
> - a single PCI Root Complex emulated in Xen
> - Xen is safety certified
> - individual Virtio devices emulated by QEMU with grants for memory
>
> We can go very far in terms of being able to use Virtio in safety
> use-cases. We might even be able to use Virtio (frontends) in a SafeOS.
>
> On the other hand if we put an additional Root Complex in QEMU:
> - we pay a price in terms of complexity of the codebase
> - we pay a price in terms of resource utilization
> - we have one additional problem in terms of using this setup with a
> SafeOS (one more device emulated by a non-safe component)
>
> Having 2 PCI Root Complexes both emulated in Xen is a middle ground
> solution because:
> - we still pay a price in terms of resource utilization
> - the code complexity goes up a bit but hopefully not by much
> - there is no impact on safety compared to the ideal scenario
>
> This is why I wrote that it is tolerable.
Ah, I see now. Yes, I am agree with this. Also I want to add some more
points:
- There is ongoing work on implementing virtio backends as a separate
applications, written in Rust. Linaro are doing this part. Right now
they are implementing only virtio-mmio, but if they want to provide
virtio-pci as well, they will need a mechanism to plug only
virtio-pci, without Root Complex. This is argument for using single Root
Complex emulated in Xen.
- As far as I know (actually, Oleksandr told this to me), QEMU has no
mechanism for exposing virtio-pci backends without exposing PCI root
complex as well. Architecturally, there should be a PCI bus to which
virtio-pci devices are connected. Or we need to make some changes to
QEMU internals to be able to create virtio-pci backends that are not
connected to any bus. Also, added benefit that PCI Root Complex
emulator in QEMU handles legacy PCI interrupts for us. This is
argument for separate Root Complex for QEMU.
As right now we have only virtio-pci backends provided by QEMU and this
setup is already working, I propose to stick to this
solution. Especially, taking into account that it does not require any
changes to hypervisor code.
--
WBR, Volodymyr
next prev parent reply other threads:[~2023-11-17 14:10 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-12 22:09 [PATCH v10 00/17] PCI devices passthrough on Arm, part 3 Volodymyr Babchuk
2023-10-12 22:09 ` [PATCH v10 01/17] pci: msi: pass pdev to pci_enable_msi() function Volodymyr Babchuk
2023-10-30 15:55 ` Jan Beulich
2023-11-17 13:59 ` Roger Pau Monné
2023-10-12 22:09 ` [PATCH v10 03/17] vpci: use per-domain PCI lock to protect vpci structure Volodymyr Babchuk
2023-11-03 15:39 ` Stewart Hildebrand
2023-11-17 15:16 ` Roger Pau Monné
2023-11-28 22:24 ` Volodymyr Babchuk
2023-10-12 22:09 ` [PATCH v10 05/17] vpci: add hooks for PCI device assign/de-assign Volodymyr Babchuk
2023-11-20 15:04 ` Roger Pau Monné
2023-10-12 22:09 ` [PATCH v10 04/17] vpci: restrict unhandled read/write operations for guests Volodymyr Babchuk
2023-10-12 22:09 ` [PATCH v10 02/17] pci: introduce per-domain PCI rwlock Volodymyr Babchuk
2023-11-17 14:33 ` Roger Pau Monné
2023-10-12 22:09 ` [PATCH v10 06/17] vpci/header: rework exit path in init_bars Volodymyr Babchuk
2023-11-20 15:07 ` Roger Pau Monné
2023-10-12 22:09 ` [PATCH v10 08/17] rangeset: add RANGESETF_no_print flag Volodymyr Babchuk
2023-10-12 22:09 ` [PATCH v10 07/17] vpci/header: implement guest BAR register handlers Volodymyr Babchuk
2023-10-14 16:00 ` Stewart Hildebrand
2023-11-20 16:06 ` Roger Pau Monné
2023-10-12 22:09 ` [PATCH v10 11/17] vpci/header: program p2m with guest BAR view Volodymyr Babchuk
2023-11-21 12:24 ` Roger Pau Monné
2023-10-12 22:09 ` [PATCH v10 10/17] vpci/header: handle p2m range sets per BAR Volodymyr Babchuk
2023-11-20 17:29 ` Roger Pau Monné
2023-10-12 22:09 ` [PATCH v10 09/17] rangeset: add rangeset_empty() function Volodymyr Babchuk
2023-10-13 17:54 ` Stewart Hildebrand
2023-10-13 18:08 ` Volodymyr Babchuk
2023-10-12 22:09 ` [PATCH v10 12/17] vpci/header: emulate PCI_COMMAND register for guests Volodymyr Babchuk
2023-10-13 21:53 ` Volodymyr Babchuk
2023-11-21 14:17 ` Roger Pau Monné
2023-12-01 2:05 ` Volodymyr Babchuk
2023-12-01 9:04 ` Roger Pau Monné
2023-12-21 22:58 ` Stewart Hildebrand
2023-10-12 22:09 ` [PATCH v10 13/17] vpci: add initial support for virtual PCI bus topology Volodymyr Babchuk
2023-11-16 16:06 ` Julien Grall
2023-11-16 23:28 ` Stefano Stabellini
2023-11-17 0:06 ` Julien Grall
2023-11-17 0:51 ` Stefano Stabellini
2023-11-17 0:21 ` Volodymyr Babchuk
2023-11-17 0:58 ` Stefano Stabellini
2023-11-17 14:09 ` Volodymyr Babchuk [this message]
2023-11-17 18:30 ` Julien Grall
2023-11-17 20:08 ` Volodymyr Babchuk
2023-11-17 21:43 ` Stefano Stabellini
2023-11-17 22:22 ` Volodymyr Babchuk
2023-11-18 0:45 ` Stefano Stabellini
2023-11-21 0:42 ` Volodymyr Babchuk
2023-11-22 1:12 ` Stefano Stabellini
2023-11-22 11:53 ` Roger Pau Monné
2023-11-22 21:18 ` Stefano Stabellini
2023-11-23 8:29 ` Roger Pau Monné
2023-11-28 23:45 ` Volodymyr Babchuk
2023-11-29 8:33 ` Roger Pau Monné
2023-11-30 2:28 ` Stefano Stabellini
2023-11-21 14:40 ` Roger Pau Monné
2023-10-12 22:09 ` [PATCH v10 14/17] xen/arm: translate virtual PCI bus topology for guests Volodymyr Babchuk
2023-11-21 15:11 ` Roger Pau Monné
2023-10-12 22:09 ` [PATCH v10 15/17] xen/arm: account IO handlers for emulated PCI MSI-X Volodymyr Babchuk
2023-10-13 8:34 ` Julien Grall
2023-10-13 13:06 ` Volodymyr Babchuk
2023-10-13 16:46 ` Julien Grall
2023-10-13 17:17 ` Volodymyr Babchuk
2023-10-12 22:09 ` [PATCH v10 16/17] xen/arm: vpci: permit access to guest vpci space Volodymyr Babchuk
2023-10-16 11:00 ` Jan Beulich
2023-10-24 19:44 ` Stewart Hildebrand
2023-10-12 22:09 ` [PATCH v10 17/17] arm/vpci: honor access size when returning an error Volodymyr Babchuk
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=87a5rc4gk7.fsf@epam.com \
--to=volodymyr_babchuk@epam.com \
--cc=Oleksandr_Andrushchenko@epam.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=stewart.hildebrand@amd.com \
--cc=wl@xen.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.