On 18/06/14 11:55, Stefan Hajnoczi wrote:
> Hi Anton,
> Still alive?
Just barely. Trying to keep my head above the snow drifts from an
avalanche of work :)
> L2TPv3 for QEMU has not been merged. Do you have an
> up-to-date series based on qemu.git/master you could send?
I will fix it to addr
On 23/06/14 12:50, Stefan Hajnoczi wrote:
> On Fri, Jun 20, 2014 at 10:34:41AM +0100, anton.iva...@kot-begemot.co.uk
> wrote:
>> From: Anton Ivanov
>>
>> This transport allows to connect a QEMU nic to a static Ethernet
>> over L2TPv3 tunnel. The transport supports all options present
>> in the Li
On 01/07/14 15:35, Stefan Hajnoczi wrote:
> On Tue, Jul 1, 2014 at 2:58 PM, wrote:
>> From: Gonglei
>>
>> because mmsghdr struct is introduced on Linux kernel 3.3+.
>> add check for mmsghdr struct, it only gets built on hosts that
>> support mmsghdr.
Incorrect.
mmsghdr itself is Linux 2.6.32 a
On 01/07/14 13:06, Jan Kiszka wrote:
> On 2014-06-27 16:24, Stefan Hajnoczi wrote:
>> From: Anton Ivanov
>>
>> This transport allows to connect a QEMU nic to a static Ethernet
>> over L2TPv3 tunnel. The transport supports all options present
>> in the Linux kernel implementation. It allows QEMU to
On 01/07/14 16:14, Peter Maydell wrote:
> On 1 July 2014 16:06, Anton Ivanov (antivano) wrote:
>> As far as general purpose linuxes, the relevant libc headers are present
>> in Ubuntul LTS 12.x and onwards, Debian 7.x, Fedora, and all other major
>> distros. I do not have
On 01/07/14 16:34, Peter Maydell wrote:
> On 1 July 2014 16:26, Anton Ivanov (antivano) wrote:
>> On 01/07/14 16:14, Peter Maydell wrote:
>>> On 1 July 2014 16:06, Anton Ivanov (antivano) wrote:
>>>> As far as general purpose linuxes, the relevant libc headers are
On 18/03/14 10:44, Stefan Hajnoczi wrote:
> On Tue, Mar 11, 2014 at 12:45:30PM +, anton.iva...@kot-begemot.co.uk
> wrote:
>> +/* This protocol number is passed getaddrinfo(), and not
>> + * used directly. If you give gettaddrinfo() what one is
>> + * supposed to give - INET, RAW, 0, the result
On 19/03/14 12:39, Eric Blake wrote:
> On 03/19/2014 03:31 AM, anton.iva...@kot-begemot.co.uk wrote:
>> From: Anton Ivanov
>>
>> This tranport allows to connect a qemu nic to a static Ethernet
> s/tranport/transport/
Guilty as charged :)
>
>> over L2TPv3 tunnel. The transport supports all option
[snip]
>> So the fact that qemu_send_packet_async() has returned a non-zero does not
>> mean that we have not paid the price for it :)
> A non-zero return is simply an error code from the ->receive() function.
> In this case the packet is dropped but queuing is unaffected.
>
>> The relevant code
On 27/03/14 12:30, Stefan Hajnoczi wrote:
> On Wed, Mar 26, 2014 at 11:08:41AM +, anton.iva...@kot-begemot.co.uk
> wrote:
>> +static ssize_t net_l2tpv3_receive_dgram_iov(NetClientState *nc,
>> +const struct iovec *iov,
>> +int iovcnt)
>> +{
>> +NetL2
On 03/04/14 13:20, Benoît Canet wrote:
> The Monday 31 Mar 2014 à 15:39:19 (+0100), anton.iva...@kot-begemot.co.uk
> wrote :
>> From: Anton Ivanov
>>
>> This transport allows to connect a QEMU nic to a static Ethernet
>> over L2TPv3 tunnel. The transport supports all options present
>> in the Lin
Hi all,
On behalf of Cisco Systems I am authorized to contribute a new transport
to the network subsystem in qemu.
Specifically, we would like to contribute a new transport:
L2TPv3 static tunnel network transport.
Earlier versions of this (we have patchsets going back to qemu-1.0) have
been use
On 28/02/14 10:02, Paolo Bonzini wrote:
>> This transport uses a linux specific call to get several GBit RX rate.
>
> Might as well mention that it's recvmmsg. :)
:)
>
>> This call can be wrapped (at some cost) in a compatibility loop using
>> posix compliant recvmsg instead for other systems. As
On 28/02/14 11:36, Paolo Bonzini wrote:
> Il 28/02/2014 12:17, Anton Ivanov (antivano) ha scritto:
>>> > As mentioned below, I suggest storing the cookies and session ids in
>>> > host order in NetL2TPV3State, and doing the conversion in
>>> > l2tpv3_form
On 28/02/14 13:40, Eric Blake wrote:
> On 02/28/2014 01:28 AM, Anton Ivanov (antivano) wrote:
>> Hi all,
>>
>> On behalf of Cisco Systems I am authorized to contribute a new transport
>> to the network subsystem in qemu.
>>
>> Patch attached.
> Your patc
I now remember why I am not using connected sockets.
connect() in UDP used to break source address bind(). I had a bug filed
vs that as far back as early 2.6 which everyone ignored for ages. It was
showing as bug vs hpa-tftpd.
I need to reverify if this is still the case as it has to keep a
parti
[snip]
>>> s/1.0/2.0/
>> OK - just to clarify, which version is this referring to - qemu, api, etc?
> This field is the version of qemu that first contains the release. If
> your patch is on time to make the qemu 2.0 release, then 2.0 is
> appropriate; but we're close to feature freeze so it may
On 03/03/14 13:27, Stefan Hajnoczi wrote:
> On Fri, Feb 28, 2014 at 08:28:11AM +0000, Anton Ivanov (antivano) wrote:
>> 3. Qemu to communicate with the local host, remote vms, network devices,
>> etc at speeds which for a number of use cases exceed the speed of the
>> lega
On 04/03/14 09:36, Stefan Hajnoczi wrote:
> On Mon, Mar 03, 2014 at 02:01:00PM +0000, Anton Ivanov (antivano) wrote:
>> On 03/03/14 13:27, Stefan Hajnoczi wrote:
>>> On Fri, Feb 28, 2014 at 08:28:11AM +0000, Anton Ivanov (antivano) wrote:
>>>> 3. Qemu to communicate w
Hi Stefan,
I am addressing a few more comments which I missed on first pass.
> If you really *need* the page size, please use sysconf(_SC_PAGESIZE).
I like to have it page aligned and if possible page sized so I can later
extend to do jumbo frame support via a vector. If this is the wrong way
Attached is a revised version.
* I am still keeping the sendmsg instead of iov_send because I have
not had the time to review udp.c in the kernel and do the relevant
regression testing to see if they connect() still breaks bind() on
multihomed hosts as it did in 2.6. We can revisit that at
Apologies, missed to diff the json definitions.
Attached.
On 04/03/14 15:19, Anton Ivanov wrote:
> Attached is a revised version.
>
> * I am still keeping the sendmsg instead of iov_send because I
> have not had the time to review udp.c in the kernel and do the
> relevant regression testing
On 04/03/14 15:41, Eric Blake wrote:
> On 03/04/2014 08:19 AM, Anton Ivanov (antivano) wrote:
>> Attached is a revised version.
> Better is to post a new top-level thread, with [PATCHv2] in the title.
> Also, one of the v1 review comments was to break this into smaller
> self
On 04/03/14 15:53, Eric Blake wrote:
> On 03/04/2014 08:22 AM, Anton Ivanov (antivano) wrote:
>> Apologies, missed to diff the json definitions.
>>
>> Attached.
>>
> Missing a commit message and a Signed-off-by line, so it can't be
> applied as-is. Also, we
On 04/03/14 16:33, Eric Blake wrote:
>
> +
> +
> +#define PAGE_SIZE 4096
> One of your earlier review comments suggested using sysconf or else
> renaming this, as not all systems have a page size of 4096.
OK.
>
>> +#define IOVSIZE 2
>> +#define MAX_L2TPV3_MSGCNT 32
>> +#define MAX_L2TPV3_IOVCNT (
On 04/03/14 16:55, Paolo Bonzini wrote:
> Il 04/03/2014 17:48, Anton Ivanov (antivano) ha scritto:
>>>> >> +static ssize_t net_l2tpv3_receive_dgram_iov(NetClientState *nc,
>>>> const struct iovec *iov, int iovcnt)
>>> > Long line; you can
On 04/03/14 15:53, Eric Blake wrote:
> On 03/04/2014 08:22 AM, Anton Ivanov (antivano) wrote:
>> Apologies, missed to diff the json definitions.
>>
>> Attached.
>>
> Missing a commit message and a Signed-off-by line, so it can't be
> applied as-is. Also, we
Hi all,
This is a functional driver which will interoperate versus most L2TPv3
implementations. It cannot be split into smaller patches - this is an
entire transport.
It will get one small incremental update at a later date. Some broken
l2tpv3 implementations require a counter field but do not
ire transport.
>> [snip]
>>
>> Please see http://wiki.qemu.org/Contribute/SubmitAPatch - in particular
>> the patch should be sent as inline text rather than as attachment (so
>> that we can comment inline on it), also it is missing a Signed-off-by
>> (without it patches cannot get accepted) and
On 10/03/14 15:05, Stefan Hajnoczi wrote:
> On Mon, Mar 10, 2014 at 11:31:38AM +, anton.iva...@kot-begemot.co.uk
> wrote:
>> From: Anton Ivanov
>>
>> This tranport allows to connect a qemu nic to a static Ethernet
>> over L2TPv3 tunnel. The transport supports all options present
>> in the lin
On 10/03/14 18:04, Stefan Hajnoczi wrote:
> On Mon, Mar 10, 2014 at 08:49:01AM +, Anton Ivanov wrote:
>> You are correct. My test is wrong.
>>
>> However, the result is the same - it wants a non-zero proto there.
>>
>> $ sudo ./gaitest
>> src ai_family 2 ai_socketype 3 ai_protocol 0
>> socket c
31 matches
Mail list logo