Christoph Hellwig wrote:
On Tue, May 22, 2007 at 10:00:42AM -0700, ron minnich wrote:
On 5/22/07, Eric Van Hensbergen [EMAIL PROTECTED] wrote:
I'm not opposed to supporting emulation environments, just don't make
a large pile of crap the default like Xen -- and having to integrate
On Wed, May 23, 2007 at 03:16:50PM +0300, Avi Kivity wrote:
Christoph Hellwig wrote:
On Tue, May 22, 2007 at 10:00:42AM -0700, ron minnich wrote:
On 5/22/07, Eric Van Hensbergen [EMAIL PROTECTED] wrote:
I'm not opposed to supporting emulation environments, just don't make
a
On 5/23/07, Carsten Otte [EMAIL PROTECTED] wrote:
For me, plan9 does provide answers to a lot of above requirements.
However, it does not provide capabilities for shared memory and it
adds extra complexity. It's been designed to solve a different problem.
As a point of clarification, plan9
On Wednesday 23 May 2007, Eric Van Hensbergen wrote:
On 5/23/07, Carsten Otte [EMAIL PROTECTED] wrote:
For me, plan9 does provide answers to a lot of above requirements.
However, it does not provide capabilities for shared memory and it
adds extra complexity. It's been designed to solve a
On 5/23/07, Arnd Bergmann [EMAIL PROTECTED] wrote:
On Wednesday 23 May 2007, Eric Van Hensbergen wrote:
On 5/23/07, Carsten Otte [EMAIL PROTECTED] wrote:
For me, plan9 does provide answers to a lot of above requirements.
However, it does not provide capabilities for shared memory and
On 5/23/07, Eric Van Hensbergen [EMAIL PROTECTED] wrote:
On 5/23/07, Arnd Bergmann [EMAIL PROTECTED] wrote:
On Wednesday 23 May 2007, Eric Van Hensbergen wrote:
On 5/23/07, Carsten Otte [EMAIL PROTECTED] wrote:
For me, plan9 does provide answers to a lot of above requirements.
On Tue, May 22, 2007 at 07:49:51AM -0500, Eric Van Hensbergen wrote:
In the general case, you can't pass a command line argument to Linux
either. kvm doesn't boot Linux; it boots the bios, which boots the boot
sector, which boots grub, which boots Linux. Relying on the user to
edit the
Eric Van Hensbergen wrote:
On 5/22/07, Avi Kivity [EMAIL PROTECTED] wrote:
Anthony Liguori wrote:
In a PV environment why not just pass an initial cookie/hash/whatever
as a command-line argument/register/memory-space to the underlying
kernel?
You can't pass a command line argument
On 5/22/07, Anthony Liguori [EMAIL PROTECTED] wrote:
Eric Van Hensbergen wrote:
On 5/22/07, Christoph Hellwig [EMAIL PROTECTED] wrote:
I didn't think we were talking about the general case, I thought we
were discussing the PV case.
In case of KVM no one is speaking of pure PV.
On 5/22/07, Anthony Liguori [EMAIL PROTECTED] wrote:
Eric Van Hensbergen wrote:
On 5/22/07, Christoph Hellwig [EMAIL PROTECTED] wrote:
In case of KVM no one is speaking of pure PV.
Why not? It seems worthwhile to come up with something that can cover
the whole spectrum instead
On 5/22/07, Eric Van Hensbergen [EMAIL PROTECTED] wrote:
I'm not opposed to supporting emulation environments, just don't make
a large pile of crap the default like Xen -- and having to integrate
PCI probing code in my guest domains is a large pile of crap.
Exactly. I'm about to start a
On 5/22/07, Dor Laor [EMAIL PROTECTED] wrote:
Don't quit so soon on us.
OK. I'll go look at Ingo's stuff.
Thanks again
ron
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2
This is quite easy with KVM. I like the approach that vmchannel has
taken. A simple PCI device. That gives you a discovery mechanism for
shared memory and an interrupt and then you can just implement a ring
queue using those mechanisms (along with a PIO port for signaling from
the
On Mon, 21 May 2007 13:28:03 +0200,
Arnd Bergmann [EMAIL PROTECTED] wrote:
We've had the same discussion about PCI as virtual device abstraction
recently when hpa made the suggestions to get a set of PCI device
numbers registered for Linux.
(If you want to read it up, it's the thread at
On Monday 21 May 2007, Cornelia Huck wrote:
IRQ numbers are evil :)
yes, but getting rid of them is an entirely different discussion.
I really think that in the first step, you should be able to
use its external interrupts with the same request_irq interface
as the other architectures.
Arnd Bergmann wrote:
On Monday 21 May 2007, Christian Borntraeger wrote:
This is quite easy with KVM. I like the approach that vmchannel has
taken. A simple PCI device. That gives you a discovery mechanism for
shared memory and an interrupt and then you can just implement a ring
OK, so what are we doing here? We're using a PCI abstraction, as a
common abstraction,which is not common really, because we don't have a
common abstraction? So we describe all these non-pci resources with a
pci abstraction?
I don't get it at all. I really think the resource interface idea I
On 5/21/07, Anthony Liguori [EMAIL PROTECTED] wrote:
ron minnich wrote:
OK, so what are we doing here? We're using a PCI abstraction, as a
common abstraction,which is not common really, because we don't have a
common abstraction? So we describe all these non-pci resources with a
pci
ron minnich wrote:
On 5/21/07, Anthony Liguori [EMAIL PROTECTED] wrote:
No. You're confusing PV device discovery with the actual paravirtual
transport. In a fully virtual environment like KVM, a PCI bus is
present. You need some way for the guest to detect that a PV device is
present. The
Eric Van Hensbergen wrote:
On 5/21/07, Anthony Liguori [EMAIL PROTECTED] wrote:
ron minnich wrote:
OK, so what are we doing here? We're using a PCI abstraction, as a
common abstraction,which is not common really, because we don't have a
common abstraction? So we describe all these non-pci
ron minnich wrote:
Hi Anthony,
I still feel that how about a socket interface is still focused on
the how to implement, and not what the interface should be.
Right. I'm not trying to answer that question ATM. There are a number
of paravirt devices that would be useful in a virtual setting.
On 5/18/07, Anthony Liguori [EMAIL PROTECTED] wrote:
I also
am not sure the socket system call interface is quite what we want,
although it's a neat idea. It's also not that portable outside the
everything is a Linux variant world.
A filesystem interface certainly isn't very portable
Daniel P. Berrange wrote:
As a userspace apps service, I'd very much like to see a common sockets
interface for inter-VM communication that is portable across virt systems
like Xen KVM. I'd see it as similar to UNIX domain sockets in style. So
basically any app which could do UNIX domain
Carsten Otte wrote:
Daniel P. Berrange wrote:
As a userspace apps service, I'd very much like to see a common sockets
interface for inter-VM communication that is portable across virt systems
like Xen KVM. I'd see it as similar to UNIX domain sockets in style. So
basically any app
Rusty Russell wrote:
On Wed, 2007-05-16 at 14:10 -0500, Anthony Liguori wrote:
For the host, you can probably stay entirely within QEMU. Interguest
communication would be a bit tricky but guest-host communication is
real simple.
guest-host is always simple. But it'd be great if
On Thu, 2007-05-17 at 11:13 -0500, Anthony Liguori wrote:
Rusty Russell wrote:
I think shared memory is an obvious start, but it's not enough for
inter-guest where they can't freely access each other's memory. So you
really want a ring-buffer of descriptors with a hypervisor-assist to say
On 5/16/07, Anthony Liguori [EMAIL PROTECTED] wrote:
What do you think about a socket interface? I'm not sure how discovery
would work yet, but there are a few PV socket implementations for Xen at
the moment.
Hi Anthony,
I still feel that how about a socket interface is still focused on
the
On Wed, May 16, 2007 at 12:28:00PM -0500, Anthony Liguori wrote:
Eric Van Hensbergen wrote:
On 5/11/07, Anthony Liguori [EMAIL PROTECTED] wrote:
There's definitely a conversation to have here. There are going to be a
lot of small devices that would benefit from a common transport
On 5/16/07, Anthony Liguori [EMAIL PROTECTED] wrote:
What do you think about a socket interface? I'm not sure how discovery
would work yet, but there are a few PV socket implementations for Xen at
the moment.
From a functional standpoint I don't have a huge problem with it,
particularly if
On Wed, May 16, 2007 at 1:28 PM, in message [EMAIL PROTECTED],
Anthony Liguori [EMAIL PROTECTED] wrote:
What do you think about a socket interface? I'm not sure how discovery
would work yet, but there are a few PV socket implementations for Xen at
the moment.
FYI: The work I am doing
Gregory Haskins wrote:
On Wed, May 16, 2007 at 1:28 PM, in message [EMAIL PROTECTED],
Anthony Liguori [EMAIL PROTECTED] wrote:
What do you think about a socket interface? I'm not sure how discovery
would work yet, but there are a few PV socket implementations for Xen at
the
Eric Van Hensbergen wrote:
On 5/16/07, Anthony Liguori [EMAIL PROTECTED] wrote:
What do you think about a socket interface? I'm not sure how discovery
would work yet, but there are a few PV socket implementations for Xen at
the moment.
From a functional standpoint I don't have a huge
Gregory Haskins wrote:
On Wed, May 16, 2007 at 2:39 PM, in message [EMAIL PROTECTED],
Anthony Liguori [EMAIL PROTECTED] wrote:
Gregory Haskins wrote:
On Wed, May 16, 2007 at 1:28 PM, in message [EMAIL PROTECTED],
Anthony Liguori [EMAIL PROTECTED]
On Wed, 2007-05-16 at 14:10 -0500, Anthony Liguori wrote:
For the host, you can probably stay entirely within QEMU. Interguest
communication would be a bit tricky but guest-host communication is
real simple.
guest-host is always simple. But it'd be great if it didn't matter to
the guest
On Monday 14 May 2007 14:05, Avi Kivity wrote:
But I agree that the growing code base is a problem. With the block
driver we can probably keep the host side in userspace, but to do the
same for networking is much more work. I do think (now) that it is doable.
Interesting. What kind of
Avi Kivity wrote:
But I agree that the growing code base is a problem. With the block
driver we can probably keep the host side in userspace, but to do the
same for networking is much more work. I do think (now) that it is doable.
I agree that networking needs to be handled in the host
ron minnich wrote:
Let me ask what may seem to be a naive question to the linux world. I
see you are doing a lot off solid work on adding block and network
devices. The code for block and network devices
is implemented in different ways. I've also seen this difference of
Dor Laor wrote:
push it into the kernel are:
a. We should perform much better
b. It would be a painful task getting all the code review that a
complicated network interface should get.
c. There's already a PV driver that answers a,b.
The Xen's PV network driver is
Subject: Re: [kvm-devel] [PATCH/RFC 7/9] Virtual network guest device
driver
Dor Laor wrote:
push it into the kernel are:
a. We should perform much better
b. It would be a painful task getting all the code review that a
complicated network interface should get.
c
Dor Laor wrote:
Furthermore,
the plan is to completely rearchitect the netback/netfront protocol for
the next Xen release (this effort is referred to netchannel2).
But isn't Jeremy Fitzhardinge is pushing big patch queue into the
kernel?
Yes, but it's not in the kernel yet and
On Sun, May 13, 2007 at 11:49:14AM -0500, Anthony Liguori wrote:
Dor Laor wrote:
Furthermore,
the plan is to completely rearchitect the netback/netfront
protocol for the next Xen release (this effort is referred to
netchannel2).
But isn't Jeremy Fitzhardinge is pushing big
Subject: Re: [kvm-devel] [PATCH/RFC 7/9] Virtual network guest device
driver
On Sun, May 13, 2007 at 11:49:14AM -0500, Anthony Liguori wrote:
Dor Laor wrote:
Furthermore,
the plan is to completely rearchitect the netback/netfront
protocol for the next Xen release (this effort is referred
On Sun, 2007-05-13 at 11:49 -0500, Anthony Liguori wrote:
Dor Laor wrote:
Furthermore,
the plan is to completely rearchitect the netback/netfront protocol for
the next Xen release (this effort is referred to netchannel2).
It's looks like generalizing all the level 0,1,2 features plus
ron minnich wrote:
Let me ask what may seem to be a naive question to the linux world. I
see you are doing a lot off solid work on adding block and network
devices. The code for block and network devices
is implemented in different ways. I've also seen this difference of
Let me ask what may seem to be a naive question to the linux world. I
see you are doing a lot off solid work on adding block and network
devices. The code for block and network devices
is implemented in different ways. I've also seen this difference of
inerface/implementation on Xen.
Hence my
ron minnich wrote:
Avoiding too much detail, in the plan 9 world, read and write of data
to a disk is via file read and write system calls.
For low speed devices, I think paravirtualization doesn't make a lot of
sense unless it's absolutely required. I don't know enough about s390
to know if
Eric Van Hensbergen wrote:
On 5/11/07, Anthony Liguori [EMAIL PROTECTED] wrote:
cpu% ls /net/ether0
/net/ether0/0
/net/ether0/1
/net/ether0/2
/net/ether0/addr
/net/ether0/clone
/net/ether0/ifstats
/net/ether0/stats
This smells a bit like XenStore which I think most will
47 matches
Mail list logo
