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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

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.

Wei.

> 
> Jan
> 
> 

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