On Wed, Aug 12, 2009 at 02:22:38PM -0500, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>>>
>>> We discussed this before, and I still think this could be directly derived
>>> from struct virtqueue, in the same way that vring_virtqueue is derived from
>>> struct virtqueue.
>>>
>>
>> I pref
This adds support for vhost-net virtio kernel backend.
This is RFC, but works without issues for me.
Still needs to be split up, tested and benchmarked properly,
but posting it here in case people want to test drive
the kernel bits I posted.
Changes since v1:
- rebased on top of 9dc275d9d660fe1c
virtio-pci depends, and will always depend, on pci.c
so it makes sense to keep it in the same makefile,
(unlike the rest of virtio files which should eventually
be moved out to Makefile.hw).
Signed-off-by: Michael S. Tsirkin
---
Makefile.hw |2 +-
Makefile.target |2 +-
2 files chan
devices should have the final say over which virtio features they
support. E.g. indirect entries may or may not make sense in the context
of virtio-console. Move the common bits from virtio-pci to an inline
function and let each device call it.
No functional changes.
Signed-off-by: Michael S. Ts
This adds support for vhost-net virtio kernel backend.
To enable (assuming device eth2):
1. enable promisc mode or program guest mac in device eth2
2. disable tso, gso, lro on the card
3. add vhost=eth0 to -net flag
4. run with CAP_NET_ADMIN priviledge (e.g. root)
This patch is RFC, but works with
On Wed, Aug 12, 2009 at 03:17:15PM +0300, Gleb Natapov wrote:
> For device assigned it may cause host hang since ack notifier callback
> enables host interrupt and guest not necessary cleared interrupt
> condition in an assigned device. For PIT we should not call ack notifier
> here since interrupt
On Wed, Aug 12, 2009 at 03:17:21PM +0300, Gleb Natapov wrote:
>
> Signed-off-by: Gleb Natapov
> ---
> arch/ia64/kvm/kvm-ia64.c |7 +---
> arch/x86/kvm/i8259.c | 22 +---
> arch/x86/kvm/lapic.c |5 +--
> arch/x86/kvm/x86.c | 10 +
> virt/kvm/ioapic.c|
- "Chen Cao" wrote:
> On Wed, Aug 12, 2009 at 07:29:25AM -0400, Michael Goldish wrote:
> >
> > - "Chen Cao" wrote:
> >
> > > On Wed, Aug 12, 2009 at 05:44:34AM -0400, Michael Goldish wrote:
> > > >
> > > > - "Chen Cao" wrote:
> > > >
> > > > > On Tue, Aug 11, 2009 at 03:10:44PM
On Thu, Aug 13, 2009 at 06:11:05AM -0300, Marcelo Tosatti wrote:
> On Wed, Aug 12, 2009 at 03:17:15PM +0300, Gleb Natapov wrote:
> > For device assigned it may cause host hang since ack notifier callback
> > enables host interrupt and guest not necessary cleared interrupt
> > condition in an assign
On Thu, Aug 13, 2009 at 06:13:30AM -0300, Marcelo Tosatti wrote:
> > +++ b/virt/kvm/ioapic.c
> > @@ -182,6 +182,7 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int
> > irq, int level)
> > union kvm_ioapic_redirect_entry entry;
> > int ret = 1;
> >
> > + mutex_lock(&ioapic->lock)
On 08/13/2009 12:48 PM, Gleb Natapov wrote:
On Thu, Aug 13, 2009 at 06:13:30AM -0300, Marcelo Tosatti wrote:
+++ b/virt/kvm/ioapic.c
@@ -182,6 +182,7 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq,
int level)
union kvm_ioapic_redirect_entry entry;
int ret = 1;
On Thu, Aug 13, 2009 at 12:49:45PM +0300, Avi Kivity wrote:
> On 08/13/2009 12:48 PM, Gleb Natapov wrote:
> >On Thu, Aug 13, 2009 at 06:13:30AM -0300, Marcelo Tosatti wrote:
> >>>+++ b/virt/kvm/ioapic.c
> >>>@@ -182,6 +182,7 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int
> >>>irq, int le
On 08/13/2009 01:09 PM, Gleb Natapov wrote:
There's also srcu.
What are the disadvantages? There should be some, otherwise why not use
it all the time.
I think it incurs an atomic op in the read path, but not much overhead
otherwise. Paul?
--
error compiling committee.c: too man
On 08/13/2009 12:42 AM, Mohammed Gamal wrote:
Signed-off-by: Mohammed Gamal
---
arch/x86/kvm/Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile
index afaaa76..0e7fe78 100644
--- a/arch/x86/kvm/Makefile
+++ b/arch/x86
Michael S. Tsirkin wrote:
> On Wed, Aug 12, 2009 at 04:27:44PM -0400, Gregory Haskins wrote:
>> Michael S. Tsirkin wrote:
>>> This adds support for vhost-net virtio kernel backend.
>>>
>>> This is RFC, but works without issues for me.
>>>
>>> Still needs to be split up, tested and benchmarked prope
On Thu, Aug 13, 2009 at 07:35:52AM -0400, Gregory Haskins wrote:
> Michael S. Tsirkin wrote:
> > On Wed, Aug 12, 2009 at 04:27:44PM -0400, Gregory Haskins wrote:
> >> Michael S. Tsirkin wrote:
> >>> This adds support for vhost-net virtio kernel backend.
> >>>
> >>> This is RFC, but works without is
Gregory Haskins wrote:
> Anthony Liguori wrote:
>> Just FYI, the numbers quoted are wrong for virtio-u. Greg's machine
>> didn't have high res timers enabled in the kernel. He'll post newer
>> numbers later but they're much better than these (venet is still ahead
>> though).
>>
>> Regards,
>>
>>
Chris Webb writes:
> Avi Kivity writes:
>
> > I understand it's hard, but it's nearly impossible to work out the
> > problem from so little data, so please do make the effort to obtain
> > dumps.
>
> We're trying for this at the moment, but since we can't change the rlimit
> for the running
Chris Webb writes:
> The segfault appears to be a null pointer dereference. ts->clock is NULL
> and line 1161 uses ts->clock->type:
>
> (gdb) p ts
> $4 = (QEMUTimer *) 0x30d1f30
> (gdb) p ts->clock
> $5 = (QEMUClock *) 0x0
Sorry, meant to paste this too:
(gdb) p *ts
$1 = {clock
On 08/13/2009 03:23 PM, Chris Webb wrote:
We've been lucky and relatively quickly got a core dump from one of the new
qemu-kvms with the non-zero core file rlimit. A backtrace looks like this:
(gdb) bt
#0 0x004068f7 in qemu_mod_timer (ts=0x30d1f30, expire_time=430489)
at /p
Avi Kivity writes:
> csock looks corrupted, should be -1 or an fd. Was a vnc client connected?
> Was the guest playing with the display resolution?
Yes, I think in this case there was a vncviewer connected, and the guest had
started booting up into windows, which changes the resolution a couple
Chris Webb writes:
> Avi Kivity writes:
>
> > csock looks corrupted, should be -1 or an fd. Was a vnc client connected?
> > Was the guest playing with the display resolution?
>
> Yes, I think in this case there was a vncviewer connected, and the guest had
> started booting up into windows, wh
On 08/13/2009 03:45 PM, Chris Webb wrote:
Chris Webb writes:
Avi Kivity writes:
csock looks corrupted, should be -1 or an fd. Was a vnc client connected?
Was the guest playing with the display resolution?
Yes, I think in this case there was a vncviewer connected, and the
On Wednesday 12 August 2009, Anthony Liguori wrote:
> At any rate, I'd like to see performance results before we consider
> trying to reuse virtio code.
Yes, I agree. I'd also like to do more work on the macvlan extensions
to see if it works out without involving a socket. Passing the socket
into
On Thursday 13 August 2009, Arnd Bergmann wrote:
> Unfortunately, this also implies that you could no longer simply use the
> packet socket interface as you do currently, as I realized only now.
> This obviously has a significant impact on your user space interface.
Also, if we do the copy in the
On Thursday 13 August 2009, Michael S. Tsirkin wrote:
> On Wed, Aug 12, 2009 at 07:59:47PM +0200, Arnd Bergmann wrote:
> > The trick is to swap the virtqueues instead. virtio-net is actually
> > mostly symmetric in just the same way that the physical wires on a
> > twisted pair ethernet are symmetr
The KVM list moved to vger.kernel.org last year
Signed-off-by: Amit Shah
---
Documentation/ioctl/ioctl-number.txt |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/ioctl/ioctl-number.txt
b/Documentation/ioctl/ioctl-number.txt
index 1f779a2..a039cb0 100644
-
On Thu, Aug 13, 2009 at 03:38:43PM +0200, Arnd Bergmann wrote:
> On Thursday 13 August 2009, Michael S. Tsirkin wrote:
> > On Wed, Aug 12, 2009 at 07:59:47PM +0200, Arnd Bergmann wrote:
> > > The trick is to swap the virtqueues instead. virtio-net is actually
> > > mostly symmetric in just the same
On Thu, Aug 13, 2009 at 03:48:35PM +0200, Arnd Bergmann wrote:
> On Thursday 13 August 2009, Arnd Bergmann wrote:
> > Unfortunately, this also implies that you could no longer simply use the
> > packet socket interface as you do currently, as I realized only now.
> > This obviously has a significan
On Thursday 13 August 2009, Michael S. Tsirkin wrote:
> The best way to do this IMO would be to add zero copy support to raw
> sockets, vhost will then get it basically for free.
Yes, that would be nice. I wonder if that could lead to security
problems on TX though. I guess It will only bring sign
On Thursday 13 August 2009, Michael S. Tsirkin wrote:
> > Right now, the number of copy operations in your code is the same.
> > You are doing the copy a little bit later in skb_copy_datagram_iovec(),
> > which is indeed a very nice hack. Changing to a virtqueue based method
> > would imply that th
On Thu, Aug 13, 2009 at 04:58:06PM +0200, Arnd Bergmann wrote:
> On Thursday 13 August 2009, Michael S. Tsirkin wrote:
> > > Right now, the number of copy operations in your code is the same.
> > > You are doing the copy a little bit later in skb_copy_datagram_iovec(),
> > > which is indeed a very
On Thu, Aug 13, 2009 at 01:44:06PM +0300, Avi Kivity wrote:
> On 08/13/2009 01:09 PM, Gleb Natapov wrote:
>>> There's also srcu.
>>>
>> What are the disadvantages? There should be some, otherwise why not use
>> it all the time.
>
> I think it incurs an atomic op in the read path, but not much
On 08/13/2009 05:53 PM, Arnd Bergmann wrote:
On Thursday 13 August 2009, Michael S. Tsirkin wrote:
The best way to do this IMO would be to add zero copy support to raw
sockets, vhost will then get it basically for free.
Yes, that would be nice. I wonder if that could lead to security
This removes assumptions that max GSIs is smaller than number of pins.
Sharing is tracked on pin level not GSI level.
Signed-off-by: Gleb Natapov
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index b17d845..4c15bdd 100644
--- a/arch/x86/include/asm/kvm_host.h
+++
This implements vhost: a kernel-level backend for virtio,
The main motivation for this work is to reduce virtualization
overhead for virtio by removing system calls on data path,
without guest changes. For virtio-net, this removes up to
4 system calls per packet: vm exit for kick, reentry for kick,
vhost net module wants to do copy to/from user from a kernel thread,
which needs use_mm (like what fs/aio has). Move that into mm/ and
export to modules.
Acked-by: Andrew Morton
Signed-off-by: Michael S. Tsirkin
---
fs/aio.c| 47 +--
includ
What it is: vhost net is a character device that can be used to reduce
the number of system calls involved in virtio networking.
Existing virtio net code is used in the guest without modification.
There's similarity with vringfd, with some differences and reduced scope
- uses eventfd for signallin
Bugs item #2837083, was opened at 2009-08-13 16:27
Message generated for change (Tracker Item Submitted) made by atilaromero
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2837083&group_id=180599
Please note that this message will contain a full copy of
On Wed, 12 Aug 2009 15:01:52 +0930
Rusty Russell wrote:
> On Wed, 12 Aug 2009 12:49:51 pm Rusty Russell wrote:
> > On Tue, 11 Aug 2009 04:22:53 pm Avi Kivity wrote:
> > > On 08/11/2009 09:32 AM, Pierre Ossman wrote:
> > > > I doesn't get out of it though, or at least the virtio net driver
> > > >
Add a user-space selftest of x86 instruction decoder at kernel build time.
When CONFIG_X86_DECODER_SELFTEST=y, Kbuild builds a test harness of x86
instruction decoder and performs it after building vmlinux.
The test compares the results of objdump and x86 instruction decoder
code and check there ar
Add x86 instruction decoder to arch-specific libraries. This decoder
can decode x86 instructions used in kernel into prefix, opcode, modrm,
sib, displacement and immediates. This can also show the length of
instructions.
This version introduces instruction attributes for decoding instructions.
The
Hi,
Here are the patches of kprobe-based event tracer for x86, version 14,
which allows you to probe various kernel events through ftrace interface.
The tracer supports per-probe filtering which allows you to set filters
on each probe and shows formats of each probe.
This version includes below f
Cleanup fix_riprel() in arch/x86/kernel/kprobes.c by using x86 instruction
decoder.
Signed-off-by: Masami Hiramatsu
Cc: Ananth N Mavinakayanahalli
Cc: Avi Kivity
Cc: Andi Kleen
Cc: Christoph Hellwig
Cc: Frank Ch. Eigler
Cc: Frederic Weisbecker
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc: Jason
Add dynamic ftrace_event_call support to ftrace. Trace engines can adds new
ftrace_event_call to ftrace on the fly. Each operator functions of the call
takes a ftrace_event_call data structure as an argument, because these
functions may be shared among several ftrace_event_calls.
Changes from v13:
Use TRACE_FIELD_ZERO(type, item) instead of TRACE_FIELD_ZERO_CHAR(item).
This also includes a fix of TRACE_ZERO_CHAR() macro.
Signed-off-by: Masami Hiramatsu
Cc: Ananth N Mavinakayanahalli
Cc: Avi Kivity
Cc: Andi Kleen
Cc: Christoph Hellwig
Cc: Frank Ch. Eigler
Cc: Frederic Weisbecker
Cc: H
Generate names for each kprobe event based on the probe point,
and remove generic k*probe event types because there is no user
of those types.
Signed-off-by: Masami Hiramatsu
Cc: Ananth N Mavinakayanahalli
Cc: Avi Kivity
Cc: Andi Kleen
Cc: Christoph Hellwig
Cc: Frank Ch. Eigler
Cc: Frederic
Add profiling interaces for each kprobes event. This interface provides
how many times each probe hit or missed.
Signed-off-by: Masami Hiramatsu
Cc: Ananth N Mavinakayanahalli
Cc: Avi Kivity
Cc: Andi Kleen
Cc: Christoph Hellwig
Cc: Frank Ch. Eigler
Cc: Frederic Weisbecker
Cc: H. Peter Anvin
Add kprobes-based event tracer on ftrace.
This tracer is similar to the events tracer which is based on Tracepoint
infrastructure. Instead of Tracepoint, this tracer is based on kprobes
(kprobe and kretprobe). It probes anywhere where kprobes can probe(this
means, all functions body except for __
Support up to 128 arguments for each kprobes event.
Signed-off-by: Masami Hiramatsu
Cc: Ananth N Mavinakayanahalli
Cc: Avi Kivity
Cc: Andi Kleen
Cc: Christoph Hellwig
Cc: Frank Ch. Eigler
Cc: Frederic Weisbecker
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc: Jason Baron
Cc: Jim Keniston
Cc: K.P
Assigns new event ids for each kprobes event. This doesn't clear ring_buffer
when unregistering each kprobe event. Thus, if you mind 'Unknown event'
messages, clear the buffer manually after changing kprobe events.
Signed-off-by: Masami Hiramatsu
Cc: Ananth N Mavinakayanahalli
Cc: Avi Kivity
Cc
Add following APIs for accessing registers and stack entries from pt_regs.
These APIs are required by kprobes-based event tracer on ftrace.
Some other debugging tools might be able to use it too.
- regs_query_register_offset(const char *name)
Query the offset of "name" register.
- regs_query_r
Ensure safeness of inserting kprobes by checking whether the specified
address is at the first byte of a instruction on x86.
This is done by decoding probed function from its head to the probe point.
Signed-off-by: Masami Hiramatsu
Acked-by: Ananth N Mavinakayanahalli
Cc: Avi Kivity
Cc: Andi Kl
This script tests kprobes to probe on all symbols in the kernel and finds
symbols which must be blacklisted.
Usage
-
kprobestest [-s SYMLIST] [-b BLACKLIST] [-w WHITELIST]
Run stress test. If SYMLIST file is specified, use it as
an initial symbol list (This is useful for verifyin
This program converts probe point in C expression to kprobe event
format for kprobe-based event tracer. This helps to define kprobes
events by C source line number or function name, and local variable
name. Currently, this supports only x86(32/64) kernels.
Compile
Before compilation, pl
You rock, this is awesome! I'm a bit busy right now, but I'll play
around with it ASAP and will see how well it works for me.
--
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/majo
Is OpenGL Acceleration based on the host's OpenGL capability available
in KVM?
Thanks.
Gordan
--
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
With the recent talk of the trim SATA instruction becoming supported in
the upcoming versions of Windows and claims from Intel that support for
it in their SSDs is imminent, it occurs to me that this would be equally
useful in virtual disk emulation.
Since the disk image is a sparse file, it a
On Fri, Aug 14, 2009 at 1:06 AM, Gordan Bobic wrote:
> Is OpenGL Acceleration based on the host's OpenGL capability available in
> KVM?
No.
The Virtualbox code for that is open though (uses chromium like VMGL) in case
you 'd like to port it to qemu/kvm :)
--
To unsubscribe from this list: send th
59 matches
Mail list logo
