yandong31
Members-
Posts
16 -
Joined
-
Last visited
yandong31's Achievements
Junior Member (1/3)
1
Reputation
-
It's true, I feel like installing macOS on AMD hardware has become even simpler than it was on my previous Intel platform. It's an aspect I never really focused on before, and I've genuinely enjoyed discussing it with you.On a separate note, while DisableWriteVariable can achieve a similar outcome, I believe it does so by sacrificing functionality. That's why I agree with CorpGhost's point that it's not about 'more is better' or 'less is better' with the whitelist. The goal is to skip only the parts that would cause issues if devirtualized.😄 It's possible that for the TRX40 platform, all the front-most regions are actively used by the system and cannot be devirtualized. Of course, this is just my theory. Thank you for your dedication and all the extensive testing you carried out back then, during a time when everyone was still figuring things out. 👍
-
You're right, I only need to skip Region 2 to boot. However, since Regions 3 and 4 are quite small, I'm thinking that skipping them as well might improve system stability. I'm testing that theory now.
-
Just to be clear for anyone else referencing this: for my platform, I only needed to skip Region 2 to get everything working normally. I'm not replying because I have a problem, but to serve as a reference for others — don't fall into the trap of thinking that skipping more regions is always better. To be clear, my view might not be entirely correct either. Let's discuss it and allow everyone to judge for themselves. Regardless, I really appreciate your contributions on the forum.
-
Like I said before, with MmioWhitelist, more isn't better. If you skip 4 out of 5 regions, DevirtualiseMmio only reclaims memory from a single region for the system — and it's likely the smallest one. This can actually lead to system instability. When it comes to the TRX40, the 'more isn't better' rule still holds true. However, the reason it might need a longer list is that the platform inherently contains numerous small or defective regions that must be filtered out. Skip in MMIO devirtualisation means exactly what it says. It skips devirtualisation for the particular region found. — If a region is whitelisted, then devirtualisation does not happen, and skip is 1. — Otherwise the region is permitted to be used by the operating system, and skip is 0. To be fair, vit9696 was very clear about this from the start.
-
Put another way, enabling DevirtualiseMmio while whitelisting every MMIO region effectively neutralizes it, producing the same outcome as leaving it off.
-
@fabiosun Your testing actually confirms my earlier point perfectly. DevirtualiseMmio works by freeing up more memory for the system to use. The reason you don't need a whitelist is that on your platform, all the memory it reclaims is perfectly usable. However, if some of that reclaimed memory is faulty or problematic, you must use MmioWhitelist to skip over those specific bad regions to prevent system crashes. The trade-off is that the more entries you add to the MmioWhitelist, the fewer available addresses KASLR has to work with, which can cause its own set of problems. So, I still believe the primary function of MmioWhitelist is precisely to identify and filter out the non-usable MMIO regions. In my platform's case, there are four key regions. Skipping only the second one is sufficient for a normal boot. But given that regions three and four are quite small, I think including them in the skip is a viable approach. 21:417 00:057 OCABC: MMIO devirt start 21:430 00:013 OCABC: MMIO devirt 0xE0000000 (0x10000 pages, 0x800000000000100D) skip 0 21:443 00:012 OCABC: MMIO devirt 0xF7000000 (0x7E00 pages, 0x800000000000100D) skip 1 21:475 00:032 OCABC: MMIO devirt 0xFEE00000 (0x1 pages, 0x8000000000000001) skip 0 21:488 00:012 OCABC: MMIO devirt 0xFEE01000 (0x11FF pages, 0x800000000000100D) skip 0 21:544 00:056 OCABC: MMIO devirt 0x860000000 (0x20200 pages, 0x800000000000100D) skip 0 21:558 00:013 OCABC: MMIO devirt end, saved 806912 KB 21:570 00:012 OCABC: Only 128/256 slide values are usable! 21:602 00:031 OCABC: Valid slides - 128-255
-
@fabiosun My understanding is that the DevirtualiseMmio quirk is designed to free up more memory address space for KASLR to use. However, some of these freed-up addresses might be problematic. The purpose of the MmioWhitelist is to filter out these specific problematic addresses. Therefore, the MmioWhitelist shouldn't be considered "the more, the better." A longer list actually means less address space is ultimately freed up for KASLR. The correct approach is to only list the addresses that are genuinely harmful, preventing just those from being released.
-
I made a patch following your method, but my device won’t boot. Could you help me figure out what’s wrong? A0000000 90909293 47303032 0A039347 30303001 90929347 3030320A 04929347 30303300 G002 != 0x03 && G000 == One && G002 != 0x04 && G003 != Zero FF000000 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF A3A3A3A3 A3A3A3A3 A3A3A3A3 A3A3A3A3 A3A3A3A3 A3A3A3A3 A3A3A3A3 A3A3A3A3 A3A3A3A3
-
I’ve got 5 Scopes for (_SB.PCI0.GPP7), 3 for (_SB.PCI0.GPP7.UP00.DP40), 2 for (_SB.PCI0.GPP7.UP00.DP40.UP00.DP40), and 2 for (_SB.PCI0.GPP7.UP00.DP20)—all tucked under different conditional statements. Then there’s also 2 Scopes for (_SB.PCI0.GPP7.UP00.DP60.XH00) that are under different conditionals too. I really have no idea which ones to keep!
-
I can get the onboard network card recognized normally if I manually delete the G000~G02D variables and the subsequent conditional statements following the OP’s method—it’s just not very clean. I’m wondering how you made your patch step by step? Also, the address for my RTL8125BG is IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/GPP7@2,1/IOPP/UP00@0/IOPP/DP40@8/IOPP/UP00@0/IOPP/DP28@5/IOPP/ethernet@0.
-
The patch definitely modified the DSDT like it should, but my onboard network card still isn’t working. Do I really have to make patches for every single conditional statement that looks like "If (((G002 != 0x03) && ((G000 == One)"? There are so many conditional statements, and the same device is referred to differently in different condition blocks. Even if I remove the conditional statements, which one should I pick? If ((G002 != One)) If (((G000 == One) && ((G002 >= 0x04) && ( G002 <= 0x07)))){} If (((G000 == One) && (G002 == 0x07))){} If (((G002 != 0x03) && (G000 != Zero))){} If ((G002 != 0x03)) If ((G002 < 0x03)) If (((G002 != 0x03) && (G000 == One))) If (((G002 != 0x03) && (G000 != Zero))) If (((G002 != 0x03) && ((G000 == One) && (G004 == 0x43FA1022)))) If (((G002 != 0x03) && ((G000 == One) && ( G004 != 0x43FA1022)))) If (((G002 != 0x03) && (G000 == 0x02))) If (((G002 < 0x03) && (G000 == One))) If (((G002 != 0x03) && ((G000 == One) && ( G002 != 0x04)))) If (((G002 != 0x03) && ((G000 == One) && ( (G002 != 0x04) && (G002 != 0x07))))) If (((G002 != 0x03) && ((G000 == One) && ( G002 != 0x05)))) If (((G002 != 0x03) && ((G000 == One) && ( G002 != 0x06)))) If (((G000 == One) && (G002 == 0x04))) If (((G000 == One) && (G002 == 0x05))) If (((G000 == One) && (G002 == 0x06))) If ((((G002 != 0x03) && (G000 == One)) && ( (G002 != 0x04) && (G003 != Zero)))) If (((G000 == One) && ((G002 == 0x07) && (G003 != Zero)))) If ((((G002 != 0x03) && (G000 == One)) && ( (G002 != 0x04) && ((G002 != 0x07) && (G003 != Zero))))) If ((((G002 != 0x03) && (G000 == One)) && ( (G002 != 0x04) && (G003 == Zero)))) If ((G002 != 0x03)) If ((G002 != 0x02)) If ((G001 == One)) The DSDT on MSI motherboards is a total disaster!
-
@Lorys89 I have a question about the following code. Is the CPU Plugin-type only for the \_SB.PR00 mode? I understand, AMD CPU does not need this patch. Processor (CP00, 0x00, 0x00000510, 0x06) { If (CondRefOf (\_SB.PR00)) { Return (\_SB.PR00) /* External reference */ } If (CondRefOf (\_SB.PLTF.C000)) { Return (\_SB.PLTF.C000) /* External reference */ } Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If ((_OSI ("Darwin") && CondRefOf (\_SB.PR00))) { If ((Arg2 == Zero)) { Return (Buffer (One) { 0x03 }) } Return (Package (0x02) { "plugin-type", One }) } Return (Zero) } Method (_STA, 0, NotSerialized) // _STA: Status { Return (MO86 ()) } }
-
Skip in MMIO devirtualisation means exactly what it says. It skips devirtualisation for the particular region found. — If a region is whitelisted, then devirtualisation does not happen, and skip is 1. — Otherwise the region is permitted to be used by the operating system, and skip is 0. If you have suggestions on how to improve the debug message, feel free to let us know. Edited March 4, 2020 by vit9696 What you're saying here is completely opposite to what vit9696 said. I don't know if more skips are better or fewer are better. In other words: are we picking the bad guys or the good guys here?
-
Method (_ON, 0, NotSerialized) // _ON_: Power On { M000 (0x30D0) M460 (" OEM-ASL-\\_SB.PCI0.GPP1.P0NV._ON\n", Zero, Zero, Zero, Zero, Zero, Zero) Store (G017, Local0) Store (0x02, Local2) Store (\PWGS (Zero), Local5) M460 (" OEM-ASL-\\_SB.PCI0.GPP1.P0NV._ON D3Cold = 0x%X WD3C First = 0x%X SI3V = 0x%X\n", Local0, WD3C, Local5, Zero, Zero, Zero) If (LEqual (Local0, One)) { PWEN () } If (LOr (LEqual (WD3C, One), LEqual (Local5, Zero))) { RPCF () Sleep (0x0A) If (CondRefOf (\UPWD)) { \UPWD () } Store (Zero, WD3C) } Store (One, D0NV) M000 (0x30D1) } Given that the variables G000 to G020 and three methods have been deleted in the cpvs section previously,Is it correct to modify this code as follows? Method (_ON, 0, NotSerialized) // _ON_: Power On { M000 (0x30D0) M460 (" OEM-ASL-\\_SB.PCI0.GPP1.P0NV._ON\n", Zero, Zero, Zero, Zero, Zero, Zero) Store (0x02, Local2) If (LEqual (WD3C, One)) { RPCF () Sleep (0x0A) Store (Zero, WD3C) } Store (One, D0NV) M000 (0x30D1) }
-
I just tried to modify it manually following your post, but what should I do with this kind of code? G001 isn't even defined. I'm wondering if I should keep the content in the else block. If (LEqual (G001, One)) { M460 (" OEM-ASL-\\_SB.GPIO._AEI return BUNP (MS)\n", Zero, Zero, Zero, Zero, Zero, Zero) Return (BUNP) } Else { M460 (" OEM-ASL-\\_SB.GPIO._AEI return BUFF (S3)\n", Zero, Zero, Zero, Zero, Zero, Zero) Return (BUFF) } Attached is my original DSDT DSDT.aml.zip