From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Olaf Hering <olaf@aepfle.de>, Wei Liu <wei.liu2@citrix.com>,
Ian Campbell <ian.campbell@citrix.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Julien Grall <julien.grall@linaro.org>,
Ian Jackson <ian.jackson@eu.citrix.com>,
Andrew Jones <drjones@redhat.com>, Tim Deegan <tim@xen.org>,
David Vrabel <david.vrabel@citrix.com>,
xen-devel@lists.xenproject.org,
Daniel De Graaf <dgdegra@tycho.nsa.gov>,
Keir Fraser <keir@xen.org>
Subject: Re: [PATCH RFC 3/4] xen: implement SCHEDOP_soft_reset
Date: Tue, 23 Jun 2015 14:10:32 +0200 [thread overview]
Message-ID: <87h9py8w1z.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <558923510200007800087EB9@mail.emea.novell.com> (Jan Beulich's message of "Tue, 23 Jun 2015 08:13:53 +0100")
"Jan Beulich" <JBeulich@suse.com> writes:
>>>> On 22.06.15 at 18:24, <vkuznets@redhat.com> wrote:
>> "Jan Beulich" <JBeulich@suse.com> writes:
>>
>>>>>> On 22.06.15 at 18:00, <vkuznets@redhat.com> wrote:
>>>> "Jan Beulich" <JBeulich@suse.com> writes:
>>>>
>>>>>>>> On 03.06.15 at 15:35, <vkuznets@redhat.com> wrote:
>>>>>> @@ -1129,8 +1129,9 @@ void unmap_vcpu_info(struct vcpu *v)
>>>>>> mfn = v->vcpu_info_mfn;
>>>>>> unmap_domain_page_global((void *)
>>>>>> ((unsigned long)v->vcpu_info & PAGE_MASK));
>>>>>> -
>>>>>> - v->vcpu_info = &dummy_vcpu_info;
>>>>>> + v->vcpu_info = ((v->vcpu_id < XEN_LEGACY_MAX_VCPUS)
>>>>>> + ? (vcpu_info_t *)&shared_info(d, vcpu_info[v->vcpu_id])
>>>>>
>>>>> Is this cast really needed?
>>>>>
>>>>
>>>> Without it my gcc-4.8.3 complains:
>>>>
>>>> domain.c: In function ‘unmap_vcpu_info’:
>>>> domain.c:1158:21: error: pointer type mismatch in conditional expression
>>>> [-Werror]
>>>> : &dummy_vcpu_info);
>>>> ^
>>>> cc1: all warnings being treated as errors
>>>
>>> Which is the kind of warning one normally should _not_ work
>>> around by adding a cast.
>>
>> In this (and in alloc_vcpu() from where this expression was copied)
>> particular case this is probably OK: in struct shared_info we have
>> 'struct vcpu_info vcpu_info[XEN_LEGACY_MAX_VCPUS]' as its first
>> member. But I may be missing something..
>
> Did you read the comment accompanying the definition of
> __shared_info()?
>
> The cast is presumably safe here, but it doesn't _look_ safe. And
> for future readers (and future changes) it would be better if it did.
Sorry, it seems I don't undestand the suggestion on how to make this
look better.
With CONFIG_COMPAT in both struct shared_info and struct
compat_shared_info vcpu_info array is of type 'struct vcpu_info[]' but
v->vcpu_info is of type 'vcpu_info_t *' which means union of 'struct
vcpu_info' and 'struct compat_vcpu_info' in CONFIG_COMPAT case. Both
these structures have same size of '64' on x86 so it's really up to its
user how to treat this data...
--
Vitaly
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2015-06-23 12:10 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-03 13:35 [PATCH RFC 0/4] 'reset everything' approach to PVHVM guest kexec Vitaly Kuznetsov
2015-06-03 13:35 ` [PATCH RFC 1/4] xen: evtchn: make evtchn_reset() ready for soft reset Vitaly Kuznetsov
2015-06-04 14:05 ` Tim Deegan
2015-06-04 15:19 ` David Vrabel
2015-06-04 15:47 ` Tim Deegan
2015-06-05 8:52 ` Jan Beulich
2015-06-05 8:58 ` Ian Campbell
2015-06-05 9:07 ` Jan Beulich
2015-06-08 14:10 ` Jan Beulich
2015-06-08 15:05 ` Vitaly Kuznetsov
2015-06-03 13:35 ` [PATCH RFC 2/4] xen: grant_table: implement grant_table_soft_reset() Vitaly Kuznetsov
2015-06-04 14:11 ` Tim Deegan
2015-06-04 15:22 ` David Vrabel
2015-06-04 15:44 ` Tim Deegan
2015-06-08 14:26 ` Jan Beulich
2015-06-08 14:58 ` Vitaly Kuznetsov
2015-06-08 15:35 ` Jan Beulich
2015-06-03 13:35 ` [PATCH RFC 3/4] xen: implement SCHEDOP_soft_reset Vitaly Kuznetsov
2015-06-08 14:31 ` Jan Beulich
2015-06-22 16:00 ` Vitaly Kuznetsov
2015-06-22 16:06 ` Jan Beulich
2015-06-22 16:24 ` Vitaly Kuznetsov
2015-06-23 7:13 ` Jan Beulich
2015-06-23 12:10 ` Vitaly Kuznetsov [this message]
2015-06-23 12:52 ` Jan Beulich
2015-06-03 13:35 ` [PATCH RFC 4/4] xen: arch-specific hooks for domain_soft_reset() Vitaly Kuznetsov
2015-06-04 14:19 ` Tim Deegan
2015-06-22 9:44 ` Vitaly Kuznetsov
2015-06-25 9:57 ` Tim Deegan
2015-06-08 15:32 ` Jan Beulich
2015-06-08 15:59 ` Vitaly Kuznetsov
2015-06-04 14:22 ` [PATCH RFC 0/4] 'reset everything' approach to PVHVM guest kexec Tim Deegan
2015-06-08 15:38 ` Ian Jackson
2015-06-08 15:53 ` Wei Liu
2015-06-08 17:43 ` Wei Liu
2015-06-09 8:19 ` Dave Scott
2015-06-09 9:29 ` Wei Liu
2015-06-09 9:38 ` Wei Liu
2015-06-09 10:02 ` Dave Scott
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=87h9py8w1z.fsf@vitty.brq.redhat.com \
--to=vkuznets@redhat.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=david.vrabel@citrix.com \
--cc=dgdegra@tycho.nsa.gov \
--cc=drjones@redhat.com \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=julien.grall@linaro.org \
--cc=keir@xen.org \
--cc=olaf@aepfle.de \
--cc=stefano.stabellini@eu.citrix.com \
--cc=tim@xen.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.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.