From: Rusty Russell <rusty@rustcorp.com.au>
To: Ira Snyder <iws@ovro.caltech.edu>
Cc: David Miller <davem@davemloft.net>,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
shemminger@vyatta.com, arnd@arndb.de, netdev@vger.kernel.org
Subject: Re: [PATCH RFC v5] net: add PCINet driver
Date: Tue, 13 Jan 2009 13:02:52 +1030 [thread overview]
Message-ID: <200901131302.52754.rusty@rustcorp.com.au> (raw)
In-Reply-To: <20090108215127.GA28935@ovro.caltech.edu>
On Friday 09 January 2009 08:21:27 Ira Snyder wrote:
> Rusty, since you wrote the virtio code, can you point me at the things I
> would need to implement to use virtio over the PCI bus.
>
> The guests (PowerPC computers running Linux) are PCI cards in the host
> system (an Intel Pentium3-M system). The guest computers can access all
> of the host's memory. The guests provide a 1MB (movable) window into
> their memory.
>
> The PowerPC computers also have a DMA controller, which I've used to get
> better throughput from my driver. I have a way to create interrupts to
> both the host and guest systems.
>
> I've read your paper titled: "virtio: Towards a De-Facto Standard For
> Virtual I/O Devices"
>
> If I read that correctly, then I should implement all of the functions
> in struct virtqueue_ops appropriately, and the existing virtio drivers
> should just work. The only concern I have there is how to make guest ->
> host transfer use the DMA controller. I've done all programming of it
> from the guest kernel, using the Linux DMAEngine API.
Hi Ira,
Interesting system: the guest being able to access the host's memory but not (fully) vice-versa makes this a little different from the current implementations where that was assumed. virtio assumes that the guest will publish buffers and someone else (ie. the host) will access them.
> Are there any other implementations other than virtio_ring?
There were some earlier implementations, but they were trivial. And not particularly helpful in your case.
In summary, yes, it should work quite nicely, but rather than publishing the buffers to the host, the host will need to tell the guest where it wants them transferred (possibly using that 1M window, and a notification mechanism). That will be the complex part I think.
Cheers,
Rusty.
next prev parent reply other threads:[~2009-01-13 2:33 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-07 19:50 [PATCH RFC v5] net: add PCINet driver Ira Snyder
2009-01-08 19:16 ` David Miller
2009-01-08 19:27 ` Ira Snyder
2009-01-08 21:51 ` Ira Snyder
2009-01-10 23:32 ` Benjamin Herrenschmidt
2009-01-12 17:56 ` Arnd Bergmann
2009-01-13 2:32 ` Rusty Russell [this message]
2009-01-13 3:34 ` Ira Snyder
2009-01-13 16:33 ` Arnd Bergmann
2009-01-13 16:40 ` Ira Snyder
2009-01-13 17:42 ` Arnd Bergmann
2009-01-15 0:12 ` Ira Snyder
2009-01-15 12:58 ` Arnd Bergmann
2009-01-15 16:54 ` Ira Snyder
2009-01-15 17:53 ` Arnd Bergmann
2009-01-15 18:20 ` Ira Snyder
2009-01-15 20:57 ` Arnd Bergmann
2009-01-15 23:27 ` Ira Snyder
2009-01-15 19:21 ` Ira Snyder
2009-01-15 21:22 ` Arnd Bergmann
2009-01-15 21:40 ` Ira Snyder
2009-01-15 22:53 ` Arnd Bergmann
2009-01-15 23:31 ` Ira Snyder
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=200901131302.52754.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=arnd@arndb.de \
--cc=davem@davemloft.net \
--cc=iws@ovro.caltech.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox