On Fri, 2011-06-03 at 16:05 -0700, Paul E. McKenney wrote:
On Sat, Jun 04, 2011 at 01:54:45AM +0300, Sasha Levin wrote:
On Fri, 2011-06-03 at 14:20 -0700, Paul E. McKenney wrote:
On Sat, Jun 04, 2011 at 12:03:59AM +0300, Sasha Levin wrote:
On Fri, 2011-06-03 at 13:22 -0700, Paul E.
On Wed, Jun 1, 2011 at 2:30 AM, Anthony Liguori anth...@codemonkey.ws wrote:
On 05/31/2011 02:24 PM, Vivek Goyal wrote:
On Tue, May 31, 2011 at 01:39:47PM -0500, Anthony Liguori wrote:
On 05/31/2011 12:59 PM, Vivek Goyal wrote:
Ok, so we seem to be talking of two requirements.
- A
On Fri, 3 Jun 2011, Alex Williamson wrote:
On Fri, 2011-06-03 at 20:31 +0100, David Woodhouse wrote:
Tell me it isn't so...
Looks accurate to me, in fact, with hugetlbfs it seems like it's doing
exactly what it should do. The non-hugetlbfs case isn't efficient, but
it isn't wrong either.
* Sasha Levin levinsasha...@gmail.com wrote:
Coalescing MMIO allows us to avoid an exit every time we have a
MMIO write, instead - MMIO writes are coalesced in a ring which
can be flushed once an exit for a different reason is needed.
A MMIO exit is also trigged once the ring is full.
* Pekka Enberg penb...@kernel.org wrote:
This patch optimizes SDL updates by keeping track of which parts of the guest
screen have been written since last update and calling SDL_BlitSurface() and
SDL_UpdateRect() for only changed parts of the screen.
Cc: Cyrill Gorcunov gorcu...@gmail.com
On Sat, 2011-06-04 at 11:38 +0200, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
Coalescing MMIO allows us to avoid an exit every time we have a
MMIO write, instead - MMIO writes are coalesced in a ring which
can be flushed once an exit for a different reason is needed.
* Sasha Levin levinsasha...@gmail.com wrote:
On Sat, 2011-06-04 at 11:38 +0200, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
Coalescing MMIO allows us to avoid an exit every time we have a
MMIO write, instead - MMIO writes are coalesced in a ring which
can be
On 04.06.2011, at 11:54, Ingo Molnar wrote:
* Pekka Enberg penb...@kernel.org wrote:
This patch optimizes SDL updates by keeping track of which parts of the guest
screen have been written since last update and calling SDL_BlitSurface() and
SDL_UpdateRect() for only changed parts of the
On Sat, 2011-06-04 at 12:17 +0200, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
On Sat, 2011-06-04 at 11:38 +0200, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
Coalescing MMIO allows us to avoid an exit every time we have a
MMIO write,
* Sasha Levin levinsasha...@gmail.com wrote:
On Sat, 2011-06-04 at 12:17 +0200, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
On Sat, 2011-06-04 at 11:38 +0200, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
Coalescing MMIO allows us to
On 04.06.2011, at 12:35, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
On Sat, 2011-06-04 at 12:17 +0200, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
On Sat, 2011-06-04 at 11:38 +0200, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com
* Alexander Graf ag...@suse.de wrote:
I wrote up 2 virtio-fb implementations a while back and I still
believe it's a bad idea. Better implement QXL in kvm-tool, so work
doesn't get needlessly duplicated. If you really have to use virtio
for whatever reason (no PCI available), just write a
On 04.06.2011, at 12:42, Ingo Molnar wrote:
* Alexander Graf ag...@suse.de wrote:
I wrote up 2 virtio-fb implementations a while back and I still
believe it's a bad idea. Better implement QXL in kvm-tool, so work
doesn't get needlessly duplicated. If you really have to use virtio
for
* Alexander Graf ag...@suse.de wrote:
On 04.06.2011, at 12:35, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
On Sat, 2011-06-04 at 12:17 +0200, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
On Sat, 2011-06-04 at 11:38 +0200, Ingo Molnar
* Alexander Graf ag...@suse.de wrote:
On 04.06.2011, at 12:42, Ingo Molnar wrote:
* Alexander Graf ag...@suse.de wrote:
I wrote up 2 virtio-fb implementations a while back and I still
believe it's a bad idea. Better implement QXL in kvm-tool, so work
doesn't get needlessly
On 04.06.2011, at 12:47, Ingo Molnar wrote:
* Alexander Graf ag...@suse.de wrote:
On 04.06.2011, at 12:35, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
On Sat, 2011-06-04 at 12:17 +0200, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
On
On 04.06.2011, at 12:54, Ingo Molnar wrote:
* Alexander Graf ag...@suse.de wrote:
On 04.06.2011, at 12:42, Ingo Molnar wrote:
* Alexander Graf ag...@suse.de wrote:
I wrote up 2 virtio-fb implementations a while back and I still
believe it's a bad idea. Better implement QXL in
* Alexander Graf ag...@suse.de wrote:
So? I only inquired about latencies, asking what impact on
latencies is. Regardless of the circumstances we do not want to
introduce unbound latencies.
If there are no unbound latencies then i'm happy.
Sure, I'm just saying that the mechanism
On 04.06.2011, at 13:27, Ingo Molnar wrote:
* Alexander Graf ag...@suse.de wrote:
So? I only inquired about latencies, asking what impact on
latencies is. Regardless of the circumstances we do not want to
introduce unbound latencies.
If there are no unbound latencies then i'm happy.
* Alexander Graf ag...@suse.de wrote:
Why would you need panning/scrolling for a fast FB? It's really an
optimization that helps a lot with VNC, but on local machines or
SDL you shouldn't see a major difference.
Qemu's fb console scrolling graphics is pretty slow to me even
locally so i
On 04.06.2011, at 13:53, Ingo Molnar wrote:
* Alexander Graf ag...@suse.de wrote:
Why would you need panning/scrolling for a fast FB? It's really an
optimization that helps a lot with VNC, but on local machines or
SDL you shouldn't see a major difference.
Qemu's fb console scrolling
On Sat, 2011-06-04 at 13:53 +0200, Ingo Molnar wrote:
* Alexander Graf ag...@suse.de wrote:
Why would you need panning/scrolling for a fast FB? It's really an
optimization that helps a lot with VNC, but on local machines or
SDL you shouldn't see a major difference.
Qemu's fb console
On 04.06.2011, at 14:04, Sasha Levin wrote:
On Sat, 2011-06-04 at 13:53 +0200, Ingo Molnar wrote:
* Alexander Graf ag...@suse.de wrote:
Why would you need panning/scrolling for a fast FB? It's really an
optimization that helps a lot with VNC, but on local machines or
SDL you shouldn't
On 03.06.2011, at 17:53, Jan Kiszka wrote:
On 2011-06-03 17:31, Jan Kiszka wrote:
On 2011-06-03 17:03, Christoffer Dall wrote:
Targets KVM support for Cortex A-15 processors.
Contains no real functionality but all the framework components,
make files, header files and some tracing
On Sat, 2011-06-04 at 15:48 +0200, Alexander Graf wrote:
On 04.06.2011, at 14:04, Sasha Levin wrote:
On Sat, 2011-06-04 at 13:53 +0200, Ingo Molnar wrote:
* Alexander Graf ag...@suse.de wrote:
Why would you need panning/scrolling for a fast FB? It's really an
optimization that helps
* Alexander Graf ag...@suse.de wrote:
So the simple rule is: don't register a coalesced MMIO region for a
region where latency matters. [...]
So my first suspicion is confirmed.
A quick look at Qemu sources shows that lots of drivers are using
coalesced_mmio without being aware of the
On 04.06.2011, at 16:19, Sasha Levin wrote:
On Sat, 2011-06-04 at 15:48 +0200, Alexander Graf wrote:
On 04.06.2011, at 14:04, Sasha Levin wrote:
On Sat, 2011-06-04 at 13:53 +0200, Ingo Molnar wrote:
* Alexander Graf ag...@suse.de wrote:
Why would you need panning/scrolling for a fast
On 04.06.2011, at 16:46, Ingo Molnar wrote:
* Alexander Graf ag...@suse.de wrote:
So the simple rule is: don't register a coalesced MMIO region for a
region where latency matters. [...]
So my first suspicion is confirmed.
A quick look at Qemu sources shows that lots of drivers are
On Sat, 2011-06-04 at 17:21 +0200, Alexander Graf wrote:
On 04.06.2011, at 16:19, Sasha Levin wrote:
On Sat, 2011-06-04 at 15:48 +0200, Alexander Graf wrote:
On 04.06.2011, at 14:04, Sasha Levin wrote:
On Sat, 2011-06-04 at 13:53 +0200, Ingo Molnar wrote:
* Alexander Graf
On 04.06.2011, at 17:34, Sasha Levin wrote:
On Sat, 2011-06-04 at 17:21 +0200, Alexander Graf wrote:
On 04.06.2011, at 16:19, Sasha Levin wrote:
On Sat, 2011-06-04 at 15:48 +0200, Alexander Graf wrote:
On 04.06.2011, at 14:04, Sasha Levin wrote:
On Sat, 2011-06-04 at 13:53 +0200, Ingo
Since printk_ratelimit() shouldn't be used anymore (see comment in
include/linux/printk.h), replace it with printk_ratelimited.
Signed-off-by: Christian Dietrich
christian.dietr...@informatik.uni-erlangen.de
---
arch/x86/kernel/hpet.c |6 +++---
arch/x86/kernel/irq.c |9 -
On Sat, Jun 04, 2011 at 09:26:15AM +0300, Sasha Levin wrote:
On Fri, 2011-06-03 at 16:05 -0700, Paul E. McKenney wrote:
On Sat, Jun 04, 2011 at 01:54:45AM +0300, Sasha Levin wrote:
On Fri, 2011-06-03 at 14:20 -0700, Paul E. McKenney wrote:
On Sat, Jun 04, 2011 at 12:03:59AM +0300, Sasha
* Alexander Graf ag...@suse.de wrote:
On 04.06.2011, at 16:46, Ingo Molnar wrote:
* Alexander Graf ag...@suse.de wrote:
So the simple rule is: don't register a coalesced MMIO region for a
region where latency matters. [...]
So my first suspicion is confirmed.
A quick
On Sat, 2011-06-04 at 17:40 +0200, Alexander Graf wrote:
On 04.06.2011, at 17:34, Sasha Levin wrote:
On Sat, 2011-06-04 at 17:21 +0200, Alexander Graf wrote:
On 04.06.2011, at 16:19, Sasha Levin wrote:
On Sat, 2011-06-04 at 15:48 +0200, Alexander Graf wrote:
On 04.06.2011, at 14:04,
On Sat, 2011-06-04 at 18:34 +0200, Ingo Molnar wrote:
* Alexander Graf ag...@suse.de wrote:
On 04.06.2011, at 16:46, Ingo Molnar wrote:
* Alexander Graf ag...@suse.de wrote:
So the simple rule is: don't register a coalesced MMIO region for a
region where latency
Hi,
as mentioned before I have successfully passed a graphics card from a
Linux host to VM using qemu-kvm.
Shortly after starting the VM and before Windows7 initializes the
graphics card, info pci looks like this:
Bus 0, device 4, function 0:
VGA controller: PCI device 1002:6719
36 matches
Mail list logo
