Re: [Xen-devel] [PATCH v4 06/14] xen: Move the hvm_start_info C representation from libxc to public/xen.h

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.03.16 at 01:59, <konrad.wilk@xxxxxxxxxx> wrote:
> On Tue, Mar 15, 2016 at 02:09:46AM -0600, Jan Beulich wrote:
>> >>> On 14.03.16 at 18:55, <anthony.perard@xxxxxxxxxx> wrote:
>> > --- a/xen/include/public/xen.h
>> > +++ b/xen/include/public/xen.h
>> > @@ -841,6 +841,37 @@ typedef struct start_info start_info_t;
>> >   */
>> >  #define XEN_HVM_START_MAGIC_VALUE 0x336ec578
>> >  
>> > +#if defined(__i386__) || defined(__x86_64__)
>> > +/* C representation of the x86/HVM start info layout.
>> > + *
>> > + * The canonical definition of this layout is abrove, this is just a way 
>> > to
>> > + * represent the layout described there using C types.
>> > + *
>> > + * NB: the packed attribute is not really needed, but it helps us enforce
>> > + * the fact this this is just a representation, and it might indeed
>> > + * be required in the future if there are alignment changes.
>> > + */
>> > +struct hvm_start_info {
>> > +    uint32_t magic;             /* Contains the magic value 0x336ec578    
>> >    */
>> > +                                /* ("xEn3" with the 0x80 bit of the "E" 
>> > set).*/
>> > +    uint32_t version;           /* Version of this structure.             
>> >    */
>> > +    uint32_t flags;             /* SIF_xxx flags.                         
>> >    */
>> > +    uint32_t cmdline_paddr;     /* Physical address of the command line.  
>> >    */
>> > +    uint32_t nr_modules;        /* Number of modules passed to the 
>> > kernel.   */
>> > +    uint32_t modlist_paddr;     /* Physical address of an array of        
>> >    */
>> > +                                /* hvm_modlist_entry.                     
>> >    */
>> > +    uint32_t rsdp_paddr;        /* Physical address of the RSDP ACPI data 
>> >    */
>> > +                                /* structure.                             
>> >    */
>> > +} __attribute__((packed));
>> > +
>> > +struct hvm_modlist_entry {
>> > +    uint64_t paddr;             /* Physical address of the module.        
>> >    */
>> > +    uint64_t size;              /* Size of the module in bytes.           
>> >    */
>> > +    uint64_t cmdline_paddr;     /* Physical address of the command line.  
>> >    */
>> > +    uint64_t reserved;
>> > +} __attribute__((packed));
>> > +#endif /* x86 */
>> 
>> This needs extra care: Either the packed attributes need to be
>> dropped (Roger - why did they get put there in the first place?),
> 
> Presumarily b/c on 32-bit and 64-bit the size of the structure would
> be different otherwise...

And that difference in size would result from what? 

>> or their use needs to be shielded from compilers not understanding
>> them.
> 
> .. which begs the question - How come we didn't make the structure 64-bit 
> nice?
> As in add another uint32_t to it? And then we can ditch the packed?

Certainly not the odd number of uint32_t-s in there. If there was
a mix of uint32_t and uint64_t, I could certainly see any issue...

Jan


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