[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v6 00/16] x86/mtrr: fix handling with PAT but without MTRR
On 31.05.23 10:35, Borislav Petkov wrote: [ 0.018357] MTRR default type: uncachable [ 0.022347] MTRR fixed ranges enabled: [ 0.026085] 00000-9FFFF write-back [ 0.029650] A0000-BFFFF uncachable [ 0.033214] C0000-FFFFF write-protect [ 0.037039] MTRR variable ranges enabled: [ 0.041038] 0 base 000000000000000 mask 0003FFC00000000 write-back [ 0.047383] 1 base 000000400000000 mask 0003FFFC0000000 write-back [ 0.053730] 2 base 000000440000000 mask 0003FFFF0000000 write-back [ 0.060076] 3 base 0000000AE000000 mask 0003FFFFE000000 uncachable [ 0.066421] 4 base 0000000B0000000 mask 0003FFFF0000000 uncachable [ 0.072768] 5 base 0000000C0000000 mask 0003FFFC0000000 uncachable [ 0.079114] 6 disabled [ 0.081635] 7 disabled [ 0.084156] 8 disabled [ 0.086677] 9 disabled [ 0.089203] total RAM covered: 16352M [ 0.093023] Found optimal setting for mtrr clean up [ 0.097734] gran_size: 64K chunk_size: 64M num_reg: 8 lose cover RAM: 0G One other note: why does mtrr_cleanup() think that using 8 instead of 6 variable MTRRs would be an "optimal setting"? IMO it should replace the original setup only in case it is using _less_ MTRRs than before. Additionally I believe mtrr_cleanup() would make much more sense if it wouldn't be __init, but being usable when trying to add additional MTRRs in the running system in case we run out of MTRRs. It should probably be based on the new MTRR map anyway... Juergen Attachment:
OpenPGP_0xB0DE9DD628BF132F.asc Attachment:
OpenPGP_signature
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |