On 5/27/21 8:02 AM, Christoph Hellwig wrote:
On Wed, May 19, 2021 at 11:50:07AM -0700, Florian Fainelli wrote:
You convert this call site with swiotlb_init_io_tlb_mem() which did not do the set_memory_decrypted()+memset(). Is this okay or should swiotlb_init_io_tlb_mem() add an additional argument to do this conditionally?
The zeroing is useful and was missing before. I think having a clean state here is the right thing.
Not sure about the set_memory_decrypted, swiotlb_update_mem_attributes kinda suggests it is too early to set the memory decrupted.
Adding Tom who should now about all this.
The reason for adding swiotlb_update_mem_attributes() was because having the call to set_memory_decrypted() in swiotlb_init_with_tbl() triggered a BUG_ON() related to interrupts not being enabled yet during boot. So that call had to be delayed until interrupts were enabled.
Thanks, Tom
On 5/27/21 9:41 AM, Tom Lendacky wrote:
On 5/27/21 8:02 AM, Christoph Hellwig wrote:
On Wed, May 19, 2021 at 11:50:07AM -0700, Florian Fainelli wrote:
You convert this call site with swiotlb_init_io_tlb_mem() which did not do the set_memory_decrypted()+memset(). Is this okay or should swiotlb_init_io_tlb_mem() add an additional argument to do this conditionally?
The zeroing is useful and was missing before. I think having a clean state here is the right thing.
Not sure about the set_memory_decrypted, swiotlb_update_mem_attributes kinda suggests it is too early to set the memory decrupted.
Adding Tom who should now about all this.
The reason for adding swiotlb_update_mem_attributes() was because having the call to set_memory_decrypted() in swiotlb_init_with_tbl() triggered a BUG_ON() related to interrupts not being enabled yet during boot. So that call had to be delayed until interrupts were enabled.
I pulled down and tested the patch set and booted with SME enabled. The following was seen during the boot:
[ 0.134184] BUG: Bad page state in process swapper pfn:108002 [ 0.134196] page:(____ptrval____) refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0 pfn:0x108002 [ 0.134201] flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff) [ 0.134208] raw: 0017ffffc0000000 ffff88847f355e28 ffff88847f355e28 0000000000000000 [ 0.134210] raw: 0000000000000000 0000000000000001 00000000ffffff7f 0000000000000000 [ 0.134212] page dumped because: nonzero mapcount [ 0.134213] Modules linked in: [ 0.134218] CPU: 0 PID: 0 Comm: swapper Not tainted 5.13.0-rc2-sos-custom #3 [ 0.134221] Hardware name: ... [ 0.134224] Call Trace: [ 0.134233] dump_stack+0x76/0x94 [ 0.134244] bad_page+0xa6/0xf0 [ 0.134252] __free_pages_ok+0x331/0x360 [ 0.134256] memblock_free_all+0x158/0x1c1 [ 0.134267] mem_init+0x1f/0x14c [ 0.134273] start_kernel+0x290/0x574 [ 0.134279] secondary_startup_64_no_verify+0xb0/0xbb
I see this about 40 times during the boot, each with a different PFN. The system boots (which seemed odd), but I don't know if there will be side effects to this (I didn't stress the system).
I modified the code to add a flag to not do the set_memory_decrypted(), as suggested by Florian, when invoked from swiotlb_init_with_tbl(), and that eliminated the bad page state BUG.
Thanks, Tom
Thanks, Tom
On Fri, May 28, 2021 at 12:32 AM Tom Lendacky thomas.lendacky@amd.com wrote:
On 5/27/21 9:41 AM, Tom Lendacky wrote:
On 5/27/21 8:02 AM, Christoph Hellwig wrote:
On Wed, May 19, 2021 at 11:50:07AM -0700, Florian Fainelli wrote:
You convert this call site with swiotlb_init_io_tlb_mem() which did not do the set_memory_decrypted()+memset(). Is this okay or should swiotlb_init_io_tlb_mem() add an additional argument to do this conditionally?
The zeroing is useful and was missing before. I think having a clean state here is the right thing.
Not sure about the set_memory_decrypted, swiotlb_update_mem_attributes kinda suggests it is too early to set the memory decrupted.
Adding Tom who should now about all this.
The reason for adding swiotlb_update_mem_attributes() was because having the call to set_memory_decrypted() in swiotlb_init_with_tbl() triggered a BUG_ON() related to interrupts not being enabled yet during boot. So that call had to be delayed until interrupts were enabled.
I pulled down and tested the patch set and booted with SME enabled. The following was seen during the boot:
[ 0.134184] BUG: Bad page state in process swapper pfn:108002 [ 0.134196] page:(____ptrval____) refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0 pfn:0x108002 [ 0.134201] flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff) [ 0.134208] raw: 0017ffffc0000000 ffff88847f355e28 ffff88847f355e28 0000000000000000 [ 0.134210] raw: 0000000000000000 0000000000000001 00000000ffffff7f 0000000000000000 [ 0.134212] page dumped because: nonzero mapcount [ 0.134213] Modules linked in: [ 0.134218] CPU: 0 PID: 0 Comm: swapper Not tainted 5.13.0-rc2-sos-custom #3 [ 0.134221] Hardware name: ... [ 0.134224] Call Trace: [ 0.134233] dump_stack+0x76/0x94 [ 0.134244] bad_page+0xa6/0xf0 [ 0.134252] __free_pages_ok+0x331/0x360 [ 0.134256] memblock_free_all+0x158/0x1c1 [ 0.134267] mem_init+0x1f/0x14c [ 0.134273] start_kernel+0x290/0x574 [ 0.134279] secondary_startup_64_no_verify+0xb0/0xbb
I see this about 40 times during the boot, each with a different PFN. The system boots (which seemed odd), but I don't know if there will be side effects to this (I didn't stress the system).
I modified the code to add a flag to not do the set_memory_decrypted(), as suggested by Florian, when invoked from swiotlb_init_with_tbl(), and that eliminated the bad page state BUG.
Thanks. Will add a flag to skip set_memory_decrypted() in v9.
Thanks, Tom
Thanks, Tom
dri-devel@lists.freedesktop.org
-
Claire Chang -
Tom Lendacky