[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 22/22] target/arm: Add allocation tag storage for system m
From: |
Richard Henderson |
Subject: |
Re: [PATCH v5 22/22] target/arm: Add allocation tag storage for system mode |
Date: |
Fri, 6 Dec 2019 06:14:39 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 |
On 12/6/19 5:02 AM, Peter Maydell wrote:
>> + /*
>> + * Find the physical address for the virtual access.
>> + *
>> + * TODO: It should be possible to have the tag mmu_idx map
>> + * from main memory ram_addr to tag memory host address.
>> + * that would allow this lookup step to be cached as well.
>> + */
>> + section = iotlb_to_section(cs, iotlbentry->addr, iotlbentry->attrs);
>> + physaddr = ((iotlbentry->addr & TARGET_PAGE_MASK) + ptr
>> + + section->offset_within_address_space
>> + - section->offset_within_region);
>
> I'm surprised that going from vaddr to (physaddr, attrs) requires
> this much effort, it seems like the kind of thing we would
> already have a function to do.
There are very few places that need to talk about the actual physical address.
Mostly because that doesn't mean much within qemu -- physical address within
which address space? Usually we want the ramaddr_t (which is a sort of
combination of pa + as), or the host address, or the device the exists at the
pa + as.
>> + /*
>> + * FIXME: Get access length and type so that we can use
>> + * probe_access, so that pages are marked dirty for migration.
>> + */
>> + return tlb_vaddr_to_host(env, tag_physaddr, MMU_DATA_LOAD, mmu_idx);
>
> Hmm, does that mean that a setup with MemTag is not migratable?
> If so, we should at least install a migration-blocker for CPUs
> in that configuration.
It probably does as written. I intend to fix this properly before final.
r~