Re: [PATCH] x86/pv: Fix construction of 32bit dom0's

["Jan Beulich" <JBeulich@suse.com>]

>>> On 13.02.19 at 19:07, <wei.liu2@citrix.com> wrote:
> On Thu, Feb 07, 2019 at 05:58:56AM -0700, Jan Beulich wrote:
>> >>> On 06.02.19 at 21:41, <andrew.cooper3@citrix.com> wrote:
>> > Slightly RFC:
>> > 
>> > 1) I've not worked out exactly what the
>> > 
>> >      v->vcpu_info = (void *)&d->shared_info->compat.vcpu_info[0];
>> > 
>> >    line is supposed to be doing and whether it is needed, but it doesn't
>> >    appear to matter.  It is perhaps another redundant opencoding.
>> 
>> Afaict this is just to be independent of the fact that the vcpu_info
>> array is first in struct shared_info. I'd be fine with it getting replaced
>> by a respective BUILD_BUG_ON(), but I'd like to ask that it not be
>> dropped without replacement.
> 
> What do you mean by "be independent of" here? Perhaps you meant "be sure
> of"? But I still fail to understand how would an assignment makes sure
> a member is first in a struct.

It's the other way around: We're fine without the assignment when
the field is first in the struct. The assignment would strictly be needed
if it wasn't, because then what's earlier in the struct could have
different sizes between the native and compat layouts.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel