In the testing for kvm59rc1, we found that 64bit SMP windows guests
cannot boot on kvm59rc1. The guest will hang during boot. UP Windows has
no problem.
A call trace error has been found in dmesg:
do_ioctl: ioctl 80385ab1 disappeared
symbol: tty_ioctl+0x0/0xc42
Call Trace:
Carlo Marcelo Arenas Belon wrote:
Avi,
now that vgabios has been merged, would be probably a good idea to
remove the unused vgabios BLOBs in the bios directory which were left
from the import of the BOCHS bios (I have a patch but felt bad about
sending it out with up to 96K) :
On Wed, Jan 02, 2008 at 04:14:53PM +0800, Zhang, Xiantao wrote:
Carlo Marcelo Arenas Belon wrote:
I'll let the specifics to all the portability interested parties (I
mostly use PC) but would suspect something similar to the work done
for the code should be most likely what is needed :
Carlo Marcelo Arenas Belon wrote:
On Tue, Jan 01, 2008 at 06:37:23PM +0200, Avi Kivity wrote:
Carlo Marcelo Arenas Belon wrote:
if nothing is available hp's testdrive have some itanium systems that
could be
used at least to validate the userspace part builds (as I did) :
Carlo Marcelo Arenas Belon wrote:
Avi,
now that vgabios has been merged, would be probably a good idea to remove the
unused vgabios BLOBs in the bios directory which were left from the import of
the BOCHS bios (I have a patch but felt bad about sending it out with up to
96K) :
Dong, Eddie wrote:
clean the redundant level check when fetching
shadow pte for present non-present spte.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is
Carlo Marcelo Arenas Belon wrote:
We also need to upload the ia64 firmware for kvm, and make it
available for users use. At least, we need to provide the binary.
beware that actually providing the binary without sources might be a problem
for some distributions (like debian and
Avi Kivity wrote:
Carlo Marcelo Arenas Belon wrote:
We also need to upload the ia64 firmware for kvm, and make it
available for users use. At least, we need to provide the binary.
beware that actually providing the binary without sources might be a
problem for some distributions (like
Dong, Eddie wrote:
Current shadow code do prefetch in FNAME(prefetch_page), but it is only
used
to choose shadow_notrap_nonpresent_pte or shadow_trap_nonpresent_pte.
At least for L1 shadow, prefetching to get exact shadow L1 pte won't
cause
performance regression (though handling time
Zhang, Xiantao wrote:
Note that we ship x86 binaries for two reasons:
- qemu does it that way, and we inherited it, before the need arose to
make modifications
- obscure tools are needed to build the binaries (iasl and dev86)
Since ia64 doesn't have these issues (is that right?) then we can
Carlo Marcelo Arenas Belon wrote:
On Wed, Jan 02, 2008 at 04:14:53PM +0800, Zhang, Xiantao wrote:
Carlo Marcelo Arenas Belon wrote:
I'll let the specifics to all the portability interested parties (I
mostly use PC) but would suspect something similar to the work done
for the code should be
On Wed, Jan 02, 2008 at 05:46:04PM +0800, Zhang, Xiantao wrote:
Avi Kivity wrote:
Carlo Marcelo Arenas Belon wrote:
We also need to upload the ia64 firmware for kvm, and make it
available for users use. At least, we need to provide the binary.
beware that actually providing the
The following patch series implement a configure passthrough for qemu so that
all available configure options in qemu can be used through kvm.
This includes all suggestions from the 3 first RFC and complements the patches
that were needed from qemu's side and that were brought back through the
This reverts commit 49f7f1a96dce9d059d2d51d450c9d4bdd529c8fd.
---
configure |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/configure b/configure
index dadda8e..715e12f 100755
--- a/configure
+++ b/configure
@@ -7,7 +7,6 @@ qemu_cc=
qemu_cflags=
qemu_ldflags=
Bugs item #1862119, was opened at 2008-01-02 19:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=1862119group_id=180599
Please note that this message will contain a full copy of
This reverts commit d3bcc58f74b29df8496933c441640d9c739ba674.
Conflicts:
configure (remove hardcoded alsa flag but keep qemu_opts)
Signed-off-by: Carlo Marcelo Arenas Belon [EMAIL PROTECTED]
---
configure |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git
This reverts commit 0d354fe9d8eaee1b3abc9dee7824021edb9f4976.
Conflicts:
configure (keep --disable-gcc-check usage)
Signed-off-by: Carlo Marcelo Arenas Belon [EMAIL PROTECTED]
---
configure |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/configure
uses qemu to generate a hopefully complete usage in case of error
Signed-off-by: Carlo Marcelo Arenas Belon [EMAIL PROTECTED]
---
configure | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/configure b/configure
index 50a0e90..0464456 100755
--- a/configure
+++
I've just got an upgrade to KVM-58 as part of the latest Fedora.
Unfortunately my existing VM (a Windows 2008 Server instance) no longer
boots. In fact it hardly gets anywhere at all. Immediately after
running qemu-kvm, I just get a black screen (no BIOS/boot messages at
all) and using 100%
Richard W.M. Jones wrote:
I've just got an upgrade to KVM-58 as part of the latest Fedora.
Unfortunately my existing VM (a Windows 2008 Server instance) no
longer boots. In fact it hardly gets anywhere at all. Immediately
after running qemu-kvm, I just get a black screen (no BIOS/boot
Avi Kivity wrote:
Richard W.M. Jones wrote:
I've just got an upgrade to KVM-58 as part of the latest Fedora.
Unfortunately my existing VM (a Windows 2008 Server instance) no
longer boots. In fact it hardly gets anywhere at all. Immediately
after running qemu-kvm, I just get a black screen
Dan Kenigsberg wrote:
On Wed, Jan 02, 2008 at 12:08:12PM +, Richard W.M. Jones wrote:
I've just got an upgrade to KVM-58 as part of the latest Fedora.
Unfortunately my existing VM (a Windows 2008 Server instance) no longer
boots. In fact it hardly gets anywhere at all. Immediately after
Avi Kivity wrote:
Can you identify which version of kvm introduced the regression?
Some more data points:
kvm-56 from [1] == works OK
kvm-57 from [2] == works OK
kvm-58 from [1] == hangs with black screen at boot
kvm-58 from [2] == hangs with black screen at boot
In all
Dong, Eddie wrote:
Current shadow code do prefetch in FNAME(prefetch_page), but
it is only
used
to choose shadow_notrap_nonpresent_pte or shadow_trap_nonpresent_pte.
At least for L1 shadow, prefetching to get exact shadow L1 pte won't
cause
performance regression (though handling time
Avi Kivity wrote:
Richard W.M. Jones wrote:
Avi Kivity wrote:
Can you identify which version of kvm introduced the regression?
Some more data points:
kvm-56 from [1] == works OK
kvm-57 from [2] == works OK
kvm-58 from [1] == hangs with black screen at boot
kvm-58 from [2]
Richard W.M. Jones wrote:
Please try reverting the attached patch (or applying it to a working
version).
If that doesn't work, try bios.bin from a working version with a
non-working qemu.
No, I'm afraid that taking kvm-58 and applying that patch reversed (to
remove it) does not work.
Avi Kivity wrote:
If that doesn't work, try bios.bin from a working version with a
non-working qemu.
I've just read the second part now ...
I took bios.bin, vgabios.bin and vgabios-cirrus.bin from KVM-57 and used
them to overwrite the corresponding files in KVM-58, and that did not
work
Please see this site in Subject
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
Richard W.M. Jones wrote:
Avi Kivity wrote:
If that doesn't work, try bios.bin from a working version with a
non-working qemu.
I've just read the second part now ...
I took bios.bin, vgabios.bin and vgabios-cirrus.bin from KVM-57 and
used them to overwrite the corresponding files in
Avi Kivity wrote:
Richard W.M. Jones wrote:
Avi Kivity wrote:
If that doesn't work, try bios.bin from a working version with a
non-working qemu.
I've just read the second part now ...
I took bios.bin, vgabios.bin and vgabios-cirrus.bin from KVM-57 and
used them to overwrite the
This patch adds support to QEMU for extboot. It requires that an extboot.bin
binary be copied into the pc-bios directory or else make install will not
function properly.
To use extboot to boot from an arbitrary block device, simply append a
,boot=on to the block device to boot from. For
extboot is an x86 Option ROM that passes through int13 functions to a VMM which
allows a VMM to expose an arbitrary block device as the primary BIOS disk. It
can be used to boot SCSI or paravirtual devices.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/extboot/Makefile
Bugs item #1862315, was opened at 2008-01-02 22:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=1862315group_id=180599
Please note that this message will contain a full copy of
Richard W.M. Jones wrote:
Avi Kivity wrote:
Richard W.M. Jones wrote:
Avi Kivity wrote:
If that doesn't work, try bios.bin from a working version with a
non-working qemu.
I've just read the second part now ...
I took bios.bin, vgabios.bin and vgabios-cirrus.bin from KVM-57 and
used
Anthony Liguori wrote:
I think we should hold off on this sort of patch at first. I know it
improves performance, but it's very hack-ish. I have a similar patch[1]
that improves performance more but is even more hack-ish.
I think we have to approach this by not special cases virtio-net to
On Wed, 2008-01-02 at 19:13 +0200, Avi Kivity wrote:
Can you try the option '-no-kvm' both with kvm-57 and kvm-58?
-no-kvm works. I can hit this just booting a live CD both on a 32bit
and a 64bit host. It looks like compatibility with old kernels is
broken (the kvm package only contains the
On Sat, 2007-12-22 at 22:25 +0200, Avi Kivity wrote:
Amit Shah wrote:
On Friday 21 December 2007 20:28:23 Zhang, Xiantao wrote:
Hi, Avi
Due to last merge with Qemu upstream, some interfaces are changed, and
leads to build fail
, this patch fixed them.
Xiantao
I've not
Hello people!
I am new to the KVM community. I found it really exciting and am interested in
contributing to the project. I found a TODO list at the site and decided to
work on the following one.
Add a qemu interface for sharing memory between guests. Using a pci device to
expose the shared
# HG changeset patch
# User Jerone Young [EMAIL PROTECTED]
# Date 1199304626 21600
# Node ID 2eddb4bcae5e444ba12b2d8985e494342e505131
# Parent 8161d444f7c37be9bdbfaac338d58301b00f2961
Add powerpc libkvm support code
This patch adds implimentation code need for powerpc libkvm support.
While the
What is the plan here, to ifdef the arch-specific callbacks? If so,
'tpr_access' is an obvious candidate...
--
Hollis Blanchard
IBM Linux Technology Center
On Wed, 2008-01-02 at 14:29 -0600, Jerone Young wrote:
# HG changeset patch
# User Jerone Young [EMAIL PROTECTED]
# Date 1199305658
That would be my sketchy idea. Though I was going to wait and see what
the feedback would be doing this :-) It can go either way. Since it's
just callbacks it really doesn't matter. But it does affect the
structure size never the less.
So what are everyone thoughs about arch specific callbacks ?
Qumranet was kind enough to donate a set of vendor/device IDs for virtio
devices. This patch switches over to using them instead of an unreserved
vendor ID.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c
index
This patch changes the virtio_pci license to be GPL2 or later.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c
index 45ff193..f8df571 100644
--- a/drivers/virtio/virtio_pci.c
+++ b/drivers/virtio/virtio_pci.c
@@ -9,8 +9,8 @@
Hi,
I've posted a repo that contains my initial attempt at backporting the
virtio modules. I've tested against a 2.6.22, 2.6.20, and 2.6.18 kernel
(although I haven't tried the block device against 2.6.18). It requires
Rusty's patch queue plus the three patches I just sent to
[EMAIL
Just to be clear, to use this repository, you need a kernel tree with
Rusty's virtio patch queue applied.
For instance, if you had the latest KVM git tree, you would then need to
get Rusty's queue at http://ozlabs.org/~rusty/kernel/hg.I apply up
to
Avi Kivity wrote:
Anthony Liguori wrote:
I think we should hold off on this sort of patch at first. I know it
improves performance, but it's very hack-ish. I have a similar
patch[1] that improves performance more but is even more hack-ish.
I think we have to approach this by not special
Curuious: should we consider it to be dual licensed from beginning?
thx,eddie
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Anthony Liguori
Sent: 2008年1月3日 5:02
To: [EMAIL PROTECTED]
Cc: kvm-devel@lists.sourceforge.net
Subject: [kvm-devel] [PATCH 1/3]
On Thursday 03 January 2008 08:01:34 Anthony Liguori wrote:
Qumranet was kind enough to donate a set of vendor/device IDs for virtio
devices. This patch switches over to using them instead of an unreserved
vendor ID.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
All applied, thanks!
Hi, all
We have booted up smp guests on kvm/ia64 with 4 virtual processors.
Attached the screen snapshot. :-)
I will refine the code, and send it our for review.
Xiantao
attachment: 2.png-
This SF.net email is sponsored by:
I have kvm-amd working fine.
when I am at my desktop everything works normal.
However, when I vncviewer into my desktop and startup my
session I mouse over the XP desktop but I cannot click in the desktop
and make it active. I get the little square mouse pointer.
I have to do the crl-alt to
50 matches
Mail list logo
