>
>> OK, this seems to work fine for me. Tested with virtio-net in guest
>> with and without vhost-net. Pls review/apply if appropriate.
>
> Acked-by: Marcelo Tosatti
Acked-by: Gregory Haskins
--
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
e remember why anymore (it obviously was a
failing 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
>
> Signed-off-by: Michael S. Tsi
s to allow each fd to only trigger one 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
Seems reasonable to me.
Acked-by: Gregory Haski
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 +
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
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
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
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
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
>>
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
12/23/09, Avi Kivity 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 wro
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
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 yo
On 12/23/09 1:15 AM, Kyle Moffett wrote:
> On Tue, Dec 22, 2009 at 12:36, Gregory Haskins
> wrote:
>> On 12/22/09 2:57 AM, Ingo Molnar wrote:
>>> * Gregory Haskins wrote:
>>>> Actually, these patches have nothing to do with the KVM folks. [...]
>>
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:51 AM, Ingo Molnar wrote:
>
> * Anthony Liguori 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.
>>> Right, like
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.
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: t
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
>>
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 interfac
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
On 12/22/09 2:25 PM, Avi Kivity wrote:
> On 12/22/2009 09:15 PM, 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.
>>>
>>>
>&
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 w
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 conv
On 12/22/09 2:57 AM, Ingo Molnar wrote:
>
> * Gregory Haskins wrote:
>
>> On 12/18/09 4:51 PM, Ingo Molnar wrote:
>>>
>>> * Gregory Haskins wrote:
>>>
>>>> Hi Linus,
>>>>
>>>> Please pull AlacrityVM guest support for
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 eve
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.
>>>
>>>
>> Whil
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
>
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
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,
On 12/18/09 4:51 PM, Ingo Molnar wrote:
>
> * Gregory Haskins 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
>>
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
p
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
>>&
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 t
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 l
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
>>>>
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_name
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
> Signed-off-by: Michael S. Tsirkin
I need this too:
Acked-by: Gregory Haskins
> ---
> mm
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;
>
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?
>>
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
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 inj
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
>>>>
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 th
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
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:
>>>>>
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 wha
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 f
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
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
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
>> --
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-1
ery a specific GSI.
Signed-off-by: Gregory Haskins
---
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 1fe135d..01
ed-off-by: Gregory Haskins
---
include/linux/kvm_host.h |6 +-
virt/kvm/irq_comm.c | 50 +++---
virt/kvm/kvm_main.c |1 +
3 files changed, 35 insertions(+), 22 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_hos
GSIs) readily support
lockless injection.
Signed-off-by: Gregory Haskins
---
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/kvm/eventfd.c
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
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
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 in
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 co
GSIs) readily support
lockless injection.
Signed-off-by: Gregory Haskins
---
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/kvm/eventfd.c
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
ery a specific GSI.
Signed-off-by: Gregory Haskins
---
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 100644
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
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 eventf
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
>
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 ir
sed 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
---
vir
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
---
virt/kvm/eventfd.c | 15 +++
1 files changed
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
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
Gregory Haskins wrote:
> Gregory Haskins wrote:
>> Avi Kivity wrote:
>>> On 10/06/2009 04:22 PM, Gregory Haskins wrote:
>>>>>>>>> +
>>>>>>>>> +static inline void
>>>>>>>>> +_kvm_xinterface_releas
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)
>>
Avi Kivity wrote:
> On 10/06/2009 04:22 PM, Gregory Haskins wrote:
>>>>>>> +
>>>>>>> +static inline void
>>>>>>> +_kvm_xinterface_release(struct kref *kref)
>>>>>>> +{
>>>>>>> +str
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&quo
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
>>
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
>>>>
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).
>>
>&
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
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
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
---
inc
limited by io-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
---
include/linux/kvm_xinterface.h | 47 ++
virt/kvm/xi
ated
struct module* will remain pinned at least until the foo module calls
kvm_xinterface_put().
Signed-off-by: Gregory Haskins
---
arch/x86/kvm/Makefile |2
include/linux/kvm_host.h |3
include/linux/kvm_xinterface.h | 114 +++
kernel/fork.c |
We want to use these functions from withing KVM, which may be built as
a module.
Signed-off-by: Gregory Haskins
---
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
--- a/mm
?
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/kv
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,
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
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 k
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
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 consum
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.
>>>
>>
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
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 fro
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
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.
&g
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.
>>>>>
>>>>>
>
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 d
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 multi
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
Michael S. Tsirkin wrote:
> On Tue, Sep 15, 2009 at 05:39:27PM -0400, Gregory Haskins wrote:
>> 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, 20
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
1 - 100 of 706 matches
Mail list logo
