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

[Tim Deegan <tim@xxxxxxx>]

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.

Tim.

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