From: pawel.moll@arm.com (Pawel Moll)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 0/2] Memory mapped virtio device
Date: Fri, 2 Sep 2011 13:24:15 +0100 [thread overview]
Message-ID: <1314966257-7503-1-git-send-email-pawel.moll@arm.com> (raw)
Hi All,
This is a proposal of a memory mapped virtio device.
The main goal was to provide an equivalent of the virtio PCI device,
happily used by KVM an qemu on x86, which could be used by PCI-less
platforms (common in ARM world). The interface exposed by my device
is very similar to the original virtio_pci one, maybe just a little
bit simplified (no sophisticated IRQ infrastructure here). Of course
all the control registers live in memory space, instead of PCI IO
space (writel vs iowrite32).
This raises an obvious question whether these two implementation
could share some common code. Probably some constant values could
be shared (like VIRTIO_*_HOST_FEATURES or VIRTIO_*_VRING_ALIGN),
maybe struct virtio_*_vq_info as well. On the other hand the vring
interface itself is an abstraction layer already... I really don't
know, all comments and ideas appreciated.
The second thing is AMBAness of the driver... I've decided to
make it an AMBA device rather than simple platform device to add
at least a touch of "dicoverability". The idea was simple - one
can add "permanent" virtio AMBA device in the kernel placing it
somewhere in reserved area of real hardware, so the kernel running
on hardware will not get correct amba_id value and ignore the
device. With the eve of Device-Trees-Everywhere this argument is
slightly out of date, as qemu could add the virtio device even in
runtime. So maybe I should convert it into a platform_device then?
This brings additional problem though. Magnus Damm already proposed
a platform virtio device here:
http://thread.gmane.org/gmane.linux.ports.sh.devel/11554
however it's something completely different, as his use case is a
heterogeneous system and the virtio is used mainly as a transport
between nodes. It also uses lguest-based interface, which is much
less applicable to the qemu reality.
The second patch simply makes it possible to use virtio framework
on ARM.
Let me just add that Peter Maydell (Linaro qemu magician) kindly
agreed to work on the qemu side of the problem once we have some
consensus regarding the interface.
Pawel Moll (2):
virtio: Add AMBA bus driver for virtio device
arm: Add VIRTUALIZATION configuration menu and virtio options
arch/arm/Kconfig | 16 ++
drivers/virtio/Kconfig | 11 +
drivers/virtio/Makefile | 1 +
drivers/virtio/virtio_amba.c | 443 ++++++++++++++++++++++++++++++++++++++++++
include/linux/virtio_amba.h | 62 ++++++
5 files changed, 533 insertions(+), 0 deletions(-)
create mode 100644 drivers/virtio/virtio_amba.c
create mode 100644 include/linux/virtio_amba.h
next reply other threads:[~2011-09-02 12:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-02 12:24 Pawel Moll [this message]
[not found] ` <1314966257-7503-2-git-send-email-pawel.moll@arm.com>
2011-09-12 1:31 ` [RFC 1/2] virtio: Add AMBA bus driver for virtio device Rusty Russell
2011-09-12 16:45 ` Pawel Moll
[not found] ` <1315846301-13892-1-git-send-email-pawel.moll@arm.com>
2011-09-12 17:27 ` [RFC v2] arm: Add platform " Anthony Liguori
2011-09-13 8:58 ` Pawel Moll
2011-09-13 2:58 ` [RFC 1/2] virtio: Add AMBA " Rusty Russell
2011-09-13 9:40 ` Pawel Moll
2011-09-14 0:18 ` Rusty Russell
2011-09-14 16:47 ` Pawel Moll
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=1314966257-7503-1-git-send-email-pawel.moll@arm.com \
--to=pawel.moll@arm.com \
--cc=linux-arm-kernel@lists.infradead.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).