...@redhat.com
Acked-by: Gregory Haskins ghask...@novell.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
on my part to _comment_ why if there was such a reason). So, short of
recalling what that reason was, and the fact that Michael's theory seems
rational and legit...
Acked-by: Gregory Haskins ghask...@novell.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
If the issue is real
gsi: triggering a
srorm of interrupts in guest is likely useless anyway, and we can do it
by binding a single gsi to many interrupts if we really want to.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Seems reasonable to me.
Acked-by: Gregory Haskins ghask...@novell.com
---
This patch
On 12/27/09 4:15 AM, Avi Kivity wrote:
On 12/23/2009 11:21 PM, Gregory Haskins wrote:
That said, you are still incorrect. With what I proposed, the model
will run as an in-kernel vbus device, and no longer run in userspace.
It would therefore improve virtio-net as I stated, much in the same
On 12/27/09 4:33 AM, Avi Kivity wrote:
On 12/24/2009 11:36 AM, Gregory Haskins wrote:
As a twist on this, the VMware paravirt driver interface is so
hardware-like that they're getting hardware vendors to supply cards that
implement it. Try that with a pure software approach.
Any
On 12/27/09 8:27 AM, Avi Kivity wrote:
On 12/27/2009 03:18 PM, Gregory Haskins wrote:
On 12/27/09 4:15 AM, Avi Kivity wrote:
On 12/23/2009 11:21 PM, Gregory Haskins wrote:
That said, you are still incorrect. With what I proposed, the model
will run as an in-kernel vbus device
On 12/27/09 8:49 AM, Avi Kivity wrote:
On 12/27/2009 03:34 PM, Gregory Haskins wrote:
On 12/27/09 4:33 AM, Avi Kivity wrote:
On 12/24/2009 11:36 AM, Gregory Haskins wrote:
As a twist on this, the VMware paravirt driver interface is so
hardware-like that they're getting hardware
On 12/27/09 8:49 AM, Avi Kivity wrote:
On 12/27/2009 03:39 PM, Gregory Haskins wrote:
No, where we are is at the point where we demonstrate that your original
statement that I did nothing to improve virtio was wrong.
I stand by it. virtio + your patch does nothing without a ton more
On 12/23/09 3:36 PM, Avi Kivity wrote:
On 12/23/2009 06:44 PM, Gregory Haskins wrote:
- Are a pure software concept
By design. In fact, I would describe it as software to software
optimized as opposed to trying to shoehorn into something that was
designed as a software-to-hardware
On 12/23/09 4:01 PM, Avi Kivity wrote:
On 12/23/2009 10:36 PM, Avi Kivity wrote:
On 12/23/2009 06:44 PM, Gregory Haskins wrote:
- Are a pure software concept
By design. In fact, I would describe it as software to software
optimized as opposed to trying to shoehorn into something
On 12/23/09 1:51 AM, Ingo Molnar wrote:
* Anthony Liguori anth...@codemonkey.ws wrote:
On 12/22/2009 10:01 AM, Bartlomiej Zolnierkiewicz wrote:
new e1000 driver is more superior in architecture and do the required
work to make the new e1000 driver a full replacement for the old one.
On 12/23/09 12:10 PM, Andi Kleen wrote:
And its moot, anyway, as I have already retracted my one outstanding
pull request based on Linus' observation. So at this time, I am not
advocating _anything_ for upstream inclusion. And I am contemplating
_never_ doing so again. It's not worth
On 12/23/09 1:15 AM, Kyle Moffett wrote:
On Tue, Dec 22, 2009 at 12:36, Gregory Haskins
gregory.hask...@gmail.com wrote:
On 12/22/09 2:57 AM, Ingo Molnar wrote:
* Gregory Haskins gregory.hask...@gmail.com wrote:
Actually, these patches have nothing to do with the KVM folks. [...]
That claim
On 12/23/09 5:22 AM, Avi Kivity wrote:
There was no attempt by Gregory to improve virtio-net.
If you truly do not understand why your statement is utterly wrong at
this point in the discussion, I feel sorry for you. If you are trying
to be purposely disingenuous, you should be ashamed of
On 12/23/09 12:52 PM, Peter W. Morreale wrote:
On Wed, 2009-12-23 at 13:14 +0100, Andi Kleen wrote:
http://www.redhat.com/f/pdf/summit/cwright_11_open_source_virt.pdf
See slide 32. This is without vhost-net.
Thanks. Do you also have latency numbers?
It seems like there's definitely still
On 12/23/09, Avi Kivity a...@redhat.com wrote:
On 12/23/2009 08:15 PM, Gregory Haskins wrote:
On 12/23/09 5:22 AM, Avi Kivity wrote:
There was no attempt by Gregory to improve virtio-net.
If you truly do not understand why your statement is utterly wrong at
this point in the discussion, I feel
On 12/22/09 1:53 PM, Avi Kivity wrote:
On 12/22/2009 07:36 PM, Gregory Haskins wrote:
Gregory, it would be nice if you worked _much_ harder with the KVM folks
before giving up.
I think the 5+ months that I politely tried to convince the KVM folks
that this was a good idea was pretty
On 12/22/09 1:53 PM, Avi Kivity wrote:
I asked why the irqfd/ioeventfd mechanisms are insufficient, and you did not
reply.
BTW: the ioeventfd issue just fell through the cracks, so sorry about
that. Note that I have no specific issue with irqfd ever since the
lockless IRQ injection code was
On 12/22/09 2:32 PM, Gregory Haskins wrote:
On 12/22/09 2:25 PM, Avi Kivity wrote:
If you're not doing something pretty minor, you're better of waking up a
thread (perhaps _sync if you want to keep on the same cpu). With the
new user return notifier thingie, that's pretty cheap.
We have
On 12/22/09 2:38 PM, Avi Kivity wrote:
On 12/22/2009 09:32 PM, Gregory Haskins wrote:
xinterface, as it turns out, is a great KVM interface for me and easy to
extend, all without conflicting with the changes in upstream. The old
way was via the kvm ioctl interface, but that sucked as the ABI
On 12/22/09 2:43 PM, Avi Kivity wrote:
On 12/22/2009 09:41 PM, Gregory Haskins wrote:
It means that kvm locking suddenly affects more of the kernel.
Thats ok. This would only be w.r.t. devices that are bound to the KVM
instance anyway, so they better know what they are doing
On 12/22/09 2:39 PM, Davide Libenzi wrote:
On Tue, 22 Dec 2009, Gregory Haskins wrote:
On 12/22/09 1:53 PM, Avi Kivity wrote:
I asked why the irqfd/ioeventfd mechanisms are insufficient, and you did
not reply.
BTW: the ioeventfd issue just fell through the cracks, so sorry about
On 12/21/09 7:12 PM, Anthony Liguori wrote:
On 12/21/2009 11:44 AM, Gregory Haskins wrote:
Well, surely something like SR-IOV is moving in that direction, no?
Not really, but that's a different discussion.
Ok, but my general point still stands. At some level, some crafty
hardware
On 12/18/09 4:51 PM, Ingo Molnar wrote:
* Gregory Haskins gregory.hask...@gmail.com wrote:
Hi Linus,
Please pull AlacrityVM guest support for 2.6.33 from:
git://git.kernel.org/pub/scm/linux/kernel/git/ghaskins/alacrityvm/linux-2.6.git
for-linus
All of these patches have stewed
On 12/21/09 10:43 AM, Avi Kivity wrote:
On 12/21/2009 05:34 PM, Gregory Haskins wrote:
I think it would be fair to point out that these patches have been
objected to
by the KVM folks quite extensively,
Actually, these patches have nothing to do with the KVM folks. You are
perhaps
On 12/21/09 11:37 AM, Anthony Liguori wrote:
On 12/21/2009 10:04 AM, Gregory Haskins wrote:
No, B and C definitely are, but A is lacking. And the performance
suffers as a result in my testing (vhost-net still throws a ton of exits
as its limited by virtio-pci and only adds about 1Gb/s
On 12/21/09 11:40 AM, Avi Kivity wrote:
On 12/21/2009 06:37 PM, Anthony Liguori wrote:
Since virtio-pci supports MSI-X, there should be no IO exits on
host-guest notification other than EOI in the virtual APIC. This is
a light weight exit today and will likely disappear entirely with
newer
On 12/21/09 12:05 PM, Avi Kivity wrote:
On 12/21/2009 06:56 PM, Gregory Haskins wrote:
I'm working on disappearing EOI exits on older hardware as well. Same
idea as the old TPR patching, without most of the magic.
While I applaud any engineering effort that results in more optimal
On 12/21/09 12:20 PM, Anthony Liguori wrote:
On 12/21/2009 10:46 AM, Gregory Haskins wrote:
The very best you can hope to achieve is 1:1 EOI per signal (though
today virtio-pci is even worse than that). As I indicated above, I can
eliminate more than 50% of even the EOIs in trivial examples
We (the AlacrityVM team) are pleased to announce the availability of the
v0.2 release. There are numerous tweaks, fixes, and features that we
have added since the v0.1 days. Here are a few of the key highlights.
*) VENET support:
*) zero-copy transmits (guest memory is paged directly to the
Michael S. Tsirkin wrote:
Ok, I think I've addressed all comments so far here.
Rusty, I'd like this to go into linux-next, through your tree, and
hopefully 2.6.33. What do you think?
I think the benchmark data is a prerequisite for merge consideration, IMO.
Do you have anything for us to
Michael S. Tsirkin wrote:
On Wed, Nov 04, 2009 at 09:25:42AM -0800, Paul E. McKenney wrote:
(Sorry, but, as always, I could not resist!)
Thanx, Paul
Thanks Paul!
Jonathan: are you reading this?
Another one for your quotes of the week
Michael S. Tsirkin wrote:
On Wed, Nov 04, 2009 at 11:02:15AM -0500, Gregory Haskins wrote:
Michael S. Tsirkin wrote:
Ok, I think I've addressed all comments so far here.
Rusty, I'd like this to go into linux-next, through your tree, and
hopefully 2.6.33. What do you think?
I think
Gregory Haskins wrote:
Eric Dumazet wrote:
Michael S. Tsirkin a écrit :
+static void handle_tx(struct vhost_net *net)
+{
+ struct vhost_virtqueue *vq = net-dev.vqs[VHOST_NET_VQ_TX];
+ unsigned head, out, in, s;
+ struct msghdr msg = {
+ .msg_name = NULL
Michael S. Tsirkin wrote:
vhost net module wants to do copy to/from user from a kernel thread,
which needs use_mm. Export it to modules.
Acked-by: Andrea Arcangeli aarca...@redhat.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
I need this too:
Acked-by: Gregory Haskins ghask
Eric Dumazet wrote:
Michael S. Tsirkin a écrit :
+static void handle_tx(struct vhost_net *net)
+{
+struct vhost_virtqueue *vq = net-dev.vqs[VHOST_NET_VQ_TX];
+unsigned head, out, in, s;
+struct msghdr msg = {
+.msg_name = NULL,
+.msg_namelen = 0,
+
Eric Dumazet wrote:
Gregory Haskins a écrit :
Gregory Haskins wrote:
Eric Dumazet wrote:
Michael S. Tsirkin a écrit :
using rcu_dereference() and mutex_lock() at the same time seems wrong, I
suspect
that your use of RCU is not correct.
1) rcu_dereference() should be done inside
Avi Kivity wrote:
On 10/26/2009 05:38 PM, Gregory Haskins wrote:
Instead of a lockless attribute, how about a -set_atomic() method.
For
msi this can be the same as -set(), for non-msi it can be a function
that schedules the work (which will eventually call -set()).
The benefit is that we
Michael S. Tsirkin wrote:
On Tue, Oct 27, 2009 at 02:54:40PM -0400, Gregory Haskins wrote:
Michael S. Tsirkin wrote:
On Mon, Oct 26, 2009 at 12:22:08PM -0400, Gregory Haskins wrote:
IRQFD currently uses a deferred workqueue item to execute the injection
operation. It was originally designed
Michael S. Tsirkin wrote:
On Mon, Oct 26, 2009 at 12:22:03PM -0400, Gregory Haskins wrote:
Certain GSI's support lockless injecton, but we have no way to detect
which ones at the GSI level. Knowledge of this attribute will be
useful later in the series so that we can optimize irqfd injection
Avi Kivity wrote:
On 10/28/2009 03:19 PM, Gregory Haskins wrote:
Yes, and it also contains the work_struct.
What if we make the work_struct (and any additional state) part of the
set_atomic() argument list? Does it simplify things?
Hmmm, that might not, but we could do a kmalloc
Hi Paul,
Paul E. McKenney wrote:
On Mon, Oct 26, 2009 at 12:21:57PM -0400, Gregory Haskins wrote:
The current code suffers from the following race condition:
thread-1thread-2
---
kvm_set_irq
Gleb Natapov wrote:
On Mon, Oct 26, 2009 at 12:21:57PM -0400, Gregory Haskins wrote:
The current code suffers from the following race condition:
thread-1thread-2
---
kvm_set_irq() {
rcu_read_lock
Gregory Haskins wrote:
Gleb Natapov wrote:
On Mon, Oct 26, 2009 at 12:21:57PM -0400, Gregory Haskins wrote:
The current code suffers from the following race condition:
thread-1thread-2
Gleb Natapov wrote:
On Tue, Oct 27, 2009 at 09:39:03AM -0400, Gregory Haskins wrote:
Gleb Natapov wrote:
On Mon, Oct 26, 2009 at 12:21:57PM -0400, Gregory Haskins wrote:
The current code suffers from the following race condition:
thread-1thread-2
Gleb Natapov wrote:
On Tue, Oct 27, 2009 at 10:00:15AM -0400, Gregory Haskins wrote:
Gregory Haskins wrote:
Gleb Natapov wrote:
On Mon, Oct 26, 2009 at 12:21:57PM -0400, Gregory Haskins wrote:
The current code suffers from the following race condition:
thread-1
Thanks for this, Paul.
Some questions and statements below.
Paul E. McKenney wrote:
On Tue, Oct 27, 2009 at 04:02:37PM +0200, Gleb Natapov wrote:
On Tue, Oct 27, 2009 at 09:39:03AM -0400, Gregory Haskins wrote:
[ . . . ]
standard RCU RSCS, which is what SRCU is designed for. So rather
Gleb Natapov wrote:
On Tue, Oct 27, 2009 at 10:50:45AM -0400, Gregory Haskins wrote:
Gleb Natapov wrote:
On Tue, Oct 27, 2009 at 10:00:15AM -0400, Gregory Haskins wrote:
Gregory Haskins wrote:
Gleb Natapov wrote:
On Mon, Oct 26, 2009 at 12:21:57PM -0400, Gregory Haskins wrote:
The current
Gleb Natapov wrote:
1) rcu_read_lock is something like 4x faster than srcu_read_lock(), but
we are talking about nanoseconds on modern hardware (I think Paul quoted
me 10ns vs 45ns on his rig). I don't think either overhead is something
to be concerned about in this case.
If we can avoid
Michael S. Tsirkin wrote:
On Mon, Oct 26, 2009 at 12:22:08PM -0400, Gregory Haskins wrote:
IRQFD currently uses a deferred workqueue item to execute the injection
operation. It was originally designed this way because kvm_set_irq()
required the caller to hold the irq_lock mutex
Avi Kivity wrote:
On 10/23/2009 04:38 AM, Gregory Haskins wrote:
Certain GSI's support lockless injecton, but we have no way to detect
which ones at the GSI level. Knowledge of this attribute will be
useful later in the series so that we can optimize irqfd injection
paths for cases where we
Gregory Haskins wrote:
Avi Kivity wrote:
On 10/23/2009 04:38 AM, Gregory Haskins wrote:
Certain GSI's support lockless injecton, but we have no way to detect
which ones at the GSI level. Knowledge of this attribute will be
useful later in the series so that we can optimize irqfd injection
at registration whether the GSI supports lockless
operation and dynamically adapt to either the original
deferred path for lock-based injections, or direct for lockless.
v1:
*) original release
]
---
Gregory Haskins (3):
KVM: Directly inject interrupts if they support lockless
GSIs) readily support
lockless injection.
Signed-off-by: Gregory Haskins ghask...@novell.com
---
virt/kvm/eventfd.c | 31 +++
1 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 30f70fd..e6cc958 100644
--- a/virt
use to fix this bug:
1) Switch to sleeping-rcu and encompass the -set() access within the
read-side critical section,
OR
2) Add reference counting to the irq_rt structure, and simply acquire
the reference from within the RSCS.
This patch implements solution (1).
Signed-off-by: Gregory
a specific GSI.
Signed-off-by: Gregory Haskins ghask...@novell.com
---
include/linux/kvm_host.h |2 ++
virt/kvm/irq_comm.c | 35 ++-
2 files changed, 36 insertions(+), 1 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index
Avi Kivity wrote:
On 10/21/2009 05:42 PM, Gregory Haskins wrote:
I believe Avi, Michael, et. al. were in agreement with me on that design
choice. I believe the reason is that there is no good way to do EOI/ACK
feedback within the constraints of an eventfd pipe which would be
required
Avi Kivity wrote:
On 10/22/2009 05:14 PM, Gregory Haskins wrote:
Yeah, I was thinking about that after I initially responded to Gleb.
I am thinking something along these lines:
Provide a function that lets you query a GSI for whether it supports
LOCKLESS or not. Then we can either do one
at registration whether the GSI supports lockless
operation and dynamically adapt to either the original
deferred path for lock-based injections, or direct for lockless.
v1:
*) original release
]
---
Gregory Haskins (2):
KVM: Directly inject interrupts if they support
a specific GSI.
Signed-off-by: Gregory Haskins ghask...@novell.com
---
include/linux/kvm_host.h |2 ++
virt/kvm/irq_comm.c | 19 +++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index bd5a616..93393a4
GSIs) readily support
lockless injection.
Signed-off-by: Gregory Haskins ghask...@novell.com
---
virt/kvm/eventfd.c | 31 +++
1 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 30f70fd..e6cc958 100644
--- a/virt
Gregory Haskins wrote:
Certain GSI's support lockless injecton, but we have no way to detect
which ones at the GSI level. Knowledge of this attribute will be
useful later in the series so that we can optimize irqfd injection
paths for cases where we know the code will not sleep. Therefore
. They are an enhancement only, so there is no urgency
to push to mainline until a suitable merge window presents itself.
Kind Regards,
-Greg
---
Gregory Haskins (2):
KVM: Remove unecessary irqfd-cleanup-wq
KVM: Directly inject interrupts via irqfd
virt/kvm/eventfd.c | 45
of lockless injection support in kvm_set_irq, the deferment
mechanism is no longer technically needed. Since context switching to the
workqueue is a source of interrupt latency, lets switch to a direct
method.
Signed-off-by: Gregory Haskins ghask...@novell.com
---
virt/kvm/eventfd.c | 15
a deadlock if we tried.
Since the injection path is now no longer utilizing a work-item, it is
no longer necessary to maintain a separate cleanup WQ. The standard
kevent queues should be sufficient, and thus we can eliminate an extra
kthread from the system.
Signed-off-by: Gregory Haskins ghask
Gleb Natapov wrote:
On Wed, Oct 21, 2009 at 10:34:53AM -0400, Gregory Haskins wrote:
IRQFD currently uses a deferred workqueue item to execute the injection
operation. It was originally designed this way because kvm_set_irq()
required the caller to hold the irq_lock mutex, and the eventfd
Gleb Natapov wrote:
On Wed, Oct 21, 2009 at 11:34:51AM -0400, Gregory Haskins wrote:
Gleb Natapov wrote:
On Wed, Oct 21, 2009 at 10:34:53AM -0400, Gregory Haskins wrote:
IRQFD currently uses a deferred workqueue item to execute the injection
operation. It was originally designed this way
Avi Kivity wrote:
On 10/06/2009 09:40 PM, Gregory Haskins wrote:
Thinking about this some more over lunch, I think we (Avi and I) might
both be wrong (and David is right). Avi is right that we don't need
rmb() or barrier() for the reasons already stated, but I think David is
right that we
Avi Kivity wrote:
On 10/06/2009 01:57 AM, Gregory Haskins wrote:
Avi Kivity wrote:
On 10/02/2009 10:19 PM, Gregory Haskins wrote:
What: xinterface is a mechanism that allows kernel modules external to
the kvm.ko proper to interface with a running guest. It accomplishes
Gregory Haskins wrote:
Avi Kivity wrote:
On 10/06/2009 01:57 AM, Gregory Haskins wrote:
Avi Kivity wrote:
On 10/02/2009 10:19 PM, Gregory Haskins wrote:
+
+static inline void
+_kvm_xinterface_release(struct kref *kref)
+{
+struct kvm_xinterface *intf;
+struct module *owner
Avi Kivity wrote:
On 10/06/2009 03:31 PM, Gregory Haskins wrote:
slots would be one implementation, if you can think of others then you'd
add them.
I'm more interested in *how* you'd add them more than if we would add
them. What I am getting at are the logistics of such a beast
Avi Kivity wrote:
On 10/06/2009 04:22 PM, Gregory Haskins wrote:
+
+static inline void
+_kvm_xinterface_release(struct kref *kref)
+{
+struct kvm_xinterface *intf;
+struct module *owner;
+
+intf = container_of(kref, struct kvm_xinterface, kref);
+
+owner = intf-owner
Gregory Haskins wrote:
Avi Kivity wrote:
On 10/06/2009 04:22 PM, Gregory Haskins wrote:
+
+static inline void
+_kvm_xinterface_release(struct kref *kref)
+{
+struct kvm_xinterface *intf;
+struct module *owner;
+
+intf = container_of(kref, struct kvm_xinterface, kref
Gregory Haskins wrote:
Gregory Haskins wrote:
Avi Kivity wrote:
On 10/06/2009 04:22 PM, Gregory Haskins wrote:
+
+static inline void
+_kvm_xinterface_release(struct kref *kref)
+{
+struct kvm_xinterface *intf;
+struct module *owner;
+
+intf = container_of(kref, struct
Hi Marcelo!
Marcelo Tosatti wrote:
On Fri, Oct 02, 2009 at 04:19:27PM -0400, Gregory Haskins wrote:
What: xinterface is a mechanism that allows kernel modules external to
the kvm.ko proper to interface with a running guest. It accomplishes
this by creating an abstracted interface which does
Avi Kivity wrote:
On 10/02/2009 10:19 PM, Gregory Haskins wrote:
What: xinterface is a mechanism that allows kernel modules external to
the kvm.ko proper to interface with a running guest. It accomplishes
this by creating an abstracted interface which does not expose any
private details
Avi Kivity wrote:
On 10/02/2009 10:19 PM, Gregory Haskins wrote:
This allows a scatter-gather approach to IO, which will be useful for
building high performance interfaces, like zero-copy and low-latency
copy (avoiding multiple calls to copy_to/from).
The interface is based on the existing
?
Kind Regards,
-Greg
---
Gregory Haskins (4):
KVM: add scatterlist support to xinterface
KVM: add io services to xinterface
KVM: introduce xinterface API for external interaction with guests
mm: export use_mm() and unuse_mm() to modules
arch/x86/kvm/Makefile
We want to use these functions from withing KVM, which may be built as
a module.
Signed-off-by: Gregory Haskins ghask...@novell.com
---
mm/mmu_context.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/mm/mmu_context.c b/mm/mmu_context.c
index ded9081..f31ba20 100644
pinned at least until the foo module calls
kvm_xinterface_put().
Signed-off-by: Gregory Haskins ghask...@novell.com
---
arch/x86/kvm/Makefile |2
include/linux/kvm_host.h |3
include/linux/kvm_xinterface.h | 114 +++
kernel/fork.c |1
virt/kvm
-bus scaling and eventfd wait-queue based
notification mechanism. This also has the advantage of retaining
the full PIO data payload and passing it to the recipient.
Signed-off-by: Gregory Haskins ghask...@novell.com
---
include/linux/kvm_xinterface.h | 47 ++
virt/kvm
in a scatterlist with its dma field
populated with valid GPAs. The xinterface will then populate each
entry by translating the GPA to a page*.
The caller signifies completion by simply performing a put_page() on
each page returned in the list.
Signed-off-by: Gregory Haskins ghask...@novell.com
---
include
Avi Kivity wrote:
On 09/30/2009 10:04 PM, Gregory Haskins wrote:
A 2.6.27 guest, or Windows guest with the existing virtio drivers,
won't work
over vbus.
Binary compatibility with existing virtio drivers, while nice to have,
is not a specific requirement nor goal. We will simply
Avi Kivity wrote:
On 09/26/2009 12:32 AM, Gregory Haskins wrote:
I realize in retrospect that my choice of words above implies vbus _is_
complete, but this is not what I was saying. What I was trying to
convey is that vbus is _more_ complete. Yes, in either case some kind
of glue needs
Avi Kivity wrote:
On 09/24/2009 09:03 PM, Gregory Haskins wrote:
I don't really see how vhost and vbus are different here. vhost expects
signalling to happen through a couple of eventfds and requires someone
to supply them and implement kernel support (if needed). vbus requires
someone
Avi Kivity wrote:
On 09/24/2009 12:15 AM, Gregory Haskins wrote:
There are various aspects about designing high-performance virtual
devices such as providing the shortest paths possible between the
physical resources and the consumers. Conversely, we also need to
ensure that we meet proper
Avi Kivity wrote:
On 09/23/2009 10:37 PM, Avi Kivity wrote:
Example: feature negotiation. If it happens in userspace, it's easy
to limit what features we expose to the guest. If it happens in the
kernel, we need to add an interface to let the kernel know which
features it should expose to
Avi Kivity wrote:
On 09/22/2009 12:43 AM, Ira W. Snyder wrote:
Sure, virtio-ira and he is on his own to make a bus-model under that, or
virtio-vbus + vbus-ira-connector to use the vbus framework. Either
model can work, I agree.
Yes, I'm having to create my own bus model, a-la
Avi Kivity wrote:
On 09/23/2009 05:26 PM, Gregory Haskins wrote:
Yes, I'm having to create my own bus model, a-la lguest, virtio-pci,
and
virtio-s390. It isn't especially easy. I can steal lots of code from
the
lguest bus model, but sometimes it is good to generalize, especially
after
Gregory Haskins wrote:
Avi Kivity wrote:
On 09/23/2009 05:26 PM, Gregory Haskins wrote:
Yes, I'm having to create my own bus model, a-la lguest, virtio-pci,
and
virtio-s390. It isn't especially easy. I can steal lots of code from
the
lguest bus model, but sometimes it is good
Avi Kivity wrote:
On 09/23/2009 08:58 PM, Gregory Haskins wrote:
It also pulls parts of the device model into the host kernel.
That is the point. Most of it needs to be there for performance.
To clarify this point:
There are various aspects about designing high-performance
Avi Kivity wrote:
On 09/15/2009 11:08 PM, Gregory Haskins wrote:
There's virtio-console, virtio-blk etc. None of these have kernel-mode
servers, but these could be implemented if/when needed.
IIUC, Ira already needs at least ethernet and console capability.
He's welcome
Avi Kivity wrote:
On 09/16/2009 02:44 PM, Gregory Haskins wrote:
The problem isn't where to find the models...the problem is how to
aggregate multiple models to the guest.
You mean configuration?
You instantiate multiple vhost-nets. Multiple ethernet NICs is a
supported
Avi Kivity wrote:
On 09/16/2009 05:10 PM, Gregory Haskins wrote:
If kvm can do it, others can.
The problem is that you seem to either hand-wave over details like this,
or you give details that are pretty much exactly what vbus does already.
My point is that I've already sat down
Avi Kivity wrote:
On 09/16/2009 10:22 PM, Gregory Haskins wrote:
Avi Kivity wrote:
On 09/16/2009 05:10 PM, Gregory Haskins wrote:
If kvm can do it, others can.
The problem is that you seem to either hand-wave over details like
this,
or you give details that are pretty
Michael S. Tsirkin wrote:
On Wed, Sep 16, 2009 at 10:10:55AM -0400, Gregory Haskins wrote:
There is no role reversal.
So if I have virtio-blk driver running on the x86 and vhost-blk device
running on the ppc board, I can use the ppc board as a block-device.
What if I really wanted to go
Avi Kivity wrote:
On 09/14/2009 10:14 PM, Gregory Haskins wrote:
To reiterate, as long as the model is such that the ppc boards are
considered the owner (direct access, no translation needed) I believe
it will work. If the pointers are expected to be owned by the host,
then my model doesn't
Avi Kivity wrote:
On 09/15/2009 04:03 PM, Gregory Haskins wrote:
In this case the x86 is the owner and the ppc boards use translated
access. Just switch drivers and device and it falls into place.
You could switch vbus roles as well, I suppose.
Right, there's not real difference
Michael S. Tsirkin wrote:
On Tue, Sep 15, 2009 at 04:08:23PM -0400, Gregory Haskins wrote:
No, what I mean is how do you surface multiple ethernet and consoles to
the guests? For Ira's case, I think he needs at minimum at least one of
each, and he mentioned possibly having two unique
Michael S. Tsirkin wrote:
On Tue, Sep 15, 2009 at 04:43:58PM -0400, Gregory Haskins wrote:
Michael S. Tsirkin wrote:
On Tue, Sep 15, 2009 at 04:08:23PM -0400, Gregory Haskins wrote:
No, what I mean is how do you surface multiple ethernet and consoles to
the guests? For Ira's case, I think he
1 - 100 of 650 matches
Mail list logo
