From: Paolo Bonzini <pbonzini@redhat.com>
To: "Sair, Umair" <Umair_Sair@mentor.com>,
Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
"qemu-discuss@nongnu.org" <qemu-discuss@nongnu.org>
Subject: Re: [Qemu-devel] [Qemu-discuss] TCP options ipv4 and ipv6 have no effect
Date: Mon, 5 Oct 2015 21:22:43 +0200 [thread overview]
Message-ID: <5612CE03.1080005@redhat.com> (raw)
In-Reply-To: <9B0F7F7B0E031F4A99FC8A50E22E3AA360FC2658@EU-MBX-01.mgc.mentorg.com>
On 05/10/2015 20:03, Sair, Umair wrote:
>> The first if handles the "default to N" case, the second handles "default to Y", the (absent) else case handles "default to PF_UNSPEC".
>
> Can you please elaborate it. Also I am not understanding the reason for inverting the values of addr->has_ipv* in second if condition.
If a value is absent, you can either default it to Y (then the value is
!addr->has_xyz || addr->xyz) or default it to N (then the value is
addr->has_xyz && addr->xyz).
The desired logic is:
- with one absent value and one "on", the absent value should be "off"
- with one absent value and one "off", the absent value should be "on"
- with two absent values, the absent values can be both left absent
The patch works like this:
>> static void inet_addr_to_opts(QemuOpts *opts, const InetSocketAddress *addr) {
>> - bool ipv4 = addr->ipv4 || !addr->has_ipv4;
>> - bool ipv6 = addr->ipv6 || !addr->has_ipv6;
>> + bool ipv4 = addr->has_ipv4 && addr->ipv4;
>> + bool ipv6 = addr->has_ipv6 && addr->ipv6;
>>
>> - if (!ipv4 || !ipv6) {
>> + if (ipv4 || ipv6) {
>> qemu_opt_set_bool(opts, "ipv4", ipv4, &error_abort);
>> qemu_opt_set_bool(opts, "ipv6", ipv6, &error_abort);
This handles the case where the absent value should be "off": at least
one value is present _and_ true.
>> + } else if (addr->has_ipv4 || addr->has_ipv6) {
>> + qemu_opt_set_bool(opts, "ipv4", !addr->has_ipv4, &error_abort);
>> + qemu_opt_set_bool(opts, "ipv6", !addr->has_ipv6, &error_abort);
This handles the case where the absent value should be "on". We know
that whichever the present value is, it is false; therefore
!addr->has_xyz || addr->xyz simplifies to just !addr->has_xyz.
> I believe that the fix for the issue under discussion will be
> committed to qemu repo very soon,
Did you test the patch, and did it work for you? If so, it is customary
to reply with a line like "Tested by: Sair, Umair <Umair_Sair@mentor.com>".
> so I'll like to add one more thing
> which requires to be fixed along with it. In 'tcp_chr_accept'
> function of qemu-char.c, the data type of saddr should be
> sockaddr_in6 so that it works with both IPv6 and IPv4 on Windows
> (works for linux without it because of accept4 and works with this
> solution as well!).
Can you send a patch for it?
Thanks!
Paolo
next prev parent reply other threads:[~2015-10-05 19:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <9B0F7F7B0E031F4A99FC8A50E22E3AA360FC1AFD@EU-MBX-01.mgc.mentorg.com>
2015-10-02 17:56 ` [Qemu-devel] [Qemu-discuss] TCP options ipv4 and ipv6 have no effect Peter Maydell
2015-10-02 18:20 ` Sair, Umair
2015-10-02 22:36 ` Peter Maydell
2015-10-04 10:47 ` Paolo Bonzini
2015-10-05 18:03 ` Sair, Umair
2015-10-05 19:22 ` Paolo Bonzini [this message]
2015-10-05 19:27 ` Paolo Bonzini
2015-10-12 13:06 ` Sair, Umair
2015-10-12 13:25 ` Paolo Bonzini
2015-10-03 8:38 ` Liviu Ionescu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5612CE03.1080005@redhat.com \
--to=pbonzini@redhat.com \
--cc=Umair_Sair@mentor.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-discuss@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.