qemu-devel
[Top][All Lists]
Advanced

[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~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]