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
> 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 tr
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 i
> 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
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
wrote:
> Right now autotest will drop caches
Patchset applied, thanks!
On Wed, Nov 4, 2009 at 12:05 PM, Michael Goldish 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.
>
> Signed-off-by: Mic
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, thi
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, wha
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 s
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
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
Buil
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
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 intern
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 sh
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
I am OK with it, applied, thanks!
On Tue, Nov 3, 2009 at 4:27 AM, Yolkfull Chow 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 params_verify
>
>
> Signe
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.
Righ
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.
Th
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, th
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
> ---
> drivers/vhost/
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 interes
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 ris
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 a
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
There were a couple unlocks missing. They were found by smatch static
checker. Compile tested.
regards,
dan carpenter
Signed-off-by: Dan Carpenter
--- orig/virt/kvm/irq_comm.c2009-11-08 19:00:50.0 +0200
+++ devel/virt/kvm/irq_comm.c 2009-11-08 19:04:45.0 +0200
@@ -209,6
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
26 matches
Mail list logo
