Here are the SMT off results. This workload is designed to not
over-saturate the CPU, so you have to pick a number of server sets to
ensure that. With SMT on, 4 sets was enough for KVM, but 5 was too much
(start seeing response time errors). For SMT off, I tried to size the
load as high as w
On Thu, Apr 30, 2009 at 4:49 PM, Paul Brook wrote:
> One of the nice things about scsi is it separates the command set from the
> transport layer. cf. USB mass-storage, SAS, SBP2(firewire), and probably
> several others I've forgotten.
ATAPI, SCSIoFC, SCSIoIB
--
Javier
--
To unsubscribe fr
On Thursday 30 April 2009, Christoph Hellwig wrote:
> On Wed, Apr 29, 2009 at 12:37:20PM +0100, Paul Brook wrote:
> > How exactly does it introduce additional latency? A scsi command block is
> > hardly large or complicated. Are you suggesting that a 16/32byte scsi
> > command takes significantly l
On Thu, 2009-04-30 at 22:13 +0200, Christoph Hellwig wrote:
> On Wed, Apr 29, 2009 at 12:37:20PM +0100, Paul Brook wrote:
> > How exactly does it introduce additional latency? A scsi command block is
> > hardly large or complicated. Are you suggesting that a 16/32byte scsi
> > command
> > takes
Greetings KVM folks,
I wondering if any information exists for doing SR-IOV on the new VT-d
capable chipsets with KVM..? From what I understand the patches for
doing this with KVM are floating around, but I have been unable to find
any user-level docs for actually making it all go against a upstr
On Wed, Apr 29, 2009 at 12:37:20PM +0100, Paul Brook wrote:
> How exactly does it introduce additional latency? A scsi command block is
> hardly large or complicated. Are you suggesting that a 16/32byte scsi command
> takes significantly longer to process than a 16byte virtio command
> descripto
Bugs item #2638990, was opened at 2009-02-25 23:35
Message generated for change (Comment added) made by ivanvimes
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2638990&group_id=180599
Please note that this message will contain a full copy of the comment
Bugs item #2638990, was opened at 2009-02-26 01:35
Message generated for change (Comment added) made by avik
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2638990&group_id=180599
Please note that this message will contain a full copy of the comment thre
Bugs item #2638990, was opened at 2009-02-25 23:35
Message generated for change (Comment added) made by ivanvimes
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2638990&group_id=180599
Please note that this message will contain a full copy of the comment
Bugs item #2638990, was opened at 2009-02-25 23:35
Message generated for change (Comment added) made by ivanvimes
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2638990&group_id=180599
Please note that this message will contain a full copy of the comment
On Thu, 30 Apr 2009 20:46:24 +0300 Izik Eidus wrote:
> Following patchs change the api to be more robust, the result change of
> the api came after conversation i had with Andrea and Chris about how
> to make the api as stable as we can,
>
> In addition i hope this patchset fix the cross compila
On Tue, 28 Apr 2009 02:12:00 +0300
Izik Eidus wrote:
> Andrew Morton wrote:
> > Breaks sparc64 and probably lots of other architectures:
> >
> > mm/ksm.c: In function `try_to_merge_two_pages_alloc':
> > mm/ksm.c:697: error: `_PAGE_RW' undeclared (first use in this
> > function)
> >
> > there sho
On Thu, Apr 30, 2009 at 11:56:14AM +0300, Avi Kivity wrote:
> Andrew Theurer wrote:
>> Comparing guest time to all other busy time, that's a 23.88/43.02 = 55%
>> overhead for virtualization. I certainly don't expect it to be 0, but
>> 55% seems a bit high. So, what's the reason for this overhead?
Avi Kivity wrote:
Anthony Liguori wrote:
Previously, the block API only exposed non-vector interfaces and
bounced vectored operations to a linear buffer. That's been
eliminated now though so we need to update the linux-aio patch to
implement a vectored backend interface.
However, it is an
Anthony Liguori wrote:
This requires adding the necessary bits to configure to create the directories
and symlinks for libkvm. It also requires sticking KVM_CFLAGS in
config-host.mak to ensure that it gets the right set of includes for the
kernel headers.
Applied, thanks.
--
error compilin
Anthony Liguori wrote:
Avi Kivity wrote:
Do we really care about optimizing latency with -clock rtc though?
People still run kvm on RHEL 5 (or cheap clones thereof), aren't they
affected?
Do they use -clock rtc? -clock dynticks should still work on RHEL 5
it's just that you won't get ve
Avi Kivity wrote:
Do we really care about optimizing latency with -clock rtc though?
People still run kvm on RHEL 5 (or cheap clones thereof), aren't they
affected?
Do they use -clock rtc? -clock dynticks should still work on RHEL 5
it's just that you won't get very accurate timer events
Avi Kivity wrote:
Anthony Liguori wrote:
This requires adding the necessary bits to configure to create the
directories
and symlinks for libkvm. It also requires sticking KVM_CFLAGS in
config-host.mak to ensure that it gets the right set of includes for the
kernel headers.
v1 => v2
Fix buil
Bugs item #2638990, was opened at 2009-02-25 17:35
Message generated for change (Comment added) made by iggy_cav
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2638990&group_id=180599
Please note that this message will contain a full copy of the comment
This requires adding the necessary bits to configure to create the directories
and symlinks for libkvm. It also requires sticking KVM_CFLAGS in
config-host.mak to ensure that it gets the right set of includes for the
kernel headers.
v1 => v2
Fix build when objdir == srcdir
v2 => v3
git add t
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
In modern KVM, the IO thread is capable of interrupting the CPU
whenever it needs to process IO. Therefore this "problem" no longer
exists.
It would still be good to verify that the problem no longer exists.
This is not a c
Jan Kiszka wrote:
Pushing things upstream is quite difficult because of the very different
infrastructure.
Isn't the midterm goal to get rid of most of these differences (namely
libkvm)?
Yes, but not by removing existing functionality.
No one s
Avi Kivity wrote:
> Jan Kiszka wrote:
>> Avi Kivity wrote:
>>
>> Where/how does the
>> migration code disable dirty logging?
>>
> Should be phase 3 of ram_save_live().
>
But only in qemu-kvm. What is the plan about pushing it upstream? Then
Anthony Liguori wrote:
This requires adding the necessary bits to configure to create the directories
and symlinks for libkvm. It also requires sticking KVM_CFLAGS in
config-host.mak to ensure that it gets the right set of includes for the
kernel headers.
v1 => v2
Fix build when objdir == src
Jes Sorensen wrote:
Avi Kivity wrote:
Jes Sorensen wrote:
I pushed my queue into a branch (named 'queue'). Will merge once I
resolve the regressions here.
Hi Avi,
I don't see that branch - it's in the qemu-kvm repo?
Did you run 'git fetch origin'?
--
error compiling committee.c: too
Cornelius Wefelscheid wrote:
Hi,
i tried to get some useful informations out of gdb.
but it just gives me this:
#0 0x004092ba in ?? ()
Do i maybe need to compile KVM with some special debug flags?
Is there no patch that increases the number of CPUS?
Use 'gdb /path/to/qemu core_f
Anthony Liguori wrote:
Previously, the block API only exposed non-vector interfaces and
bounced vectored operations to a linear buffer. That's been
eliminated now though so we need to update the linux-aio patch to
implement a vectored backend interface.
However, it is an apples to apples c
Hi,
i tried to get some useful informations out of gdb.
but it just gives me this:
warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/libm.so.6...(no debugging symbols
found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libz.so.1...(no d
Hollis Blanchard wrote:
dtb is the compiled (binary) form of dts (source) device tree files.
Think of it like bios.bin: if make clean doesn't delete bios.bin (and it
looks like it doesn't), neither should it delete *.dtb, and we can drop
the patch.
Acked-by: Hollis Blanchard
make clean do
Andrew Theurer wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
Avi Kivity wrote:
1) I'm seeing about 2.3% in scheduler functions [that I recognize].
Does that seems a bit excessive?
Yes, it is. If there is a lot of I/O, this might be due to the
thread pool used for I/O.
This is why I wr
On Thu, 2009-04-30 at 12:42 +0300, Avi Kivity wrote:
> Anthony Liguori wrote:
> > It's not in upstream QEMU so apparently it's not useful.
> >
> > Signed-off-by: Anthony Liguori
> > ---
> > pc-bios/Makefile |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/pc-bi
Avi Kivity wrote:
Anthony Liguori wrote:
Avi Kivity wrote:
1) I'm seeing about 2.3% in scheduler functions [that I recognize].
Does that seems a bit excessive?
Yes, it is. If there is a lot of I/O, this might be due to the
thread pool used for I/O.
This is why I wrote the linux-aio patch
Avi Kivity wrote:
Anthony Liguori wrote:
2) cpu_physical_memory_rw due to not using preadv/pwritev?
I think both virtio-net and virtio-blk use memcpy().
With latest linux-2.6, and a development snapshot of glibc,
virtio-blk will not use memcpy() anymore but virtio-net still does on
the r
Avi Kivity wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
This requires adding the necessary bits to configure to create the
directories
and symlinks for libkvm. It also requires sticking KVM_CFLAGS in
config-host.mak to ensure that it gets the right set of includes for
the
kernel headers.
This requires adding the necessary bits to configure to create the directories
and symlinks for libkvm. It also requires sticking KVM_CFLAGS in
config-host.mak to ensure that it gets the right set of includes for the
kernel headers.
v1 => v2
Fix build when objdir == srcdir
Signed-off-by: Antho
- "yogi" wrote:
> Hello everyone,
>
> I like to submit patch to add support for "remote migration" in
> kvm-autotest.
Sounds like a good idea.
Also, the patch isn't too big, which I personally appreciate very much (makes
it easier to read).
> To use this patch the following four paramet
Avi Kivity wrote:
Jes Sorensen wrote:
I pushed my queue into a branch (named 'queue'). Will merge once I
resolve the regressions here.
Hi Avi,
I don't see that branch - it's in the qemu-kvm repo?
Cheers,
Jes
[...@leavenworth qemu-kvm]$ git branch -a
* master
origin/HEAD
origin/bios-m
Avi Kivity wrote:
Anthony Liguori wrote:
Avi Kivity wrote:
1) I'm seeing about 2.3% in scheduler functions [that I recognize].
Does that seems a bit excessive?
Yes, it is. If there is a lot of I/O, this might be due to the
thread pool used for I/O.
This is why I wrote the linux-aio patch
yogi wrote:
Hello everyone,
I like to submit patch to add support for "remote migration" in
kvm-autotest.
Thanks for the patch, Uri is out on vacation for a while. I'll apply the
patch to my test repo and do some validation testing, however may be a
little while untill it makes it in.
-D
Anthony Liguori wrote:
Avi Kivity wrote:
1) I'm seeing about 2.3% in scheduler functions [that I recognize].
Does that seems a bit excessive?
Yes, it is. If there is a lot of I/O, this might be due to the
thread pool used for I/O.
This is why I wrote the linux-aio patch. It only reduced
Anthony Liguori wrote:
2) cpu_physical_memory_rw due to not using preadv/pwritev?
I think both virtio-net and virtio-blk use memcpy().
With latest linux-2.6, and a development snapshot of glibc, virtio-blk
will not use memcpy() anymore but virtio-net still does on the receive
path (but no
Avi Kivity wrote:
Anthony Liguori wrote:
This requires adding the necessary bits to configure to create the
directories
and symlinks for libkvm. It also requires sticking KVM_CFLAGS in
config-host.mak to ensure that it gets the right set of includes for the
kernel headers.
Applied, thanks
Andrew Theurer wrote:
disk:read: 17 MB/sec write: 40 MB/sec
This could definitely cause the extra load, especially if it's many
small requests (compared to a few large ones).
I don't have the request sizes at my fingertips, but we have to use a
lot of disks to support this I/O, so I
> From: Avi Kivity [mailto:a...@redhat.com]
> Sent: Thursday, April 30, 2009 5:31 AM
>
> Sheng Yang wrote:
> > Intel TXT(Trusted Execution Technology) required VMX off for all cpu to work
> > when system shutdown.
> >
>
> Applied, thanks.
>
> Is this needed for 2.6.30 and -stable? That is, is the
Andrew Theurer wrote:
Really, I think linux-aio support can help here.
Yes, I think that would work for real block devices, but would that
help for files? I am using real block devices right now, but it would
be nice to also see a benefit for files in a file-system. Or maybe I
am mis-unders
Avi Kivity wrote:
Andrew Theurer wrote:
Avi Kivity wrote:
What's the typical I/O load (disk and network bandwidth) while the
tests are running?
This is average thrgoughput:
network:Tx: 79 MB/sec Rx: 5 MB/sec
MB as in Byte or Mb as in bit?
Byte. There are 4 x 1 Gb adapters, each han
Avi Kivity wrote:
1) I'm seeing about 2.3% in scheduler functions [that I recognize].
Does that seems a bit excessive?
Yes, it is. If there is a lot of I/O, this might be due to the thread
pool used for I/O.
This is why I wrote the linux-aio patch. It only reduced CPU
consumption by abou
Anthony Liguori wrote:
This requires adding the necessary bits to configure to create the directories
and symlinks for libkvm. It also requires sticking KVM_CFLAGS in
config-host.mak to ensure that it gets the right set of includes for the
kernel headers.
Applied, thanks.
--
error compilin
Alex Williamson wrote:
On Wed, 2009-04-29 at 15:53 -0500, Anthony Liguori wrote:
-#define VIRTIO_NET_VM_VERSION6
+/* Version 7 has TAP_VNET_HDR support. This is reserved in upstream QEMU to
+ * avoid future conflict.
+ * We can't assume verisons > 7 have TAP_VNET_HDR support until this i
Anthony Liguori wrote:
Oh okay. But signal delivery is slow; for example the FPU needs to
be reset.
Is it really justified to add all of this extra code (including
signalfd emulation) for something that probably isn't even measurable?
We don't have to add signalfd emulation; we can simply
Avi Kivity wrote:
Anthony Liguori wrote:
In modern KVM, the IO thread is capable of interrupting the CPU
whenever it needs to process IO. Therefore this "problem" no longer
exists.
It would still be good to verify that the problem no longer exists.
This is not a cosmetic change; some tes
Avi Kivity wrote:
Anthony Liguori wrote:
Right now, there is no way savevm versioning can be compatible with
upstream
QEMU because KVM adds fields to existing savevm structures without
incrementing
the versions.
If you assume that KVM will eventually merge into upstream QEMU, this
means that
Anthony Liguori wrote:
This isn't in upstream QEMU and is of little utility to KVM. It's
unlikely
to appear in upstream QEMU either.
Since we allow overriding cpuid flags, why not the vendor string?
It's necessary for cpu passthrough.
But we don't allow explicit override of cpuid flags
Anthony Liguori wrote:
Right now, there is no way savevm versioning can be compatible with upstream
QEMU because KVM adds fields to existing savevm structures without incrementing
the versions.
If you assume that KVM will eventually merge into upstream QEMU, this means that
eventually KVM is goi
Avi Kivity wrote:
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
We don't use signalfd in upstream QEMU. Instead, we always emulate
it.
With an extra thread -> so an extra context switch.
We don't use an extra thread. We just install a signal handler that
writes to a
Avi Kivity wrote:
Anthony Liguori wrote:
This isn't in upstream QEMU and is of little utility to KVM. It's
unlikely
to appear in upstream QEMU either.
Since we allow overriding cpuid flags, why not the vendor string?
It's necessary for cpu passthrough.
But we don't allow explicit over
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
Signed-off-by: Anthony Liguori
---
vl.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/vl.c b/vl.c
index 3b0e3dc..848a8f8 100644
--- a/vl.c
+++ b/vl.c
@@ -1367,8 +1367,7 @@ static void host_alarm_handl
Avi Kivity wrote:
Ah, ok, will apply. But that's not in upstream either.
Nope, but one step at a time.
--
Regards,
Anthony Liguori
--
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.kern
Avi Kivity wrote:
Anthony Liguori wrote:
Signed-off-by: Anthony Liguori
---
vl.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/vl.c b/vl.c
index 3b0e3dc..848a8f8 100644
--- a/vl.c
+++ b/vl.c
@@ -1367,8 +1367,7 @@ static void host_alarm_handler(int host_signum)
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
This has been consistently nacked in upstream QEMU.
-#if defined(__linux__)
-#define __user
-#endif
-
This will introduce a regression into qemu-kvm.git.
It won't because -D__user is in CFLAGS.
Ah, ok, will apply. But t
Anthony Liguori wrote:
This isn't in upstream QEMU and is of little utility to KVM. It's
unlikely
to appear in upstream QEMU either.
Since we allow overriding cpuid flags, why not the vendor string?
It's necessary for cpu passthrough.
But we don't allow explicit override of cpuid flags
Avi Kivity wrote:
Anthony Liguori wrote:
This has been consistently nacked in upstream QEMU.
Signed-off-by: Anthony Liguori
---
usb-linux.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/usb-linux.c b/usb-linux.c
index 26643bd..70d7a1c 100644
--- a/usb-linux.c
+++
Avi Kivity wrote:
Anthony Liguori wrote:
This isn't in upstream QEMU and is of little utility to KVM. It's
unlikely
to appear in upstream QEMU either.
Since we allow overriding cpuid flags, why not the vendor string?
It's necessary for cpu passthrough.
But we don't allow explicit over
Avi Kivity wrote:
@@ -1585,12 +1585,11 @@ static void vga_sync_dirty_bitmap(VGAState *s)
*/
static void vga_draw_graphic(VGAState *s, int full_update)
{
-int y1, y, update, linesize, y_start, double_scan, mask, depth;
-int width, height, shift_control, line_offset, bwidth, bits;
+
On Mon, Apr 27, 2009 at 02:33:34PM -0400, Gregory Haskins wrote:
> This allows an eventfd to be registered as an irq source with a guest. Any
> signaling operation on the eventfd (via userspace or kernel) will inject
> the registered GSI at the next available window.
>
> Signed-off-by: Gregory Ha
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
We don't use signalfd in upstream QEMU. Instead, we always emulate it.
With an extra thread -> so an extra context switch.
We don't use an extra thread. We just install a signal handler that
writes to a pipe. At best, th
Andrew Theurer wrote:
Avi Kivity wrote:
What's the typical I/O load (disk and network bandwidth) while the
tests are running?
This is average thrgoughput:
network:Tx: 79 MB/sec Rx: 5 MB/sec
MB as in Byte or Mb as in bit?
disk:read: 17 MB/sec write: 40 MB/sec
This could defin
Avi Kivity wrote:
Anthony Liguori wrote:
We don't use signalfd in upstream QEMU. Instead, we always emulate it.
With an extra thread -> so an extra context switch.
We don't use an extra thread. We just install a signal handler that
writes to a pipe. At best, the added overhead is that
Avi Kivity wrote:
Andrew Theurer wrote:
I wanted to share some performance data for KVM and Xen. I thought it
would be interesting to share some performance results especially
compared to Xen, using a more complex situation like heterogeneous
server consolidation.
The Workload:
The workload is
Sheng Yang wrote:
Intel TXT(Trusted Execution Technology) required VMX off for all cpu to work
when system shutdown.
Applied, thanks.
Is this needed for 2.6.30 and -stable? That is, is the code that
enables TXT in 2.6.30 and below or in the BIOS? Or is it new code not
yet merged?
--
Sheng Yang wrote:
Shadow_mt_mask is out of date, now it have only been used as a flag to indicate
if TDP enabled. Get rid of it and use tdp_enabled instead.
Also put memory type logical in kvm_x86_ops->get_mt_mask().
Applied both, thanks.
--
error compiling committee.c: too many arguments
Hello everyone,
I like to submit patch to add support for "remote migration" in
kvm-autotest.
To use this patch the following four parameters should be added to the
existing migration test
remote = dst
hostip =
remoteip =
remuser = root
rempassword =
t
Michael S. Tsirkin wrote:
CONFIG_KVM_TRACE in kernel conflicts with the definition
in external module. external-module-compat-comm.h tried
to work around this, but this didn't work as some
code still does #include
directly.
Solve this differently by s/CONFIG_KVM_TRACE/CONFIG_KMOD_KVM_TRACE/
in
Glauber Costa wrote:
we currently unblock shadow interrupt state when we skip an instruction,
but failing to do so when we actually emulate one. This blocks interrupts
in key instruction blocks, in particular sti; hlt; sequences
If the instruction emulated is an sti, we have to block shadow inte
Chris Wright wrote:
The irq handler changes (introduced in 2.6.19, not 2.6.20) dropped
struct pt_regs from the handler prototype, they are found globally now.
This introduces the back compat for older kernels. The handler is just
a thin layer which calls the real registered handler (all this to
Jan Kiszka wrote:
Signed-off-by: Jan Kiszka
---
monitor.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/monitor.c b/monitor.c
index 11e48c7..674630b 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1792,7 +1792,6 @@ static const mon_cmd_t mon_cmds[] = {
Jan Kiszka wrote:
Avi Kivity wrote:
Where/how does the
migration code disable dirty logging?
Should be phase 3 of ram_save_live().
But only in qemu-kvm. What is the plan about pushing it upstream? Then
we could discuss how to extend the exiting support best
Anthony Liguori wrote:
Now that we've got qemu-kvm, it's pretty easy to look at what's different
between upstream QEMU and qemu-kvm.
This was actually easy in kvm-userspace.git: git diff origin/master
origin/qemu-svn/trunk.
Unfortunately, there's still a lot of
gunk that seems to keep sur
Anthony Liguori wrote:
Signed-off-by: Anthony Liguori
---
vl.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/vl.c b/vl.c
index 3b0e3dc..848a8f8 100644
--- a/vl.c
+++ b/vl.c
@@ -1367,8 +1367,7 @@ static void host_alarm_handler(int host_signum)
last_clock = t
Anthony Liguori wrote:
This has been consistently nacked in upstream QEMU.
Signed-off-by: Anthony Liguori
---
usb-linux.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/usb-linux.c b/usb-linux.c
index 26643bd..70d7a1c 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -
Anthony Liguori wrote:
It's not in upstream QEMU so apparently it's not useful.
Signed-off-by: Anthony Liguori
---
pc-bios/Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/pc-bios/Makefile b/pc-bios/Makefile
index dabeb4c..315288d 100644
--- a/pc-bios/Makefile
Anthony Liguori wrote:
This isn't in upstream QEMU and is of little utility to KVM. It's unlikely
to appear in upstream QEMU either.
Since we allow overriding cpuid flags, why not the vendor string? It's
necessary for cpu passthrough.
--
error compiling committee.c: too many arguments t
Anthony Liguori wrote:
If this change should happen, it should happen in upstream QEMU.
Signed-off-by: Anthony Liguori
---
hw/virtio-console.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/virtio-console.c b/hw/virtio-console.c
index 89e8be0..b263281 100644
--- a
Anthony Liguori wrote:
I looked closely at the vga code in kvm-userspace a while ago and merged
every fix I could understand into upstream QEMU. This particular change makes
no sense to me. I could not figure out from revision history what it actually
fixed. I'm fairly certain it's not useful
Anthony Liguori wrote:
Signed-off-by: Anthony Liguori
---
hw/vga.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/hw/vga.c b/hw/vga.c
index 4931b69..d96f1be 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -1585,12 +1585,11 @@ static void vga_sync_dirty_bitmap(VGAState *s)
Avi Kivity wrote:
Where/how does the
migration code disable dirty logging?
>>> Should be phase 3 of ram_save_live().
>>>
>>
>> But only in qemu-kvm. What is the plan about pushing it upstream? Then
>> we could discuss how to extend the exiting support best.
>>
>
> P
Anthony Liguori wrote:
We don't use signalfd in upstream QEMU. Instead, we always emulate it.
With an extra thread -> so an extra context switch.
It's not necessarily a bad thing to use signalfd, but this is something that
should be done upstream. It certainly does qemu-kvm no harm to us
Jes Sorensen wrote:
Zhang, Xiantao wrote:
Jes Sorensen wrote:
The main difference is that my patch cleans up the interfaces and
calls to the various functions, and removes a bunch of global
variables as well.
I still can't see the difference with the patch in Avi's tree except
nvram stuff.
Jan Kiszka wrote:
That's sort of what's implemented in qemu-kvm.git. In qemu.git vga
logging does not get disabled, which is really broken. It prevents
optimizations like disabling logging when the screen is not displayed to
a human.
Is there a channel that tells vga "nothing will be dis
Zhang, Xiantao wrote:
Jes Sorensen wrote:
The main difference is that my patch cleans up the interfaces and
calls to the various functions, and removes a bunch of global
variables as well.
I still can't see the difference with the patch in Avi's tree except nvram
stuff. And I believe the gl
Bernhard Kohl wrote:
I'm trying to clone this new repository using the http protocol because I'm
behind a proxy. I get the following error. For kvm.git and qemu-kvm.git this
works well.
$ git clone http://www.kernel.org/pub/scm/virt/kvm/kvm-kmod.git
Initialized empty Git repository in /home/bern
Anthony Liguori wrote:
Kapadia, Vivek wrote:
I came across this thread looking for an efficient event channel
mechanism between two guests (running on different cpu cores).
While I can use available emulated IO mechanism (guest1->host kernel
driver->Qemu1->Qemu2) in conjunction with interrupt
Andrew Theurer wrote:
I wanted to share some performance data for KVM and Xen. I thought it
would be interesting to share some performance results especially
compared to Xen, using a more complex situation like heterogeneous
server consolidation.
The Workload:
The workload is one that simulates
MCE features are detected, initialized and injected via the
corresponding KVM ioctl.
Signed-off-by: Huang Ying
---
kvm-all.c| 24 ++
kvm.h|4 +++
target-i386/helper.c |8 +-
target-i386/kvm.c| 67 +++
- MCE features are initialized when VCPU is intialized according to CPUID.
- A monitor command "mce" is added to inject a MCE.
- A new interrupt mask: CPU_INTERRUPT_MCE is added to inject the MCE.
Signed-off-by: Huang Ying
---
cpu-all.h |4 ++
cpu-exec.c |4 ++
Xu, Jiajun wrote:
Yes. If booting guest with -no-kvm, X display can work well. And I am using
bridge network, so still can not get network up. :(
And qemu cpu utilization is still ~100%.
The last merge with qemu.git broke both vga and networking. Mark fixed
networking, we're still looking
walt wrote:
When building on x86 I get this error:
make[2]: Entering directory `/home/wa1ter/src/qemu-kvm/kvm/libkvm'
make[2]: *** No rule to make target
`/home/wa1ter/src/qemu-kvm/kvm/kernel/include/asm/kvm.h', needed by `libkvm.o'.
I fixed it by adding the same symlink that I add to Linus's k
Bugs item #2638990, was opened at 2009-02-25 23:35
Message generated for change (Comment added) made by ivanvimes
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2638990&group_id=180599
Please note that this message will contain a full copy of the comment
Move Double-Fault generation logic out of page fault
exception generating function to cover more generic case.
Signed-off-by: Eddie Dong
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index ab1fdac..51a8dad 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -162,
99 matches
Mail list logo
