On Friday 27 March 2009 18:08:00 Jan Beulich wrote:
> >>> Christoph Egger <Christoph.Egger@xxxxxxx> 27.03.09 17:49 >>>
> >
> >On Friday 27 March 2009 17:34:07 Jan Beulich wrote:
> >> - * Currently Intel extended MSR (32/64) including all gp registers
> >> - * and E(R)DI, E(R)BP, E(R)SP, E(R)FLAGS, E(R)IP, E(R)MISC, only 10
> >> - * of them might be useful. So expend this array to 10.
> >> - */
> >> - struct mcinfo_msr mc_msr[10];
> >> + * Currently Intel extended MSR (32/64) include all gp registers
> >> + * and E(R)FLAGS, E(R)IP, E(R)MISC, up to 11/19 of them might be
> >> + * useful at present. So expand this array to 16/32 to leave room.
> >> + */
> >> + struct mcinfo_msr mc_msr[sizeof(void *) * 4];
> >
> >Please make this a fixed sized array. There are users like Oracle who run
> >a 32bit PAE Dom0 on a 64bit Xen ...
>
> And you expect a 32-bit kernel to be able to make sense of the MSRs
> corresponding to 64-bit-only registers?
>
> But you remind me that I failed to handle the difference in size of that
> array for 32-on-64 - I really need to check why the structure layout
> checking logic didn't catch the difference in size. Oh, right, sizeof(void
> *) needs special treatment (and I really don#t want to sue sizeof(long)
> here due to the implied dependency on the OS ABI).
Having the same size for both 32bit and 64bit makes the Dom0 code
simpler to use it. Taking care about the different sizes would
enforce either hackish code or two different implementations.
That's not acceptable IMO.
Christoph
--
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Jochen Polster, Thomas M. McCoy, Giuliano Meroni
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home