From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>, Andi Kleen <ak@suse.de>,
Christian Borntraeger <borntrae@de.ibm.com>,
virtualization@lists.linux-foundation.org,
"H. Peter Anvin" <hpa@zytor.com>,
Virtualization Mailing List <virtualization@lists.osdl.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
mathiasen@gmail.com
Subject: Re: A set of "standard" virtual devices?
Date: Tue, 03 Apr 2007 12:55:15 -0700 [thread overview]
Message-ID: <4612B123.2040105@goop.org> (raw)
In-Reply-To: <200704032142.51976.arnd@arndb.de>
Arnd Bergmann wrote:
> We already have device drivers for physical devices that can be attached
> to different buses. The EHCI USB is an example of a driver that can
> be for instance PCI, OF or an on-chip device. Moreover, you can have an
> abstracted device behind it that does not need to know about the transport,
> like the SCSI disk driver does not care if it is talking to an ATA,
> parallel SCSI or SAS chip, or even which controller that is.
>
Yes, that kind of layering is useful when there's enough of an
abstraction gap to fit the layers into. USB is particularly simple in
that way, since it can be made to travel nicely over any number of
transports.
> console is also the least problematic interface, you can do it over
> practically anything.
>
Sure. But its interesting that there are savings to be had.
> Doing a SCSI driver has been tried before, with ibmvscsi. Not good.
>
OK, interesting. People had proposed using SCSI as the interface, but I
wasn't aware of any results from doing that. How is it not good?
> The interesting question about block devices is how to handle concurrency
> and interrupt mitigation. An efficient interface should
>
> - have asynchronous notification, not sleep until the transfer is complete
> - allow multiple blocks to be in flight simultaneously, so the host can
> reorder the requests if it is smart enough
> - give only a single interrupt when multiple transfers have completed
>
Yes. The Xen block interface is already pretty efficient in these respects.
>> I'm not sure what similar common code could be extracted for network
>> devices. I haven't looked into it all that closely.
>>
>
> One way to do networking would be to simply provide a shared memory area
> that everyone can write to, then use a ring buffer and atomic operations
> to synchronize between the guests, and a method to send interrupts to the
> others for flow control.
>
Yes, and that's the core of the Xen netfront. But is there really much
code which can be shared between different hypervisors? When you get
down to it, all the real code is hypervisor-specific stuff for setting
up ringbuffers and dealing with interrupts. Like all the other network
drivers.
J
next prev parent reply other threads:[~2007-04-03 19:55 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4611652F.700@zytor.com>
2007-04-02 20:56 ` A set of "standard" virtual devices? Jeremy Fitzhardinge
2007-04-02 21:12 ` Andi Kleen
2007-04-02 21:33 ` Jeff Garzik
2007-04-02 21:36 ` Andi Kleen
2007-04-02 21:42 ` Jeremy Fitzhardinge
2007-04-02 21:53 ` Anthony Liguori
2007-04-02 22:04 ` Jeremy Fitzhardinge
2007-04-02 22:10 ` H. Peter Anvin
2007-04-02 22:25 ` Jeff Garzik
2007-04-02 22:30 ` H. Peter Anvin
2007-04-03 9:41 ` Arnd Bergmann
2007-04-03 10:41 ` Cornelia Huck
2007-04-03 12:15 ` Arnd Bergmann
2007-04-03 13:39 ` Cornelia Huck
2007-04-03 14:03 ` Arnd Bergmann
2007-04-03 16:07 ` Cornelia Huck
2007-04-03 8:29 ` Christian Borntraeger
2007-04-03 8:30 ` Andi Kleen
2007-04-03 9:17 ` Cornelia Huck
2007-04-03 9:26 ` Andi Kleen
2007-04-03 10:51 ` Cornelia Huck
2007-04-03 15:00 ` Adrian Bunk
2007-04-03 17:50 ` Arnd Bergmann
2007-04-03 19:07 ` Jeremy Fitzhardinge
2007-04-03 19:42 ` Arnd Bergmann
2007-04-03 19:55 ` Jeremy Fitzhardinge [this message]
2007-04-03 20:03 ` H. Peter Anvin
2007-04-03 21:00 ` Jeremy Fitzhardinge
2007-04-03 21:45 ` H. Peter Anvin
2007-04-03 21:51 ` Arnd Bergmann
2007-04-03 22:10 ` H. Peter Anvin
2007-04-03 22:49 ` Arnd Bergmann
2007-04-04 0:52 ` H. Peter Anvin
2007-04-04 13:11 ` Arnd Bergmann
2007-04-04 15:50 ` H. Peter Anvin
2007-04-03 20:50 ` Arnd Bergmann
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=4612B123.2040105@goop.org \
--to=jeremy@goop.org \
--cc=ak@suse.de \
--cc=arnd@arndb.de \
--cc=borntrae@de.ibm.com \
--cc=cornelia.huck@de.ibm.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathiasen@gmail.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=virtualization@lists.osdl.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).