[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 1/7] x86/vioapic: introduce a internal vIO APIC structure



On Tue, Mar 28, 2017 at 01:17:27AM -0600, Jan Beulich wrote:
> >>> On 27.03.17 at 18:49, <roger.pau@xxxxxxxxxx> wrote:
> > Yes, I think the unnamed structure is way better, here's what I've done:
> > 
> > save.h:
> > 
> > union vioapic_redir_entry
> > {
> >     uint64_t bits;
> >     struct {
> >         uint8_t vector;
> >         uint8_t delivery_mode:3;
> >         uint8_t dest_mode:1;
> >         uint8_t delivery_status:1;
> >         uint8_t polarity:1;
> >         uint8_t remote_irr:1;
> >         uint8_t trig_mode:1;
> >         uint8_t mask:1;
> >         uint8_t reserve:7;
> >         uint8_t reserved[4];
> >         uint8_t dest_id;
> >     } fields;
> > };
> > 
> > #define VIOAPIC_NUM_PINS  48 /* 16 ISA IRQs, 32 non-legacy PCI IRQS. */
> > 
> > #define DECLARE_VIOAPIC(name, cnt)                      \
> >     struct name {                                       \
> >         uint64_t base_address;                          \
> >         uint32_t ioregsel;                              \
> >         uint32_t id;                                    \
> >         union vioapic_redir_entry redirtbl[cnt];        \
> >     }
> > 
> > DECLARE_VIOAPIC(hvm_hw_vioapic, VIOAPIC_NUM_PINS);
> > 
> > #ifndef __XEN__
> > #undef DECLARE_VIOAPIC
> > #endif
> > 
> > vioapic.h:
> > 
> > struct hvm_vioapic {
> >     struct domain *domain;
> >     DECLARE_VIOAPIC(, VIOAPIC_NUM_PINS);
> > };
> > 
> > This seems to work fine, and now the BUILD_BUG_ON is just pointless.
> 
> Well, no, not entirely. As said you still want to exclude alignment
> effects prior structure members of hvm_vioapic may have (please
> continue to not make assumptions on the alignment of the first
> field of the structure here).

But doesn't the usage of an unnamed structure get rid of the alignment issue?
For example I have the following code:

struct bar {
        uint8_t b;
        uint8_t c;
        uint32_t d;
        uint32_t e;
};

struct foo {
        uint8_t a;
        struct {
        uint8_t b;
        uint8_t c;
        uint32_t d;
        uint32_t e;
        };
};

struct foobar {
        uint8_t a;
        uint8_t b;
        uint8_t c;
        uint32_t d;
        uint32_t e;
};

This according to pahole has the following layout:

struct bar {
        uint8_t                    b;                    /*     0     1 */
        uint8_t                    c;                    /*     1     1 */

        /* XXX 2 bytes hole, try to pack */

        uint32_t                   d;                    /*     4     4 */
        uint32_t                   e;                    /*     8     4 */

        /* size: 12, cachelines: 1, members: 4 */
        /* sum members: 10, holes: 1, sum holes: 2 */
        /* last cacheline: 12 bytes */
};
struct foo {
        uint8_t                    a;                    /*     0     1 */

        /* XXX 3 bytes hole, try to pack */

        struct {
                uint8_t            b;                    /*     4     1 */
                uint8_t            c;                    /*     5     1 */
                uint32_t           d;                    /*     8     4 */
                uint32_t           e;                    /*    12     4 */
        };                                               /*     4    12 */

        /* size: 16, cachelines: 1, members: 2 */
        /* sum members: 13, holes: 1, sum holes: 3 */
        /* last cacheline: 16 bytes */
};
struct foobar {
        uint8_t                    a;                    /*     0     1 */
        uint8_t                    b;                    /*     1     1 */
        uint8_t                    c;                    /*     2     1 */

        /* XXX 1 byte hole, try to pack */

        uint32_t                   d;                    /*     4     4 */
        uint32_t                   e;                    /*     8     4 */

        /* size: 12, cachelines: 1, members: 5 */
        /* sum members: 11, holes: 1, sum holes: 1 */
        /* last cacheline: 12 bytes */
};

The unnamed struct (clone of bar) inside of foo is already aligned (so it ends
up with the same layout as bar), as opposed to foobar, which indeed ends up
with a different layout.

> Furthermore, despite the #undef the macro name should start
> with XEN_, perhaps even with XEN_HVM_. Whether the
> DECLARE part is really needed/useful I'm not sure.

I've renamed it to XEN_HVM_VIOAPIC.

Thanks, Roger.

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.