|
| From: | David Hildenbrand |
| Subject: | Re: [PATCH v4 7/9] migration: Simplify alignment and alignment checks |
| Date: | Fri, 3 Sep 2021 10:47:34 +0200 |
| User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 |
On 03.09.21 00:32, Peter Xu wrote:
On Thu, Sep 02, 2021 at 03:14:30PM +0200, David Hildenbrand wrote:diff --git a/migration/migration.c b/migration/migration.c index bb909781b7..ae97c2c461 100644 --- a/migration/migration.c +++ b/migration/migration.c @@ -391,7 +391,7 @@ int migrate_send_rp_message_req_pages(MigrationIncomingState *mis, int migrate_send_rp_req_pages(MigrationIncomingState *mis, RAMBlock *rb, ram_addr_t start, uint64_t haddr) { - void *aligned = (void *)(uintptr_t)(haddr & (-qemu_ram_pagesize(rb))); + void *aligned = (void *)QEMU_ALIGN_DOWN(haddr, qemu_ram_pagesize(rb));Is uintptr_t still needed? I thought it would generate a warning otherwise but not sure.
It doesn't in my setup, but maybe it will on 32bit archs ... I discussed this with Phil in https://lkml.kernel.org/r/2c8d80ad-f171-7d5f-3235-92f02fa174b3@redhat.com Maybe QEMU_ALIGN_PTR_DOWN((void *)haddr, qemu_ram_pagesize(rb))); Is really what we want.
Also, maybe ROUND_DOWN() is better? QEMU_ALIGN_DOWN is the slow version for arbitrary numbers.
We do have exactly 2 direct users of ROUND_DOWN() in the tree (well, we do have some more for ROUND_UP) :)
QEMU_ALIGN_DOWN vs. QEMU_ALIGN_DOWN is much easier to map and understand IMHO, and there is usually little need to optimize.
I actually do wonder how much of a difference it actually makes on modern CPUs ...
-- Thanks, David / dhildenb
| [Prev in Thread] | Current Thread | [Next in Thread] |