On Friday 09 April 2010, xiaohui@intel.com wrote:
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
On Wednesday 14 April 2010, Michael S. Tsirkin wrote:
On Wed, Apr 14, 2010 at 04:55:21PM +0200, Arnd Bergmann wrote:
On Friday 09 April 2010, xiaohui@intel.com wrote:
From: Xin Xiaohui xiaohui@intel.com
It seems that you are duplicating a lot of functionality that
is already
On Wednesday 14 April 2010, Michael S. Tsirkin wrote:
qemu needs the ability to inject raw packets into device
from userspace, bypassing vhost/virtio (for live migration).
Ok, but since there is only a write callback and no read, it won't
actually be able to do this with the
On Wednesday 14 April 2010 22:31:42 Michael S. Tsirkin wrote:
On Wed, Apr 14, 2010 at 06:35:57PM +0200, Arnd Bergmann wrote:
On Wednesday 14 April 2010, Michael S. Tsirkin wrote:
qemu needs the ability to inject raw packets into device
from userspace, bypassing vhost/virtio
On Wednesday 14 April 2010 22:40:03 Michael S. Tsirkin wrote:
On Wed, Apr 14, 2010 at 10:39:49PM +0200, Arnd Bergmann wrote:
Well, if the guest not only wants to send data but also receive
frames coming from other machines, they need to get from the kernel
into qemu, and the only way I can
On Thursday 15 April 2010, Xin, Xiaohui wrote:
It seems that you are duplicating a lot of functionality that
is already in macvtap. I've asked about this before but then
didn't look at your newer versions. Can you explain the value
of introducing another interface to user land?
I'm still
On Friday 23 April 2010, Avi Kivity wrote:
On 04/23/2010 01:20 PM, Alexander Graf wrote:
I would say the reason is that if we did not convert the user-space
pointer to
a void * kvm_get_dirty_log() would end up copying the dirty log to
(log-dirty_bitmap 32) | 0x
On Friday 23 April 2010, Avi Kivity wrote:
On 04/23/2010 03:27 PM, Arnd Bergmann wrote:
Using a 64-bit integer avoids the problem (though perhaps not sufficient
for s390, Arnd?)
When there is only a __u64 for the address, it will work on s390 as well,
gcc is smart enough
On Friday 23 April 2010, Avi Kivity wrote:
Ah so the 31st bit is optional as far as userspace is concerned? What
does it mean? (just curious)
On data pointers it's ignored. When you branch to a function, this bit
determines whether the target function is run in 24 or 31 bit mode.
This allows
On Tuesday 04 May 2010, Takuya Yoshikawa wrote:
Although we can use *_le_bit() helpers to treat bitmaps le arranged,
having le bit offset calculation as a seperate macro gives us more freedom.
For example, KVM has le arranged dirty bitmaps for VGA, live-migration
and they are used in user
On Monday 10 May 2010, Takuya Yoshikawa wrote:
(2010/05/06 22:38), Arnd Bergmann wrote:
On Wednesday 05 May 2010, Takuya Yoshikawa wrote:
There was a suggestion to propose set_le_bit_user() kind of macros.
But what I thought was these have a constraint you two explained and
seemed
On Saturday 29 May 2010, Tom Lyon wrote:
+/*
+ * Structure for DMA mapping of user buffers
+ * vaddr, dmaaddr, and size must all be page aligned
+ * buffer may only be larger than 1 page if (a) there is
+ * an iommu in the system, or (b) buffer is part of a huge page
+ */
+struct
On Wednesday 16 September 2009, Michael S. Tsirkin wrote:
vhost-net driver projects
I still think that list should include
- UDP multicast socket support
- TCP socket support
- raw packet socket support for qemu (from Or Gerlitz)
if we have those, plus the tap support that is already on
your
On Tuesday 15 September 2009, Michael S. Tsirkin wrote:
Userspace in x86 maps a PCI region, uses it for communication with ppc?
This might have portability issues. On x86 it should work, but if the
host is powerpc or similar, you cannot reliably access PCI I/O memory
through copy_tofrom_user but
On Wednesday 16 September 2009, Michael S. Tsirkin wrote:
On Wed, Sep 16, 2009 at 04:52:40PM +0200, Arnd Bergmann wrote:
On Wednesday 16 September 2009, Michael S. Tsirkin wrote:
vhost-net driver projects
I still think that list should include
Yea, why not. Go wild.
- UDP
On Wednesday 16 September 2009, Michael S. Tsirkin wrote:
On Wed, Sep 16, 2009 at 04:57:42PM +0200, Arnd Bergmann wrote:
On Tuesday 15 September 2009, Michael S. Tsirkin wrote:
Userspace in x86 maps a PCI region, uses it for communication with ppc?
This might have portability issues
On Wednesday 16 September 2009, Michael S. Tsirkin wrote:
No, I think this is less important, because the bridge code
also doesn't do this.
True, but the reason might be that it is much harder in bridge (you have
to snoop multicast registrations). With macvlan you know which
multicasts
On Wednesday 16 September 2009, Michael S. Tsirkin wrote:
Also, I might not want to allow the user to open a
random random raw socket, but only one on a specific downstream
port of a macvlan interface, so I can filter out the data from
that respective MAC address in an external switch.
On Thursday 17 September 2009, Michael S. Tsirkin wrote:
On Thu, Sep 17, 2009 at 01:30:00PM +0200, Arnd Bergmann wrote:
On Wednesday 16 September 2009, Michael S. Tsirkin wrote:
Also, I might not want to allow the user to open a
random random raw socket, but only one on a specific
On Thursday 17 September 2009, Michael S. Tsirkin wrote:
Well, we could have a char device with an ioctl that gives you back a socket,
or maybe even have it give you back a socket when you open it.
Will that make you happy?
Well, that would put is in the exact same spot as the tun/tap driver
On Tuesday 22 September 2009, Michael S. Tsirkin wrote:
More importantly, when virtualizations is used with multi-queue
NIC's the virtio-net NIC is a single CPU bottleneck. The virtio-net
NIC should preserve the parallelism (lock free) using multiple
receive/transmit queues. The number
On Tuesday 22 September 2009, Stephen Hemminger wrote:
My idea for that was to open multiple file descriptors to the same
macvtap device and let the kernel figure out the right thing to
do with that. You can do the same with raw packed sockets in case
of vhost_net, but I wouldn't want to
On Thursday 08 October 2009, Anthony Liguori wrote:
Jens Osterkamp wrote:
On Wednesday 30 September 2009, Anthony Liguori wrote:
Please add to this list and I'll collect it all and post it somewhere.
What about Or Gerlitz' raw backend driver ? I did not see it go in yet, or
support for Book3s_64 hosts and guest support
for Book3s_64 and G3/G4.
To really make use of this, you also need a recent version of qemu.
Don't want to apply patches? Get the git tree!
$ git clone git://csgraf.de/kvm
$ git checkout origin/ppc-v4
Whole series Acked-by: Arnd Bergmann
On Monday 26 October 2009, Shirley Ma wrote:
On Sun, 2009-10-25 at 11:11 +0200, Michael S. Tsirkin wrote:
What is vnet0?
That's a tap interface. I am binding raw socket to a tap interface and
it doesn't work. Does it support?
Is the tap device connected to a bridge as you'd normally do
On Monday 02 November 2009, Michael S. Tsirkin wrote:
Tun device looks similar to a packet socket
in that both pass complete frames from/to userspace.
This patch fills in enough fields in the socket underlying tun driver
to support sendmsg/recvmsg operations, and message flags
MSG_TRUNC and
On Tuesday 03 November 2009, Benjamin Herrenschmidt wrote:
(Though glibc can be nasty, afaik it might load up optimized variants of
some routines with hard wired cache line sizes based on the CPU type)
You can also get application with hand-coded cache optimizations
that are even harder, if not
On Tuesday 03 November 2009, Arnd Bergmann wrote:
index 3f5fd52..404abe0 100644
--- a/include/linux/if_tun.h
+++ b/include/linux/if_tun.h
@@ -86,4 +86,18 @@ struct tun_filter {
__u8 addr[0][ETH_ALEN];
};
+#ifdef __KERNEL__
+#if defined(CONFIG_TUN) || defined
On Thursday 10 December 2009, Avi Kivity wrote:
Maybe even /usr/local/include/kvm-kmod-$version/, and a symlink
/usr/local/include/kvm-kmod.
Depends on how fine-grained you want to do the packaging.
Most distributions split packages between code and development
packages. The kvm-kmod code
On Thursday 10 December 2009 17:14:40 Jan Kiszka wrote:
Avi Kivity wrote:
On 12/10/2009 06:42 PM, Jan Kiszka wrote:
I've just (forced-)pushed the simple version with
/usr/include/kvm-kmod as destination. The user headers are now stored
under usr/include in the kvm-kmod sources and
On Wednesday 26 November 2008, Gleb Natapov wrote:
The interfaces that are being considered are netlink socket (only datagram
semantics, linux specific), new socket family or character device with
different minor number for each channel. Which one better suits for
the purpose? Is there other
On Monday 18 April 2011, Asias He wrote:
Hi, folks
I am trying to use qemu/qemu-kvm with macvtap using following commands:
# ip link add link eth0 name v0 type macvtap mode {vepa,bridge,private}
# ip link set v0 address da:4e:17:88:42:b1 up
# idx=`ip link show v0 | grep mtu| awk -F:
On Monday 18 April 2011, Asias He wrote:
(1) Is it possible to add an interface to macvtap like /dev/net/tun,
eg, /dev/net/macvtap. Currently, it is hard to use macvtap programmatically.
I decided against having a multiplexor device because it makes permission
handling rather hard. One chardev
On Monday 18 April 2011, Ingo Molnar wrote:
Only in VEPA mode. Note that a similar restriction applies when using the
bridge device, for the same technical reasons.
Just to sum things up, our goal is to allow the tools/kvm/ unprivileged tool
to
provide TCP connectivity to Linux guests
On Monday 18 April 2011, Asias He wrote:
We do need guest appearing on the same network as the host support as
well. The reason I am considering using macvatp instead of tap plus
brctl is that it simplifies the bridge configuration and it is more
efficient.
Right, you certainly don't need to
On Monday 18 April 2011, Asias He wrote:
If you want a regular device to be able to send to a macvlan
port, that would require at least these changes:
* Add an option to put a plain device into macvlan-bridge mode
* Add support for that option into iproute2
* Add a hook into
On Tuesday 08 June 2010, Randy Dunlap wrote:
Documentation/ioctl/ioctl-number.txt |1
Documentation/vfio.txt | 177 +++
MAINTAINERS |7
drivers/Kconfig |2
drivers/Makefile |1
On Wednesday 16 June 2010, Markus Armbruster wrote:
Can't hurt reviewer motivation. Could it be automated? Find replies,
extract tags. If you want your acks to be picked up, you better make
sure your References header works, and your tags are formatted
correctly.
I think pwclient
On Monday 21 June 2010, Christian Borntraeger wrote:
Hmm, dont know. Currently this calls into a s390 debug tracing facility
(arch/s390/kernel/debug.c) which is heavily used by our service folks.
There are commands for crash and lcrash to show these s390 debug traces
from a dump.
Maybe its
On Friday 30 July 2010 17:51:52 Shirley Ma wrote:
On Fri, 2010-07-30 at 16:53 +0800, Xin, Xiaohui wrote:
Since vhost-net already supports macvtap/tun backends, do you think
whether it's better to implement zero copy in macvtap/tun than
inducing
a new media passthrough device here?
On Wednesday 04 August 2010, Dong, Eddie wrote:
Arnd Bergmann wrote:
On Friday 30 July 2010 17:51:52 Shirley Ma wrote:
I think it should be less duplicated code in the kernel if we use
macvtap to support what media passthrough driver here. Since macvtap
has support virtio_net head
On Monday 18 January 2010, john cooper wrote:
+.name = Conroe,
+.level = 2,
+.vendor1 = CPUID_VENDOR_INTEL_1,
+.vendor2 = CPUID_VENDOR_INTEL_2,
+.vendor3 = CPUID_VENDOR_INTEL_3,
+.family = 6, /* P6 */
+.model = 2,
On Wednesday 27 January 2010, Anthony Liguori wrote:
The raw backend can be attached to a physical device
This is equivalent to bridging with tun/tap except that it has the
unexpected behaviour of unreliable host/guest networking (which is not
universally consistent across platforms
On Wednesday 27 January 2010, Michael S. Tsirkin wrote:
I am not sure I agree with this sentiment. The main issue being that
macvtap doesn't exist on all kernels :). macvlan also requires hardware
support, packet socket can work with any network card in promisc mode.
To be clear, macvlan does
On Wednesday 27 January 2010, Anthony Liguori wrote:
I think -net socket,fd should just be (trivially) extended to work with raw
sockets out of the box, with no support for opening it. Then you can have
libvirt or some wrapper open a raw socket and a private namespace and just
pass it
On Wednesday 27 January 2010, Sridhar Samudrala wrote:
On Wed, 2010-01-27 at 22:39 +0100, Arnd Bergmann wrote:
On Wednesday 27 January 2010, Anthony Liguori wrote:
I think -net socket,fd should just be (trivially) extended to work
with raw
sockets out of the box, with no support
On Wednesday 27 January 2010, Anthony Liguori wrote:
Introducing something that is known to be problematic from a security
perspective without any clear idea of what the use-case for it is is a
bad idea IMHO.
vepa on existing kernels is one use-case.
Considering
On Monday 25 January 2010, Dor Laor wrote:
x86 qemu64
x86 phenom
x86 core2duo
x86kvm64
x86 qemu32
x86 coreduo
x86 486
x86 pentium
x86 pentium2
x86 pentium3
x86 athlon
x86
On Thursday 28 January 2010, Anthony Liguori wrote:
normal user uses libvirt to launch custom qemu instance. libvirt passes
an fd of a raw socket to qemu and puts the qemu process in a restricted
network namespace. user has another program running listening on a unix
domain socket and
On Wednesday 10 February 2010, Xin Xiaohui wrote:
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
On Thursday 11 February 2010, Xin, Xiaohui wrote:
This does a lot of things that I had planned for macvtap. It's
great to hear that you have made this much progress.
However, I'd hope that we could combine this with the macvtap driver,
which would give us zero-copy transfer capability both
On Monday 08 March 2010, Cam Macdonell wrote:
enum ivshmem_registers {
IntrMask = 0,
IntrStatus = 2,
Doorbell = 4,
IVPosition = 6,
IVLiveList = 8
};
The first two registers are the interrupt mask and status registers.
Interrupts are triggered when a message is
On Tuesday 09 March 2010, Cam Macdonell wrote:
We could make the masking in RAM, not in registers, like virtio, which would
require no exits. It would then be part of the application specific
protocol and out of scope of of this spec.
This kind of implementation would be possible now
On Thursday 11 March 2010, Avi Kivity wrote:
A totally different option that avoids this whole problem would
be to separate the signalling from the shared memory, making the
PCI shared memory device a trivial device with a single memory BAR,
and using something a higher-level concept like
On Thursday 11 March 2010, Avi Kivity wrote:
That would be much slower. The current scheme allows for an
ioeventfd/irqfd short circuit which allows one guest to interrupt
another without involving their qemus at all.
Yes, the serial line approach would be much slower, but my point
On Wednesday 18 February 2009, Rusty Russell wrote:
2) Direct NIC attachment
This is particularly interesting with SR-IOV or other multiqueue nics,
but for boutique cases or benchmarks, could be for normal NICs. So
far I have some very sketched-out patches: for the attached nic
On Thursday 19 February 2009, Rusty Russell wrote:
Not quite: I think PCI passthrough IMHO is the *wrong* way to do it:
it makes migrate complicated (if not impossible), and requires
emulation or the same NIC on the destination host.
This would be the *host* seeing the virtual functions
On Thursday 26 February 2009, Glauber Costa wrote:
@@ -548,15 +548,13 @@ static int do_set_msr(struct kvm_vcpu *vcpu, unsigned
index, u64 *data)
static void kvm_write_wall_clock(struct kvm *kvm, gpa_t wall_clock)
{
- static int version;
+ int version = 1;
struct
On Friday 27 February 2009, Glauber Costa wrote:
Doesn't this mean that kvm_write_guest now writes an uninitialized value
to the guest?
No. If you look closely, it's now initialized to 1.
Right, I didn't see that change at first.
Arnd
--
To unsubscribe from this list: send the
On Friday 24 April 2009, Oliver Rath wrote:
Hi,
Im looking for an abillity seeing vt-capability of Intel-processors by
there name :-/
I.e. T7200 has vt, T3400 has not. Exists a rule for the naming scheme
seeing vt-capability? Alternatively, exists a matrix anywhere in the net
for this?
On Tuesday 28 April 2009, Marc Bevand wrote:
As a rule of thumb, anything higher than 6000 will have VT,
anything below 6000 will not. Interesting exceptions are
Doesn't have VT: E7300, Q8200, Q8400, E8190
Does have VT: T5600, U2xxx, SU3xxx, Celeron 900 (?)
May have VT[1]: T5500,
On Friday 20 August 2010 19:56:20 Glauber Costa wrote:
@@ -675,6 +676,9 @@ struct kvm_clock_data {
#define KVM_SET_PIT2 _IOW(KVMIO, 0xa0, struct kvm_pit_state2)
/* Available with KVM_CAP_PPC_GET_PVINFO */
#define KVM_PPC_GET_PVINFO _IOW(KVMIO, 0xa1, struct
On Wednesday 08 September 2010, Krishna Kumar2 wrote:
The new guest and qemu code work with old vhost-net, just with reduced
performance, yes?
Yes, I have tested new guest/qemu with old vhost but using
#numtxqs=1 (or not passing any arguments at all to qemu to
enable MQ). Giving numtxqs
On Wednesday 08 September 2010, Krishna Kumar2 wrote:
On Wednesday 08 September 2010, Krishna Kumar2 wrote:
The new guest and qemu code work with old vhost-net, just with
reduced
performance, yes?
Yes, I have tested new guest/qemu with old vhost but using
#numtxqs=1 (or not
On Tuesday 14 September 2010, Shirley Ma wrote:
On Tue, 2010-09-14 at 11:12 +0200, Avi Kivity wrote:
That's what io_submit() is for. Then io_getevents() tells you what
a
while actually was.
This macvtap zero copy uses iov buffers from vhost ring, which is
allocated from guest kernel.
On Tuesday 28 September 2010, Michael S. Tsirkin wrote:
+ skb_reserve(skb, NET_IP_ALIGN);
+ skb_put(skb, len);
+
+ if (skb_copy_datagram_from_iovec(skb, 0, iov, 0, len)) {
+ kfree_skb(skb);
+ return -EAGAIN;
+ }
+
+ skb-protocol =
On Tuesday 28 September 2010, Michael S. Tsirkin wrote:
On Tue, Sep 28, 2010 at 04:39:59PM +0200, Arnd Bergmann wrote:
Can you be more specific what the problem is? Do you think
it breaks when a guest sends VLAN tagged frames or when macvtap
is connected to a VLAN interface that adds
On Tuesday 05 October 2010, Krishna Kumar2 wrote:
After testing various combinations of #txqs, #vhosts, #netperf
sessions, I think the drop for 1 stream is due to TX and RX for
a flow being processed on different cpus. I did two more tests:
1. Pin vhosts to same CPU:
- BW drop is
On Wednesday 06 October 2010 19:14:42 Krishna Kumar2 wrote:
Arnd Bergmann a...@arndb.de wrote on 10/06/2010 05:49:00 PM:
I don't see any reasons mentioned above. However, for higher
number of netperf sessions, I see a big increase in retransmissions
On Thursday 14 October 2010 21:58:08 Alex Williamson wrote:
If it works anywhere (I assume it works on 32bit), then it's only
because it happened to get the alignment right. This just makes 64bit
hosts get it right too. I don't see any compatibility issues,
non-packed + 64bit = broken.
On Thursday 14 October 2010 22:59:04 Alex Williamson wrote:
The structs in question only contain 4 8 byte elements, so there
shouldn't be any change on x86-32 using one-byte aligned packing.
I'm talking about the alignment of the structure, not the members
within the structure. The data
On Friday 15 October 2010, Alex Williamson wrote:
We can't let the compiler define the alignment for qemu_cfg data.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
v2: Adjust alignment to help non-x86 hosts per Arnd's suggestion
Ok, looks good now. Thanks!
Arnd
--
On Friday 15 October 2010, Michael S. Tsirkin wrote:
On Thu, Oct 14, 2010 at 11:40:52PM +0200, Dragos Tatulea wrote:
Hi,
I'm starting a thread related to the TODO item mentioned in the
subject. Currently still gathering info and trying to make kvm
macvtap play nicely together. I
...@oracle.com
Cc: rds-de...@oss.oracle.com
Cc: David S. Miller da...@davemloft.net
Cc: net...@vger.kernel.org
Cc: Avi Kivity a...@redhat.com
Cc: Marcelo Tosatti mtosa...@redhat.com
Cc: kvm@vger.kernel.org
Acked-by: Arnd Bergmann a...@arndb.de
--
To unsubscribe from this list: send the line
On Wednesday 27 October 2010, Sridhar Samudrala wrote:
Support a new 'passthru' mode with macvlan and 'mode' parameter
with macvtap devices.
Signed-off-by: Sridhar Samudrala s...@us.ibm.com
Can you split this into two patches?
We definitely want the part adding support for macvtap device
On Wednesday 27 October 2010, Sridhar Samudrala wrote:
With the current default macvtap mode, a KVM guest using virtio with
macvtap backend has the following limitations.
- cannot change/add a mac address on the guest virtio-net
- cannot create a vlan device on the guest virtio-net
- cannot
On Friday 29 October 2010, Sridhar Samudrala wrote:
Add support for 'mode' parameter when creating a macvtap device.
This allows a macvtap device to be created in bridge, private or
the default vepa modes.
Signed-off-by: Sridhar Samudrala s...@us.ibm.com
Acked-by: Arnd Bergmann
On Friday 29 October 2010, Sridhar Samudrala wrote:
With the current default 'vepa' mode, a KVM guest using virtio with
macvtap backend has the following limitations.
- cannot change/add a mac address on the guest virtio-net
I believe this could be changed if there is a neeed, but I actually
Bergmann a...@arndb.de
cc: Avi Kivity a...@redhat.com
cc: Marcelo Tosatti mtosa...@redhat.com
cc: kvm@vger.kernel.org
Acked-by: Arnd Bergmann a...@arndb.de
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info
on
plain files.
Signed-off-by: Johannes Stezenbach j...@sig21.net
Acked-by: Arnd Bergmann a...@arndb.de
---
(resend with Cc: suggested by get_maintainer.pl)
discussed in http://lkml.kernel.org/r/20110617090424.ga19...@sig21.net
Arnd, is this what you had in mind, or did you mean to move
On Thursday 16 July 2009, Gregory Haskins wrote:
Background: The original vbus code was tightly integrated with kvm.ko. Avi
suggested that we abstract the interfaces such that it could live outside
of kvm.
The code is still highly kvm-specific, you would not be able to use
it with another
On Thursday 16 July 2009, Gregory Haskins wrote:
Arnd Bergmann wrote:
Your approach allows passing the vmid from a process that does
not own the kvm context. This looks like an intentional feature,
but I can't see what this gains us.
This work is towards the implementation of lockless
On Thursday 09 July 2009, Lukáš Doktor wrote:
--- orig/client/tests/kvm/control 2009-07-08 13:18:07.0 +0200
+++ new/client/tests/kvm/control2009-07-09 12:32:32.0 +0200
@@ -45,6 +45,8 @@ Each test is appropriately documented on
import sys, os
+# set
On Thursday 06 August 2009, Gregory Haskins wrote:
We can exchange out the virtio-pci module like this:
(guest-side)
|--
| virtio-net
|--
| virtio-ring
|--
| virtio-bus
|--
| virtio-vbus
.
Signed-off-by: Arnd Bergmann a...@arndb.de
diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index 6dfe758..6b34e82 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -123,7 +123,7 @@ static uint32_t virtio_net_get_features(VirtIODevice *vdev)
VirtIONet *n = to_virtio_net(vdev
On Friday 07 August 2009, Mark McLoughlin wrote:
The vnet_hdr code in qemu-kvm.git is a hack which we plan to
(eventually) replace by allowing a nic to be paired directly with a
backend.
Your patch is fine, but I'd suggest since both are a hack we stick with
mine since it'll reduce merge
On Monday 10 August 2009, Michael S. Tsirkin wrote:
What it is: vhost net is a character device that can be used to reduce
the number of system calls involved in virtio networking.
Existing virtio net code is used in the guest without modification.
Very nice, I loved reading it. It's getting
On Monday 10 August 2009 20:10:44 Michael S. Tsirkin wrote:
On Mon, Aug 10, 2009 at 09:51:18PM +0200, Arnd Bergmann wrote:
what is the difference between vhost_net_reset_owner(n)
and vhost_net_set_socket(n, -1)?
set socket to -1 will only stop the device.
reset owner will let another
On Wednesday 12 August 2009, Gregory Haskins wrote:
Are you saying SRIOV is a requirement, and I can either program the
SRIOV adapter with a mac or use promis? Or are you saying I can use
SRIOV+programmed mac OR a regular nic + promisc (with a perf penalty).
SRIOV is not a requirement.
On Wednesday 12 August 2009, Michael S. Tsirkin wrote:
If I understand it correctly, you can at least connect a veth pair
to a bridge, right? Something like
veth0 - veth1 - vhost - guest 1
eth0 - br0-|
veth2 - veth3 - vhost - guest 2
Heh, you
On Monday 10 August 2009, Michael S. Tsirkin wrote:
+struct workqueue_struct *vhost_workqueue;
[nitpicking] This could be static.
+/* The virtqueue structure describes a queue attached to a device. */
+struct vhost_virtqueue {
+ struct vhost_dev *dev;
+
+ /* The actual ring of
On Wednesday 12 August 2009, Michael S. Tsirkin wrote:
On Wed, Aug 12, 2009 at 07:03:22PM +0200, Arnd Bergmann wrote:
We discussed this before, and I still think this could be directly derived
from struct virtqueue, in the same way that vring_virtqueue is derived from
struct virtqueue.
I
On Wednesday 12 August 2009, Anthony Liguori wrote:
At any rate, I'd like to see performance results before we consider
trying to reuse virtio code.
Yes, I agree. I'd also like to do more work on the macvlan extensions
to see if it works out without involving a socket. Passing the socket
into
On Thursday 13 August 2009, Arnd Bergmann wrote:
Unfortunately, this also implies that you could no longer simply use the
packet socket interface as you do currently, as I realized only now.
This obviously has a significant impact on your user space interface.
Also, if we do the copy
On Thursday 13 August 2009, Michael S. Tsirkin wrote:
On Wed, Aug 12, 2009 at 07:59:47PM +0200, Arnd Bergmann wrote:
The trick is to swap the virtqueues instead. virtio-net is actually
mostly symmetric in just the same way that the physical wires on a
twisted pair ethernet are symmetric (I
On Thursday 13 August 2009, Michael S. Tsirkin wrote:
The best way to do this IMO would be to add zero copy support to raw
sockets, vhost will then get it basically for free.
Yes, that would be nice. I wonder if that could lead to security
problems on TX though. I guess It will only bring
On Thursday 13 August 2009, Michael S. Tsirkin wrote:
Right now, the number of copy operations in your code is the same.
You are doing the copy a little bit later in skb_copy_datagram_iovec(),
which is indeed a very nice hack. Changing to a virtqueue based method
would imply that the host
, mostly by convincing me
that you got it right anyway ;-).
I hope this gets into 2.6.32, good work!
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Acked-by: Arnd Bergmann a...@arndb.de
One idea though:
+ /* Parameter checking */
+ if (sock-sk-sk_type != SOCK_RAW
On Tuesday 18 August 2009, Gregory Haskins wrote:
Avi Kivity wrote:
On 08/17/2009 10:33 PM, Gregory Haskins wrote:
One point of contention is that this is all managementy stuff and should
be kept out of the host kernel. Exposing shared memory, interrupts, and
guest hypercalls can all
On Tuesday 18 August 2009 20:35:22 Michael S. Tsirkin wrote:
On Tue, Aug 18, 2009 at 10:27:52AM -0700, Ira W. Snyder wrote:
Also, in my case I'd like to boot Linux with my rootfs over NFS. Is
vhost-net capable of this?
I've had Arnd, BenH, and Grant Likely (and others, privately) contact
1 - 100 of 203 matches
Mail list logo
