On 2011-01-17 08:31, Huang Ying wrote:
On Mon, 2011-01-17 at 15:11 +0800, Jan Kiszka wrote:
On 2011-01-17 01:54, Huang Ying wrote:
On Sat, 2011-01-15 at 17:00 +0800, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
This case is a pure user space error we do not need to record.
No need to check the support of mergeable buffer inside the recevie
loop as the whole handle_rx()_xx is in the read critical region. So
this patch move it ahead of the receiving loop.
Signed-off-by: Jason Wang jasow...@redhat.com
---
drivers/vhost/net.c |5 +++--
1 files changed, 3
Codes duplication were found between the handling of mergeable and big
buffers, so this patch tries to unify them. This could be easily done
by adding a quota to the get_rx_bufs() which is used to limit the
number of buffers it returns (for mergeable buffer, the quota is
simply UIO_MAXIOV, for big
We can use lock_sock_fast() instead of lock_sock() in order to get
speedup in peek_head_len().
Signed-off-by: Jason Wang jasow...@redhat.com
---
drivers/vhost/net.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index
On Mon, Jan 17, 2011 at 04:11:08PM +0800, Jason Wang wrote:
Codes duplication were found between the handling of mergeable and big
buffers, so this patch tries to unify them. This could be easily done
by adding a quota to the get_rx_bufs() which is used to limit the
number of buffers it
On Mon, Jan 17, 2011 at 04:10:59PM +0800, Jason Wang wrote:
No need to check the support of mergeable buffer inside the recevie
loop as the whole handle_rx()_xx is in the read critical region. So
this patch move it ahead of the receiving loop.
Signed-off-by: Jason Wang jasow...@redhat.com
Le lundi 17 janvier 2011 à 16:11 +0800, Jason Wang a écrit :
We can use lock_sock_fast() instead of lock_sock() in order to get
speedup in peek_head_len().
Signed-off-by: Jason Wang jasow...@redhat.com
---
drivers/vhost/net.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
On 2011-01-17 03:08, Huang Ying wrote:
As indicated, I'm sitting on lots of fixes and refactorings of the MCE
user space code. How do you test your patches? Any suggestions how to do
this efficiently would be warmly welcome.
We use a self-made test script to test. Repository is at:
On Mon, Jan 17, 2011 at 04:11:17PM +0800, Jason Wang wrote:
We can use lock_sock_fast() instead of lock_sock() in order to get
speedup in peek_head_len().
Signed-off-by: Jason Wang jasow...@redhat.com
Queued for 2.6.39, thanks everyone.
---
drivers/vhost/net.c |4 ++--
1 files
qmp feature provided with RHEL6 is different from qmp in qemu-kvm 0.13.*.
introduce a new test for RHEL6.
Signed-off-by: Qingtang Zhou qz...@redhat.com
---
client/tests/kvm/tests/qmp_basic_rhel6.py | 386 +
client/tests/kvm/tests_base.cfg.sample|3 +
2 files
On Mon, Jan 17, 2011 at 07:37:30AM +0900, Simon Horman wrote:
On Fri, Jan 14, 2011 at 08:54:15AM +0200, Michael S. Tsirkin wrote:
On Fri, Jan 14, 2011 at 03:35:28PM +0900, Simon Horman wrote:
On Fri, Jan 14, 2011 at 06:58:18AM +0200, Michael S. Tsirkin wrote:
On Fri, Jan 14, 2011 at
On Mon, Jan 17, 2011 at 10:26:25AM +1030, Rusty Russell wrote:
On Mon, 17 Jan 2011 09:07:30 am Simon Horman wrote:
[snip]
I've been away, but what concerns me is that socket buffer limits are
bypassed in various configurations, due to skb cloning. We should probably
drop such limits
On Sun, Jan 16, 2011 at 10:38:11AM -0500, Avi Kivity wrote:
On 01/16/2011 05:35 PM, Joerg Roedel wrote:
On Sun, Jan 16, 2011 at 12:49:41PM +0200, Avi Kivity wrote:
On 01/14/2011 05:45 PM, Joerg Roedel wrote:
here is the reworked version of the patch-set. Only patch 1/2 has
changed
On Thu, Jan 06, 2011 at 06:19:44PM +0800, Sheng Yang wrote:
Then we can support mask bit operation of assigned devices now.
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
arch/x86/kvm/Makefile|2 +-
arch/x86/kvm/x86.c |8 +-
include/linux/kvm.h | 21
On Monday 17 January 2011 19:54:47 Marcelo Tosatti wrote:
On Thu, Jan 06, 2011 at 06:19:44PM +0800, Sheng Yang wrote:
Then we can support mask bit operation of assigned devices now.
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
arch/x86/kvm/Makefile|2 +-
On 01/17/2011 02:18 PM, Sheng Yang wrote:
+
+ if (copy_to_user((void __user *)(entry_base + offset), val, len))
+ goto out;
Instead of copying to/from userspace (which is subject to swapin,
unexpected values), you could include the guest written value in a
kvm_run
On 01/06/2011 12:19 PM, Sheng Yang wrote:
Signed-off-by: Sheng Yangsh...@linux.intel.com
---
Documentation/kvm/api.txt | 41 +
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
index
On 01/06/2011 12:19 PM, Sheng Yang wrote:
Then we can support mask bit operation of assigned devices now.
+int kvm_assigned_device_update_msix_mask_bit(struct kvm *kvm,
+ int assigned_dev_id, int entry, bool mask)
+{
+ int r = -EFAULT;
+ struct
Hello,
I saw this error logged while booting the kernel
prasad@prasad-kvm:~$ dmesg | grep PAGE
[ 13.132547] AMD-Vi: Event logged [IO_PAGE_FAULT device=06:00.1
domain=0x address=0xbb402000 flags=0x0050]
The kernel I have is cloned copy of the KVM repository.
menuentry 'Ubuntu, with
On Monday 17 January 2011 20:21:45 Avi Kivity wrote:
On 01/06/2011 12:19 PM, Sheng Yang wrote:
Signed-off-by: Sheng Yangsh...@linux.intel.com
---
Documentation/kvm/api.txt | 41
+ 1 files changed, 41
insertions(+), 0 deletions(-)
On Mon, Jan 17, 2011 at 08:18:22PM +0800, Sheng Yang wrote:
+ goto out;
+
+ mmio = mmio_dev-mmio[idx];
+ entry = (addr - mmio-table_base_addr) / PCI_MSIX_ENTRY_SIZE;
+ entry_base = mmio-table_base_va + entry * PCI_MSIX_ENTRY_SIZE;
+ ctrl_pos = (u32 *)(entry_base +
On 01/17/2011 02:35 PM, Sheng Yang wrote:
On Monday 17 January 2011 20:21:45 Avi Kivity wrote:
On 01/06/2011 12:19 PM, Sheng Yang wrote:
Signed-off-by: Sheng Yangsh...@linux.intel.com
---
Documentation/kvm/api.txt | 41
+ 1 files
On Mon, Jan 17, 2011 at 02:18:43PM +0200, Avi Kivity wrote:
On 01/17/2011 02:18 PM, Sheng Yang wrote:
+
+ if (copy_to_user((void __user *)(entry_base + offset), val,
len))
+ goto out;
Instead of copying to/from userspace (which is subject to swapin,
On 01/17/2011 02:48 PM, Marcelo Tosatti wrote:
On Mon, Jan 17, 2011 at 02:18:43PM +0200, Avi Kivity wrote:
On 01/17/2011 02:18 PM, Sheng Yang wrote:
+
+ if (copy_to_user((void __user *)(entry_base + offset), val,
len))
+ goto out;
Instead of
On Mon, Jan 17, 2011 at 02:29:44PM +0200, Avi Kivity wrote:
On 01/06/2011 12:19 PM, Sheng Yang wrote:
Then we can support mask bit operation of assigned devices now.
+int kvm_assigned_device_update_msix_mask_bit(struct kvm *kvm,
+int assigned_dev_id, int
On 2011-01-17 13:29, Avi Kivity wrote:
On 01/06/2011 12:19 PM, Sheng Yang wrote:
Then we can support mask bit operation of assigned devices now.
+int kvm_assigned_device_update_msix_mask_bit(struct kvm *kvm,
+int assigned_dev_id, int entry, bool mask)
+{
+int r =
Hi Prasad,
On Mon, Jan 17, 2011 at 12:30:48PM +, Prasad Joshi wrote:
Hello,
I saw this error logged while booting the kernel
prasad@prasad-kvm:~$ dmesg | grep PAGE
[ 13.132547] AMD-Vi: Event logged [IO_PAGE_FAULT device=06:00.1
domain=0x address=0xbb402000 flags=0x0050]
On Mon, Jan 17, 2011 at 02:51:37PM +0200, Avi Kivity wrote:
On 01/17/2011 02:48 PM, Marcelo Tosatti wrote:
On Mon, Jan 17, 2011 at 02:18:43PM +0200, Avi Kivity wrote:
On 01/17/2011 02:18 PM, Sheng Yang wrote:
+
+if (copy_to_user((void __user *)(entry_base + offset),
On Fri, Jan 14, 2011 at 01:29:52PM -0500, Rik van Riel wrote:
I am not sure whether we are meeting that objective via this patch, as
lock-spinning vcpu would simply yield after setting next buddy to preferred
vcpu on target pcpu, thereby leaking some amount of bandwidth on the pcpu
where it is
On 01/17/2011 05:52 PM, Marcelo Tosatti wrote:
What a value is written by the guest, which kvm cannot handle itself
(i.e. a change to anything other than the mask bit), we exit with
the table and entry ids, so userspace can reread them.
OK. But regarding access to the MSI-X entry in
The vmsd code expects the fields structure to be properly terminated,
not NULL. An assigned device should never be saved or restored, and
recent qemu fixes to the no_migrate flag should ensure this, but let's
avoid setting the wrong precedent.
Signed-off-by: Alex Williamson
On Mon, Jan 17, 2011 at 05:08:42PM +, Prasad Joshi wrote:
Please find the information you requested attached with this mail.
Also attaching the output of lspci -vvv -xxx incase it is useful.
Thanks, I'll have a look at it.
I would be interested in understanding the problem. If possible
On Mon, Jan 17, 2011 at 05:08:42PM +, Prasad Joshi wrote:
[ 13.132547] AMD-Vi: Event logged [IO_PAGE_FAULT device=06:00.1
domain=0x address=0xbb402000 flags=0x0050]
Ok, the problem is, that the device 06:00.1 is not described in the
ACPI table for the IOMMU driver. So the
Please send in any agenda items you are interested in covering.
thanks,
-chris
--
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.kernel.org/majordomo-info.html
From: Heiko Carstens heiko.carst...@de.ibm.com
Get rid of this warning:
CC arch/s390/kvm/../../../virt/kvm/kvm_main.o
arch/s390/kvm/../../../virt/kvm/kvm_main.c:596:12: warning:
'kvm_create_dirty_bitmap' defined but not used
The only caller of the function is within a !CONFIG_S390
Stefan,
I think you have captured it nicely. Here are few links that gives more
feature level perspectives.
http://www.convirture.com/products_opensource.php
http://www.convirture.com/products_enterprise.php
http://www.convirture.com/products_compare.php
/Jd
--- On Wed, 12/15/10, Stefan
On 01/16/2011 09:43 AM, Avi Kivity wrote:
On 01/14/2011 09:27 PM, Stefan Berger wrote:
Can you sprinkle some printfs() arount kvm_run (in qemu-kvm.c) to
verify this?
Here's what I did:
interrupt exit requested
It appears from this you're using qemu.git. Please try qemu-kvm.git,
Michael S. Tsirkin writes:
On Mon, Jan 17, 2011 at 04:11:08PM +0800, Jason Wang wrote:
Codes duplication were found between the handling of mergeable and big
buffers, so this patch tries to unify them. This could be easily done
by adding a quota to the get_rx_bufs() which is used to
Michael S. Tsirkin writes:
On Mon, Jan 17, 2011 at 04:10:59PM +0800, Jason Wang wrote:
No need to check the support of mergeable buffer inside the recevie
loop as the whole handle_rx()_xx is in the read critical region. So
this patch move it ahead of the receiving loop.
On Tue, Jan 18, 2011 at 12:26:17PM +0800, Jason Wang wrote:
Michael S. Tsirkin writes:
On Mon, Jan 17, 2011 at 04:10:59PM +0800, Jason Wang wrote:
No need to check the support of mergeable buffer inside the recevie
loop as the whole handle_rx()_xx is in the read critical region. So
On Tue, Jan 18, 2011 at 11:05:33AM +0800, Jason Wang wrote:
Michael S. Tsirkin writes:
On Mon, Jan 17, 2011 at 04:11:08PM +0800, Jason Wang wrote:
Codes duplication were found between the handling of mergeable and big
buffers, so this patch tries to unify them. This could be easily
Michael S. Tsirkin writes:
On Tue, Jan 18, 2011 at 11:05:33AM +0800, Jason Wang wrote:
Michael S. Tsirkin writes:
On Mon, Jan 17, 2011 at 04:11:08PM +0800, Jason Wang wrote:
Codes duplication were found between the handling of mergeable and big
buffers, so this patch tries to
42 matches
Mail list logo
