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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.02.19 at 11:30, <wei.liu2@xxxxxxxxxx> wrote:
> On Thu, Feb 14, 2019 at 01:11:49AM -0700, Jan Beulich wrote:
>> >>> On 13.02.19 at 19:07, <wei.liu2@xxxxxxxxxx> wrote:
>> > On Thu, Feb 07, 2019 at 05:58:56AM -0700, Jan Beulich wrote:
>> >> >>> On 06.02.19 at 21:41, <andrew.cooper3@xxxxxxxxxx> 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.
> 
> I see. In that case I think replacing it with
> 
>    BUILD_BUG_ON(offsetof(struct shared_info, vcpu_info) != 0);
> 
> should be OK. Although I don't see how it can change to not be the first
> in the shared_info, it being part of the guest visible ABI.

Sure - it was added really just as a pre- (and perhaps over-)
cautionary measure, when at the time so many other native
<-> compat transformations were necessary and could be got
wrong.

Jan



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