Hi all,
a late response of my part, but I got it partially working under
slackware 13.0 with the qemu-kvm-0.11.0.tar.gz (it compiles now without
errors.)
When I start my virtual machine in *windowed mode* it boots fine,It
installs the OS I want but everything is black around the windowed
There were a couple unlocks missing. They were found by smatch static
checker. Compile tested.
regards,
dan carpenter
Signed-off-by: Dan Carpenter erro...@gmail.com
--- orig/virt/kvm/irq_comm.c2009-11-08 19:00:50.0 +0200
+++ devel/virt/kvm/irq_comm.c 2009-11-08
On 11/08/2009 08:42 PM, Daniel Bareiro wrote:
Hi all!
I'm using KVM-88 compiled by myself from the source code provided by the
official site of the project.
Is this version of KVM vulnerable to the mentioned thing in the
DSA-1907-1 [1]?
Yes.
In such case, there is some published patch that
On 11/02/2009 06:20 PM, Jan Kiszka wrote:
Add a new IOCTL pair to retrieve or set the VCPU state in one chunk.
More precisely, the IOCTL is able to process a list of substates to be
read or written. This list is easily extensible without breaking the
existing ABI, thus we will no longer have to
On 11/02/2009 06:20 PM, Jan Kiszka wrote:
Obviously, people tend to extend this header at the bottom - more or
less blindly. Ensure that deprecated stuff gets its own corner again by
moving things to the top. Also add some comments and reindent IOCTLs to
make them more readable and reduce the
Avi Kivity wrote:
I recommend to use distro-provided modules (or kernel.org kernels
within their support period) for production use. This ensures you get
security and stability fixes. kvm-89 will fix these issues, but as
it's a development snapshot, may introduce new issues.
This is
On Tue, Nov 10, 2009 at 01:49:09PM +1030, Rusty Russell wrote:
One fix:
vhost: fix TUN=m VHOST_NET=y
drivers/built-in.o: In function `get_tun_socket':
net.c:(.text+0x15436e): undefined reference to `tun_get_socket'
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
Avi Kivity wrote:
On 11/02/2009 06:20 PM, Jan Kiszka wrote:
Add a new IOCTL pair to retrieve or set the VCPU state in one chunk.
More precisely, the IOCTL is able to process a list of substates to be
read or written. This list is easily extensible without breaking the
existing ABI, thus we
Asdo wrote:
Avi Kivity wrote:
I recommend to use distro-provided modules (or kernel.org kernels
within their support period) for production use. This ensures you get
security and stability fixes. kvm-89 will fix these issues, but as
it's a development snapshot, may introduce new issues.
On 11/10/2009 02:03 PM, Jan Kiszka wrote:
I'm having some second thoughts about this.
What does the new API buy us? Instead of declaring two new ioctls for
new/fixed substates, we only have to declare one. We still have the
capability check. We still have to declare a structure.
I am OK with it, applied, thanks!
On Tue, Nov 3, 2009 at 4:27 AM, Yolkfull Chow yz...@redhat.com wrote:
We may need leave smp as standalone parameter of VM. Reasons I can proposal:
1) memory is a standalone parameter, so is smp
2) smp parameter is needed in some test case, say VM
Avi Kivity wrote:
On 11/10/2009 02:03 PM, Jan Kiszka wrote:
I'm having some second thoughts about this.
What does the new API buy us? Instead of declaring two new ioctls for
new/fixed substates, we only have to declare one. We still have the
capability check. We still have to declare a
On 11/10/2009 03:22 PM, Jan Kiszka wrote:
Since we have very few variable-size states, and their number is
unlikely to increase, ad-hoc handling should be sufficient.
Regarding CPU states, there is actually only the MSR interface.
cpuid internal states too.
So the new roadmap
Avi Kivity wrote:
On 11/10/2009 03:22 PM, Jan Kiszka wrote:
Since we have very few variable-size states, and their number is
unlikely to increase, ad-hoc handling should be sufficient.
Regarding CPU states, there is actually only the MSR interface.
cpuid internal states too.
The Buildbot has detected a new failure of default_x86_64_out_of_tree on
qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/default_x86_64_out_of_tree/builds/87
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this Build: b1_qemu_kvm_1
The Buildbot has detected a new failure of default_i386_out_of_tree on qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/default_i386_out_of_tree/builds/85
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this Build: b1_qemu_kvm_2
Thanks for your reply,
sorry to get you angry, but there are still things which are not clear
to me.
Please note that if you try to search kvm kvm-kmod kvm-qemu with
google you will discover that basically nothing comes out telling you
the differences between the three. Now searching within
Asdo wrote:
Thanks for your reply,
sorry to get you angry, but there are still things which are not clear
to me.
Well, today wasn't my best day.
You're right the documentation on the matter is nearly non-existing.
[]
3) Everyone here mentions to upgrade the userspace part only. That
sounds
Great, thanks for your reply!
All clear, except one thing, pls see ---
Michael Tokarev wrote:
2.6.31.5
2.6.30
2.6.30.1
2.6.30-rc8
2.6.30-rc6
I don't undestand why they are numbered like the kernel, that's
strange... More specifically, this is the question: If I have a
kernel version N,
Patchset applied, thanks!
On Wed, Nov 4, 2009 at 12:05 PM, Michael Goldish mgold...@redhat.com wrote:
Add a command to setuprss.bat that disables the password prompt on resuming
from hibernation.
Note that for this change to take effect the local winutils.iso should be
updated as well.
Asdo wrote:
Great, thanks for your reply!
All clear, except one thing, pls see ---
Michael Tokarev wrote:
2.6.31.5
2.6.30
2.6.30.1
2.6.30-rc8
2.6.30-rc6
I don't undestand why they are numbered like the kernel, that's
strange... More specifically, this is the question: If I have a
Will this code actually work on a standalone client job? I'm not sure
we've ever used global_config stuff outside of the server (despite the
fact that the code lives in the common_lib).
-- John
On Thu, Nov 5, 2009 at 12:23 PM, Lucas Meneghel Rodrigues
l...@redhat.com wrote:
Right now autotest
I immediately reproduced the problem locally. It turns out that
kvm reflects packets coming from one guest NIC on another guest
NIC, and since both are connected to the same bridge we're getting
endless packet storm. To a level when kvm process becomes 100%
busy and does not respond to
Mark McLoughlin wrote:
On Fri, 2009-10-23 at 20:25 +0400, Michael Tokarev wrote:
I've two questions:
o what's the intended usage of all-vlan-equal case, when kvm (or qemu)
reflects packets from one interface to another? It's what bridge
in linux is for, I think.
I don't think
But I certainly do _not_ want to update the SCSI disk
emulation, as this is really quite tied to the SCSI parallel
interface used by the old lsi53c895a.c.
This is completely untrue. scsi-disk.c contains no transport-specific code. It
is deliberately designed to be independent of both the
On Tue, 2009-11-10 at 10:28 -0800, John Admanski wrote:
Will this code actually work on a standalone client job? I'm not sure
we've ever used global_config stuff outside of the server (despite the
fact that the code lives in the common_lib).
Whoops, I just forgot that global_config.ini is a
On 10.11.2009, at 08:20, Benjamin Herrenschmidt wrote:
Hi Alex !
After a bit of digging as to why the karmic installer dies, I found
out
that you don't set the right SRR1 bits when forwarding a program check
exception to the guest.
Cool, thanks for trying things out and debugging them!
On Tue, 2009-11-10 at 11:50 +0100, Alexander Graf wrote:
if ((vcpu-arch.last_inst 0xff0007ff) !=
(INS_DCBZ 0xfff7)) {
+ vcpu-arch.msr |= (vcpu-arch.shadow_msr
0x1full);
What bits are those? It might be
On 10.11.2009, at 22:16, Benjamin Herrenschmidt wrote:
On Tue, 2009-11-10 at 11:50 +0100, Alexander Graf wrote:
if ((vcpu-arch.last_inst 0xff0007ff) !=
(INS_DCBZ 0xfff7)) {
+ vcpu-arch.msr |=
On 11.11.2009, at 02:03, Benjamin Herrenschmidt wrote:
+ li r4,0
mfspr r5,SPRN_HID5
r5 = *HID5
So far so good...
- rldimi r5,r5,6,56
Take r5, remove some bits, write into r5
Hrm... nope :-)
rldimi will insert into the destination (r5) bits 56..57
the
On Wed, 2009-11-11 at 02:06 +0100, Alexander Graf wrote:
On 11.11.2009, at 02:03, Benjamin Herrenschmidt wrote:
+li r4,0
mfspr r5,SPRN_HID5
r5 = *HID5
So far so good...
-rldimi r5,r5,6,56
Take r5, remove some bits, write into r5
Hrm... nope :-)
31 matches
Mail list logo
