[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC 1/3] xen/save: pass a size paramter to the HVM compat functions
El 15/10/15 a les 10.12, Jan Beulich ha escrit: >>>> On 14.10.15 at 18:24, <roger.pau@xxxxxxxxxx> wrote: >> In order to cope with types having multiple compat versions pass a parameter >> to the fixup function so we can identify which compat version Xen is dealing >> with. > > Having peeked at patch 2, this won't help once another bit gets added > to the tail of that structure. Also it doesn't seem logical that the > previous compat handling got around without being passed the size > explicitly. I.e. while perhaps more involved, I think the compat > handling needs to be extended to allow for multiple versions. Yes, patch #2 needs to be fixed by making fpu_initialised an uint32_t. Adding versions would be the best option IMHO, but I don't think I have enough time to do that myself right now. > Or, since we have this under control going forward, don't even declare > all the various compat structures in the public header (and only ever > add to the tail). Then staying with the passing of size probably makes > sense, but the fixup function then should use offsetof() instead of > sizeof() (and validate unused tail bits are zero, so they can be used for > something later on). Since we use hvm_load_entry_zeroextend I think we can assert that all new tail bits are going to be 0, but I'm not sure I follow you regarding the usage of offsetof instead of sizeof. What are we going to compare with offsetof? Also, we already have a compat version of hvm_hw_cpu that didn't add the new field to the end. Roger. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |