Re: [Xen-devel] [PATCH 5/5] xen: Add V4V implementation - padding question

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 11 Jun 2013, Tim Deegan wrote:
> At 13:54 -0400 on 11 Jun (1370958882), Ross Philipson wrote:
> > On 06/11/2013 01:40 PM, Ross Philipson wrote:
> > >On 06/11/2013 01:25 PM, Tim Deegan wrote:
> > >>At 13:10 -0400 on 11 Jun (1370956242), Ross Philipson wrote:
> > >>>>
> > >>>>>>...
> > >>>>>>+struct v4v_info
> > >>>>>>+{
> > >>>>>>+ uint64_t ring_magic;
> > >>>>>>+ uint64_t data_magic;
> > >>>>>>+ evtchn_port_t evtchn;
> > >>>>>
> > >>>>>Missing padding at the end?
> > >>>>>
> > >>>>
> > >>>>ack.
> > >>>>
> > >>>
> > >>>At one point during the review of an earlier version of the V4V patch
> > >>>set, Jan requested that this pad be added to the v4v_info struct. I
> > >>>understand the padding in all the other structs but I don't understand
> > >>>this one. This struct is not included in any other structs and is not
> > >>>followed by any data.
> > >>
> > >>64-bit Xen would see this as a 24-byte struct, even without explicit
> > >>padding. That would surprise a 32-bit guest that allocated what it saw
> > >>as a 20-byte struct for Xen to copy into.
> > >
> > >Ah yes, of course. Thanks for the quick response.
> > >
> > >Ross
> > 
> > I guess that means that this struct is unhappy then...
> > 
> > typedef struct v4vtables_rule
> > {
> >     v4v_addr_t src;  -- 8b
> >     v4v_addr_t dst;  -- 8b
> >     uint32_t accept; -- 4b
> > } v4vtables_rule_t;
> 
> Surprisingly, no: since it contains no 8-byte fields, both x86
> architectures will see it as a 20-byte (4-byte-aligned) struct. 
> Not sure about ARM, though.

same on ARM and ARM64

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel