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 r
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 shar
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
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, p
Carsten Otte wrote:
> I have been closely following thisvery interresting discussion. Here's
> my summary:
> - PV capabilities is something we'll want
> - being able to surface virtual devices to the guest as PCI is
> preferable to Windows
> - we need an additional way to surface virtual devices
Nakajima, Jun wrote:
> BTW, I'm presenting this at OLS:
> http://www.linuxsymposium.org/2007/view_abstract.php?content_key=192
>
> This uses direct paging mode today.
>
Are there patches available anywhere?
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
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
>> PCI probing code in my guest domains is a large pile of crap.
>>
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, j
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
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.
>>
>
> Why not? It seems worthwhile to come
I have been closely following thisvery interresting discussion. Here's
my summary:
- PV capabilities is something we'll want
- being able to surface virtual devices to the guest as PCI is
preferable to Windows
- we need an additional way to surface virtual devices to the guest.
We don't have PCI
Dor Laor wrote:
> > > If you don't care about full virtualization kvm is the wrong
project for
> > > you. You might want to take a look at lguest.
> >
> > Ah, I had not realized that KVM was purely a full-virt environment
> > with no real use for PV-only users. I'll move on. Thanks for the
tip!
>
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 DB
>> If you don't care about full virtualization kvm is the wrong project
for
>> you. You might want to take a look at lguest.
>
>Ah, I had not realized that KVM was purely a full-virt environment
>with no real use for PV-only users. I'll move on. Thanks for the tip!
>ron
Don't quit so soon on us.
On 5/22/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> If you don't care about full virtualization kvm is the wrong project for
> you. You might want to take a look at lguest.
Ah, I had not realized that KVM was purely a full-virt environment
with no real use for PV-only users. I'll move on.
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
> >PCI probing code in my gue
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 p
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
>
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
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.
>>
>>
>
> Why not? It seems worth
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.
>
Why not? It seems worthwhile to come up with something that can cover
the w
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
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
> > edi
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 to Wind
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 to Windows (at least, not easily
> AFAIK). You could get away with
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 t
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
> >
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
>> pre
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
> >
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 abstraction?
>
No. You're confusing PV device discovery
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
menti
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
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.
Fundam
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
h
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
> > queue using those
Anthony Liguori <[EMAIL PROTECTED]> wrote on 17.05.2007 16:22:23:
> Is there anything that explains what the fields in sockaddr mean:
>
> sa_family_tsiucv_family;
> unsigned shortsiucv_port;/* Reserved */
> unsigned intsiucv_addr;/* Reserved */
> char
On Mon, 21 May 2007 11:07:07 +0200,
Christian Borntraeger <[EMAIL PROTECTED]> 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 implem
> 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 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 v
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
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 o
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 t
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'
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 a
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 doma
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 gues
On 5/16/07, Anthony Liguori <[EMAIL PROTECTED]> wrote:
> Eric Van Hensbergen wrote:
> >
> > From a functional standpoint I don't have a huge problem with it,
> > particularly if its more of a pure socket and not something that tries
> > to look like a TCP/IP endpoint -- I would prefer something clo
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]>,
>>
>>
>>> 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]> wrote:
>>
>>> What do you thin
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 ha
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
>>> 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
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,
particula
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 tran
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
>> mechanism. Someone mentioned a PV entropy device on LKML. A
>> h
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 kern
Christian Bornträger wrote:
> 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 d
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 user
ron minnich wrote:
> We had hoped to get something like this into Xen. On Xen, for example,
> the block device and ethernet device interfaces are as different as
> one could imagine. Disk I/O does not steal pages from the guest. The
> network does. Disk I/O is in 4k chunks, period, with a bitmap
>
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 patch queue
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 f
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
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 Fitzhar
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 ker
>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
>>
>>
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 dri
>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
>> inerface/im
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
> inerface/impleme
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
> mechanism. Someone mentioned a PV entropy device on LKML. A
> host=>guest filesystem is another c
On 5/11/07, Anthony Liguori <[EMAIL PROTECTED]> wrote:
> 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 it supports things like uarts but if so, then emulating a
> uart would in my mind m
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 Xe
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 agree was an
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 i
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 ques
From: Christian Borntraeger <[EMAIL PROTECTED]>
This is a work-in- progress paravirtualized network driver for Linux systems
running under a hypervisor.
The basic idea of this network driver is to have a shared memory pool between
host and guest. The guest allocates the buffer and registers its me
75 matches
Mail list logo
