Btw. This patch posting is broken. It suffers from line-wraps which make
it impossible to apply as-is. I was able to fix it but please consider
this in your next posting.
On Wed, Mar 31, 2010 at 05:12:35PM -0700, Tom Lyon wrote:
--- linux-2.6.33/drivers/uio/uio_pci_generic.c2010-02-24
Hi Lucas
Thanks for your comments.
Please find the patch, with suggested changes.
Thanks
Pradeep
Signed-off-by: Pradeep Kumar Surisetty psuri...@linux.vnet.ibm.com
---
diff -uprN autotest-old/client/tests/kvm/tests/balloon_check.py
autotest/client/tests/kvm/tests/balloon_check.py
---
Hi, this is the first version!
We've first implemented the x86 specific parts without introducing
new APIs: so this code works with current qemu-kvm.
Although we have many things to do, we'd like to get some comments
to see we are going to the right direction.
Note: we are now testing this
We will use this later in other parts.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
Signed-off-by: Fernando Luis Vazquez Cao ferna...@oss.ntt.co.jp
---
arch/powerpc/kvm/book3s.c |2 +-
arch/x86/kvm/x86.c|2 +-
include/linux/kvm_host.h |5 +
For x86, we will change the allocation and free parts to do_mmap() and
do_munmap(). This patch makes it cleaner.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
Signed-off-by: Fernando Luis Vazquez Cao ferna...@oss.ntt.co.jp
---
virt/kvm/kvm_main.c | 27
Currently, x86 vmalloc()s a dirty bitmap every time when we swich
to the next dirty bitmap. To avoid this, we use the double buffering
technique: we also move the bitmaps to userspace, so that extra
bitmaps will not use the precious kernel resource.
This idea is based on Avi's suggestion.
By this patch, bitmap allocation is replaced with do_mmap() and
bitmap manipulation is replaced with *_user() functions.
Note that this does not change the APIs between kernel and user space.
To get more advantage from this hack, we need to add a new interface
for triggering the bitmap swith and
The idea is simple, just to pin the guest VM user space and then
let host NIC driver has the chance to directly DMA to it.
The patches are based on vhost-net backend driver. We add a device
which provides proto_ops as sendmsg/recvmsg to vhost-net to
send/recv directly to/from the NIC driver. KVM
From: Xin Xiaohui xiaohui@intel.com
Add a device to utilize the vhost-net backend driver for
copy-less data transfer between guest FE and host NIC.
It pins the guest user space to the host memory and
provides proto_ops as sendmsg/recvmsg to vhost-net.
Signed-off-by: Xin Xiaohui
From: Xin Xiaohui xiaohui@intel.com
The patch let host NIC driver to receive user space skb,
then the driver has chance to directly DMA to guest user
space buffers thru single ethX interface.
Signed-off-by: Xin Xiaohui xiaohui@intel.com
Signed-off-by: Zhao Yu yzha...@gmail.com
From: Xin Xiaohui xiaohui@intel.com
The vhost-net backend now only supports synchronous send/recv
operations. The patch provides multiple submits and asynchronous
notifications. This is needed for zero-copy case.
Signed-off-by: Xin Xiaohui xiaohui@intel.com
---
drivers/vhost/net.c |
On 04/02/2010 08:05 PM, Greg KH wrote:
Currently kvm does device assignment with its own code, I'd like to unify
it with uio, not split it off.
Separate notifications for msi-x interrupts are just as useful for uio as
they are for kvm.
I agree, there should not be a difference here for
On Fri, Apr 9, 2010 at 2:40 PM, pradeep psuri...@linux.vnet.ibm.com wrote:
Hi Lucas
Thanks for your comments.
Please find the patch, with suggested changes.
Thanks
Pradeep
Signed-off-by: Pradeep Kumar Surisetty psuri...@linux.vnet.ibm.com
---
diff -uprN
On Thu, 8 Apr 2010 18:01:01 +0200
Mohammed Gamal m.gamal...@gmail.com wrote:
Hi,
Now that Cam is almost done with his ivshmem patches, I was thinking
of another idea for GSoC which is improving the pass-though
filesystems.
I've got some questions on that:
1- What does the community prefer
On Thu, 2010-04-08 at 17:14 -0700, Rick Jones wrote:
Here are the results with netperf TCP_STREAM 64K guest to host on a
8-cpu Nehalem system.
I presume you mean 8 core Nehalem-EP, or did you mean 8 processor Nehalem-EX?
Yes. It is a 2 socket quad-core Nehalem. so i guess it is a 8 core
On Friday 09 April 2010 02:58:19 am Avi Kivity wrote:
On 04/02/2010 08:05 PM, Greg KH wrote:
Currently kvm does device assignment with its own code, I'd like to unify
it with uio, not split it off.
Separate notifications for msi-x interrupts are just as useful for uio as
they are for
Mea culpa.
On Friday 09 April 2010 02:08:55 am Joerg Roedel wrote:
Btw. This patch posting is broken. It suffers from line-wraps which make
it impossible to apply as-is. I was able to fix it but please consider
this in your next posting.
On Wed, Mar 31, 2010 at 05:12:35PM -0700, Tom Lyon
On Fri, Apr 09, 2010 at 09:34:16AM -0700, Tom Lyon wrote:
The 'check' items are already done, not fully tested; probably available next
week.
Can we leave the others for future patches? Please? And I definitely need
help with
the PCI config stuff.
Yeah, go in small steps forward. Just
Luiz Capitulino wrote:
On Thu, 8 Apr 2010 18:01:01 +0200
Mohammed Gamal m.gamal...@gmail.com wrote:
Hi,
Now that Cam is almost done with his ivshmem patches, I was thinking
of another idea for GSoC which is improving the pass-though
filesystems.
I've got some questions on that:
1- What
Sridhar Samudrala wrote:
On Thu, 2010-04-08 at 17:14 -0700, Rick Jones wrote:
Here are the results with netperf TCP_STREAM 64K guest to host on a
8-cpu Nehalem system.
I presume you mean 8 core Nehalem-EP, or did you mean 8 processor Nehalem-EX?
Yes. It is a 2 socket quad-core Nehalem. so
On Fri, Apr 9, 2010 at 7:11 PM, jvrao jv...@linux.vnet.ibm.com wrote:
Luiz Capitulino wrote:
On Thu, 8 Apr 2010 18:01:01 +0200
Mohammed Gamal m.gamal...@gmail.com wrote:
Hi,
Now that Cam is almost done with his ivshmem patches, I was thinking
of another idea for GSoC which is improving the
On 04/09/2010 07:34 PM, Tom Lyon wrote:
- access to all config space, but BARs must be translated so userspace
cannot attack the host
Please elaborate. All of PCI config? All of PCIe config? Seems like a huge mess.
Yes. Anything a guest's device driver may want to access.
The
* Bernhard Schmidt (be...@birkenwald.de) wrote:
* KSM seems to be largely ineffective (100MB saved - 1.3MB saved)
Am I doing something wrong? Is this a bug? Is this generally impossible
with large pages (which might explain the lower load on the host, if
large pages are not scanned)? Or is
* Avi Kivity (a...@redhat.com) wrote:
On 04/02/2010 08:05 PM, Greg KH wrote:
- access to all config space, but BARs must be translated so
userspace cannot attack the host
Specifically, intermediated access to config space. For example, need
to know about MSI/MSI-X updates in config space.
* Tom Lyon (p...@lyon-about.com) wrote:
On Friday 09 April 2010 02:58:19 am Avi Kivity wrote:
- access to all config space, but BARs must be translated so userspace
cannot attack the host
Please elaborate. All of PCI config? All of PCIe config? Seems like a huge
mess.
All of config
Mohammed Gamal wrote:
2- With respect to CIFS. I wonder how the shares are supposed to be
exposed to the guest. Should the Samba server be modified to be able
to use unix domain sockets instead of TCP ports and then QEMU
communicating on these sockets. With that approach, how should the
guest
On Fri, Apr 9, 2010 at 11:22 PM, Jamie Lokier ja...@shareable.org wrote:
Mohammed Gamal wrote:
2- With respect to CIFS. I wonder how the shares are supposed to be
exposed to the guest. Should the Samba server be modified to be able
to use unix domain sockets instead of TCP ports and then QEMU
On Fri, Apr 9, 2010 at 5:17 PM, Mohammed Gamal m.gamal...@gmail.com wrote:
That's all good and well. The question now is which direction would
the community prefer to go. Would everyone be just happy with
virtio-9p passthrough? Would it support multiple OSs (Windows comes to
mind here)? Or
On Sat, Apr 10, 2010 at 12:22 AM, Javier Guerra Giraldez
jav...@guerrag.com wrote:
On Fri, Apr 9, 2010 at 5:17 PM, Mohammed Gamal m.gamal...@gmail.com wrote:
That's all good and well. The question now is which direction would
the community prefer to go. Would everyone be just happy with
Richard Simpson wrote:
On 08/04/10 09:52, Andre Przywara wrote:
Can you try to boot the attached multiboot kernel, which just outputs
a brief CPUID dump?
$ qemu-kvm -kernel cpuid_mb -vnc :0
(Unfortunately I have no serial console support in there yet, so you
either have to write the values
30 matches
Mail list logo
