On 02/25/2011 03:11 PM, Glauber Costa wrote:
On Thu, 2011-02-24 at 18:54 -0500, Steven Rostedt wrote:
On Thu, 2011-02-24 at 20:48 -0300, Glauber Costa wrote:
On Thu, 2011-02-24 at 18:24 -0500, Steven Rostedt wrote:
On Wed, Feb 23, 2011 at 12:44:14PM -0500, Glauber Costa wrote:
On 02/24/2011 08:08 PM, Alex Williamson wrote:
@@ -207,7 +206,7 @@ struct kvm_mmu_page {
* One bit set per slot which has memory
* in this shadow page.
*/
- DECLARE_BITMAP(slot_bitmap, KVM_MEMORY_SLOTS + KVM_PRIVATE_MEM_SLOTS);
+ unsigned long
On 02/24/2011 07:35 PM, Alex Williamson wrote:
On Thu, 2011-02-24 at 12:06 +0200, Avi Kivity wrote:
On 02/23/2011 09:28 PM, Alex Williamson wrote:
I had forgotten about1M mem, so actually the slot configuration was:
0:1M
1: 1M - 3.5G
2: 4G+
I stacked the deck in favor
Copying netdev: looks like memory corruption in the networking stack.
Archive link: http://www.spinics.net/lists/kvm/msg50651.html (for the
attachment).
On 02/24/2011 11:15 PM, Ruben Kerkhof wrote:
On Tue, Feb 15, 2011 at 18:16, Marcelo Tosattimtosa...@redhat.com wrote:
This and the
On 02/23/2011 10:28 AM, Jan Kiszka wrote:
Replace obsolete qemu-kvm.h with kvm.h in pci.c and build that module
just like upstream does. This fixes non-x86 targets which have no PCI
support.
Thanks, applied to mainline and stable-0.14.
--
error compiling committee.c: too many arguments to
On 02/23/2011 07:44 PM, Glauber Costa wrote:
We've been supporting kvmclock MSRs in the 0x4b564d00-0x4b564dff range
for a while now, but we're not exposing it yet, meaning nobody is using it.
This simple patch takes care of that.
We're exposing them via KVM_GET_SUPPORTED_CPUID, leaf
On 02/26/2011 06:44 PM, Prasad Joshi wrote:
During device assignment the memory pre-fetchable flag was discarded
as the IORESOURCE_PREFETCH was defined as 0x1000 when instead it
should have been 0x2000. Following small patch fixes the problem,
please apply.
Applied, thanks. Note this
On 02/26/2011 06:38 PM, Prasad Joshi wrote:
I pulled the latest qemu-kvm code and configured it with disabled-kvm
and related options. Configuration finishes well, but the compilation
fails.
This is already fixed in tree.
--
error compiling committee.c: too many arguments to function
--
To
On 02/24/2011 11:48 PM, Anthony Liguori wrote:
Signed-off-by: Anthony Liguorialigu...@us.ibm.com
diff --git a/lib/x86/io.h b/lib/x86/io.h
new file mode 100644
index 000..bd6341c
--- /dev/null
+++ b/lib/x86/io.h
@@ -0,0 +1,40 @@
+#ifndef IO_H
+#define IO_H
+
+static inline unsigned char
On 02/24/2011 11:48 PM, Anthony Liguori wrote:
I'm not sure if this was intentional but the QEMU i8259 does not support this
flag. I haven't observed any issues with this but I'll happily admit that
I'm not very aware of what I'm doing here.
Signed-off-by: Anthony Liguorialigu...@us.ibm.com
On 02/24/2011 11:48 PM, Anthony Liguori wrote:
Use the serial port for printf() and use the Bochs bios exit port if the
testdev port isn't available.
This unconditionally switches to use the serial port but tries to use the
testdev exit port since that lets you pass an exit status.
The only
On 02/27/2011 06:44 AM, Avi Kivity wrote:
On 02/24/2011 11:48 PM, Anthony Liguori wrote:
Signed-off-by: Anthony Liguorialigu...@us.ibm.com
diff --git a/lib/x86/io.h b/lib/x86/io.h
new file mode 100644
index 000..bd6341c
--- /dev/null
+++ b/lib/x86/io.h
@@ -0,0 +1,40 @@
+#ifndef IO_H
On 02/27/2011 04:01 PM, Anthony Liguori wrote:
On 02/27/2011 06:44 AM, Avi Kivity wrote:
On 02/24/2011 11:48 PM, Anthony Liguori wrote:
Signed-off-by: Anthony Liguorialigu...@us.ibm.com
diff --git a/lib/x86/io.h b/lib/x86/io.h
new file mode 100644
index 000..bd6341c
--- /dev/null
+++
On 02/21/2011 12:07 PM, Gleb Natapov wrote:
When vm86 is active TR descriptor is updated with vm86 task values,
but selector is left intact. vmx_set_segment() makes sure that if TR
register is written into while vm86 is active the new values are saved
for use after vm86 is deactivated, but since
On 02/21/2011 12:07 PM, Gleb Natapov wrote:
Currently vm86 task is initialized on each real mode entry and vcpu
reset. Initialization is done by zeroing TSS and updating relevant
fields. But since all vcpus are using the same TSS there is a race where
one vcpu may use TSS while other vcpu is
On Sun, Feb 27, 2011 at 05:43:07PM +0200, Avi Kivity wrote:
On 02/21/2011 12:07 PM, Gleb Natapov wrote:
Currently vm86 task is initialized on each real mode entry and vcpu
reset. Initialization is done by zeroing TSS and updating relevant
fields. But since all vcpus are using the same TSS
On 02/27/2011 05:52 PM, Gleb Natapov wrote:
According to my reading of the code, if KVM_SET_TSS_ADDR is not
invoked, the guest would fail both before and after the patch, yes?
Hmmm. Actually no. Before the patch guest that doesn't use KVM_SET_TSS_ADDR
will use the top of slot zero. Should
On 02/27/2011 05:58 PM, Avi Kivity wrote:
The problem with using top of slot
zero is that this memory is available for guest use and we do not even
put it into e820 map as far as I see. Also there are patches floating
around that re-arrange memslots or even put them in a tree. They will
break
On Sun, Feb 27, 2011 at 05:58:54PM +0200, Avi Kivity wrote:
On 02/27/2011 05:52 PM, Gleb Natapov wrote:
According to my reading of the code, if KVM_SET_TSS_ADDR is not
invoked, the guest would fail both before and after the patch, yes?
Hmmm. Actually no. Before the patch guest that
On 02/27/2011 06:12 PM, Gleb Natapov wrote:
On Sun, Feb 27, 2011 at 05:58:54PM +0200, Avi Kivity wrote:
On 02/27/2011 05:52 PM, Gleb Natapov wrote:
According to my reading of the code, if KVM_SET_TSS_ADDR is not
invoked, the guest would fail both before and after the patch, yes?
On 02/21/2011 05:21 AM, Lai Jiangshan wrote:
The hash array of async gfns may still contain some left gfns after
kvm_clear_async_pf_completion_queue() called, need to clear them.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list:
On Sun, Feb 27, 2011 at 06:04:16PM +0200, Avi Kivity wrote:
On 02/27/2011 05:58 PM, Avi Kivity wrote:
The problem with using top of slot
zero is that this memory is available for guest use and we do not even
put it into e820 map as far as I see. Also there are patches floating
around that
On 02/23/2011 04:57 PM, Jan Kiszka wrote:
The only situation where using kernel headers not provided
by qemu itself is when you want to build qemu for older
kernel and omit some features and runtime tests. But this
is hardly a good goal to support.
I don't think the goal of the
On 02/27/2011 06:27 PM, Gleb Natapov wrote:
Or we can keep the old behaviour. If KVM_SET_TSS_ADDR hasn't been
called by the time of the first entry into real mode (the first
KVM_CREATE_VCPU?), use the top of the first slot.
Do we require that KVM_SET_TSS_ADDR is called before first
On Sun, Feb 27, 2011 at 06:31:13PM +0200, Avi Kivity wrote:
On 02/27/2011 06:27 PM, Gleb Natapov wrote:
Or we can keep the old behaviour. If KVM_SET_TSS_ADDR hasn't been
called by the time of the first entry into real mode (the first
KVM_CREATE_VCPU?), use the top of the first slot.
On Fri, Feb 25, 2011 at 10:07:22AM +0100, Jean-Philippe Menil wrote:
Hi,
Each time i try tou use vhost_net, i'm facing a kernel bug.
I do a modprobe vhost_net, and start guest whith vhost=on.
Following is a trace with a kernel 2.6.37, but i had the same
problem with 2.6.36 (cf
I was not aware of the thread. Please cc me directly, or add a keyword
I track - timekeeping, TSC..
Hello Zachary, thanks for Your time looking at this!
That change alone may not bisect well; without further fixes on top of
it, you may end up with a hang or stall, which is likely to
On 2011-02-27 17:28, Avi Kivity wrote:
On 02/23/2011 04:57 PM, Jan Kiszka wrote:
The only situation where using kernel headers not provided
by qemu itself is when you want to build qemu for older
kernel and omit some features and runtime tests. But this
is hardly a good goal to
On Sat, Feb 26, 2011 at 01:29:01PM +0100, Jan Kiszka wrote:
On 2011-02-26 12:43, xming wrote:
When trying to start X (and it loads qxl driver) the kvm process just
crashes.
This is fixed by Gerd's attached patch (taken from rhel repository, don't know
why it wasn't pushed to qemu-kvm
On 2011-02-27 20:03, Alon Levy wrote:
On Sat, Feb 26, 2011 at 01:29:01PM +0100, Jan Kiszka wrote:
On 2011-02-26 12:43, xming wrote:
When trying to start X (and it loads qxl driver) the kvm process just
crashes.
This is fixed by Gerd's attached patch (taken from rhel repository, don't know
From: Gerd Hoffmann kra...@redhat.com
qxl needs to release the qemu lock before calling some libspice
functions (and re-aquire it later). In upstream qemu qxl can just
use qemu_mutex_{unlock,lock}_iothread. In qemu-kvm this doesn't
work, qxl needs additionally save+restore the cpu_single_env
On Sun, Feb 27, 2011 at 08:11:26PM +0100, Jan Kiszka wrote:
On 2011-02-27 20:03, Alon Levy wrote:
On Sat, Feb 26, 2011 at 01:29:01PM +0100, Jan Kiszka wrote:
On 2011-02-26 12:43, xming wrote:
When trying to start X (and it loads qxl driver) the kvm process just
crashes.
This is
On 2011-02-27 20:16, Alon Levy wrote:
On Sun, Feb 27, 2011 at 08:11:26PM +0100, Jan Kiszka wrote:
On 2011-02-27 20:03, Alon Levy wrote:
On Sat, Feb 26, 2011 at 01:29:01PM +0100, Jan Kiszka wrote:
On 2011-02-26 12:43, xming wrote:
When trying to start X (and it loads qxl driver) the kvm
On Sun, Feb 27, 2011 at 08:27:01PM +0100, Jan Kiszka wrote:
On 2011-02-27 20:16, Alon Levy wrote:
On Sun, Feb 27, 2011 at 08:11:26PM +0100, Jan Kiszka wrote:
On 2011-02-27 20:03, Alon Levy wrote:
On Sat, Feb 26, 2011 at 01:29:01PM +0100, Jan Kiszka wrote:
On 2011-02-26 12:43, xming wrote:
On Sun, Feb 27, 2011 at 08:27:01PM +0100, Jan Kiszka wrote:
On 2011-02-27 20:16, Alon Levy wrote:
On Sun, Feb 27, 2011 at 08:11:26PM +0100, Jan Kiszka wrote:
On 2011-02-27 20:03, Alon Levy wrote:
On Sat, Feb 26, 2011 at 01:29:01PM +0100, Jan Kiszka wrote:
On 2011-02-26 12:43, xming wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=30042
Summary: page allocation failure when using jumbo frames with
kvm guests
Product: Virtualization
Version: unspecified
Kernel Version: 2.6.35
Platform: All
OS/Version: Linux
On Friday 25 February 2011 16:12:30 Michael S. Tsirkin wrote:
On Fri, Feb 25, 2011 at 11:23:30AM +0800, Sheng Yang wrote:
On Thursday 24 February 2011 18:22:19 Michael S. Tsirkin wrote:
On Thu, Feb 24, 2011 at 05:51:03PM +0800, Sheng Yang wrote:
Add a new parameter to IO writing handler,
On Friday 25 February 2011 16:29:38 Michael S. Tsirkin wrote:
On Fri, Feb 25, 2011 at 02:28:02PM +0800, Sheng Yang wrote:
On Thursday 24 February 2011 18:45:08 Michael S. Tsirkin wrote:
On Thu, Feb 24, 2011 at 05:51:04PM +0800, Sheng Yang wrote:
Then we can support mask bit operation of
This patch series is a continuation of an earlier one that
implemented guest MQ TX functionality. This new patchset
implements both RX and TX MQ. Qemu changes are not being
included at this time solely to aid in easier review.
Compatibility testing with old/new combinations of qemu/guest
and
Move queue_index from virtio_pci_vq_info to virtqueue. This
allows callback handlers to figure out the queue number for
the vq that needs attention.
Signed-off-by: Krishna Kumar krkum...@in.ibm.com
---
drivers/virtio/virtio_pci.c | 10 +++---
include/linux/virtio.h |1 +
2 files
Implement mq virtio-net driver.
Though struct virtio_net_config changes, it works with the old
qemu since the last element is not accessed unless qemu sets
VIRTIO_NET_F_NUMTXQS. Patch also adds a macro for the maximum
number of TX vq's (VIRTIO_MAX_TXQS) that the user can specify.
Changes for mq vhost.
vhost_net_open is changed to allocate a vhost_net and return.
The remaining initializations are delayed till SET_OWNER.
SET_OWNER is changed so that the argument is used to determine
how many txqs to use. Unmodified qemu's will pass NULL, so
this is recognized and handled
Add a new parameter to IO writing handler, so that we can transfer information
from IO handler to caller.
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
arch/x86/kvm/i8254.c |6 --
arch/x86/kvm/i8259.c |3 ++-
arch/x86/kvm/lapic.c |3 ++-
arch/x86/kvm/x86.c
Change from v9:
Update according to the comments of Alex and Michael.
Notice this patchset still based on 2.6.37 due to a block bug on assigned
device in the upstream now.
Sheng Yang (4):
KVM: Move struct kvm_io_device to kvm_host.h
KVM: Add kvm_io_ext_data to IO handler
KVM: Emulate MSI-X
Then we can support mask bit operation of assigned devices now.
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
arch/x86/include/asm/kvm_host.h |1 +
arch/x86/kvm/Makefile |2 +-
arch/x86/kvm/mmu.c |2 +
arch/x86/kvm/x86.c | 40 -
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
Documentation/kvm/api.txt | 58 +
1 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
index e1a9297..dd10c3b 100644
---
Then it can be used by other struct in kvm_host.h
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
include/linux/kvm_host.h | 23 +++
virt/kvm/iodev.h | 25 +
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git
On Mon, Feb 28, 2011 at 12:04:27PM +0530, Krishna Kumar wrote:
This patch series is a continuation of an earlier one that
implemented guest MQ TX functionality. This new patchset
implements both RX and TX MQ. Qemu changes are not being
included at this time solely to aid in easier review.
Anthony Liguori anth...@codemonkey.ws writes:
On 02/25/2011 03:54 AM, Markus Armbruster wrote:
Anthony Liguorialigu...@linux.vnet.ibm.com writes:
On 02/24/2011 10:20 AM, Markus Armbruster wrote:
Anthony Liguorialigu...@linux.vnet.ibm.com writes:
On 02/24/2011 02:33
49 matches
Mail list logo
