From: Peter Xu <peterx@redhat.com>
To: qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>
Cc: peterx@redhat.com, Paolo Bonzini <pbonzini@redhat.com>,
David Hildenbrand <david@redhat.com>
Subject: [PULL 07/14] physmem: factor out RAM/ROMD check in memory_access_is_direct()
Date: Tue, 11 Feb 2025 17:50:51 -0500 [thread overview]
Message-ID: <20250211225059.182533-8-peterx@redhat.com> (raw)
In-Reply-To: <20250211225059.182533-1-peterx@redhat.com>
From: David Hildenbrand <david@redhat.com>
Let's factor more of the generic "is this directly accessible" check,
independent of the "write" condition out.
Note that the "!mr->rom_device" check in the write case essentially
disallows the memory_region_is_romd() condition again. Further note that
RAM DEVICE regions are also RAM regions, so we can check for RAM+ROMD
first.
This is a preparation for further changes.
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Link: https://lore.kernel.org/r/20250210084648.33798-3-david@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
---
include/exec/memory.h | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 5cd7574c60..cb35c38402 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -2997,6 +2997,10 @@ bool prepare_mmio_access(MemoryRegion *mr);
static inline bool memory_access_is_direct(MemoryRegion *mr, bool is_write)
{
+ /* ROM DEVICE regions only allow direct access if in ROMD mode. */
+ if (!memory_region_is_ram(mr) && !memory_region_is_romd(mr)) {
+ return false;
+ }
/*
* RAM DEVICE regions can be accessed directly using memcpy, but it might
* be MMIO and access using mempy can be wrong (e.g., using instructions not
@@ -3006,11 +3010,9 @@ static inline bool memory_access_is_direct(MemoryRegion *mr, bool is_write)
return false;
}
if (is_write) {
- return memory_region_is_ram(mr) && !mr->readonly &&
- !mr->rom_device;
- } else {
- return memory_region_is_ram(mr) || memory_region_is_romd(mr);
+ return !mr->readonly && !mr->rom_device;
}
+ return true;
}
/**
--
2.47.0
next prev parent reply other threads:[~2025-02-11 22:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-11 22:50 [PULL 00/14] Mem next patches Peter Xu
2025-02-11 22:50 ` [PULL 01/14] system/physmem: take into account fd_offset for file fallocate Peter Xu
2025-02-11 22:50 ` [PULL 02/14] os: add an ability to lock memory on_fault Peter Xu
2025-02-12 14:13 ` Stefan Hajnoczi
2025-02-12 14:17 ` Daniil Tatianin
2025-02-11 22:50 ` [PULL 03/14] system/vl: extract overcommit option parsing into a helper Peter Xu
2025-02-11 22:50 ` [PULL 04/14] system: introduce a new MlockState enum Peter Xu
2025-02-11 22:50 ` [PULL 05/14] overcommit: introduce mem-lock=on-fault Peter Xu
2025-02-11 22:50 ` [PULL 06/14] physmem: factor out memory_region_is_ram_device() check in memory_access_is_direct() Peter Xu
2025-02-11 22:50 ` Peter Xu [this message]
2025-02-11 22:50 ` [PULL 08/14] physmem: factor out direct access check into memory_region_supports_direct_access() Peter Xu
2025-02-11 22:50 ` [PULL 09/14] physmem: disallow direct access to RAM DEVICE in address_space_write_rom() Peter Xu
2025-02-11 22:50 ` [PULL 10/14] memory: pass MemTxAttrs to memory_access_is_direct() Peter Xu
2025-02-11 22:50 ` [PULL 11/14] hmp: use cpu_get_phys_page_debug() in hmp_gva2gpa() Peter Xu
2025-02-11 22:50 ` [PULL 12/14] physmem: teach cpu_memory_rw_debug() to write to more memory regions Peter Xu
2025-02-11 22:50 ` [PULL 13/14] system/physmem: handle hugetlb correctly in qemu_ram_remap() Peter Xu
2025-02-11 22:50 ` [PULL 14/14] system/physmem: poisoned memory discard on reboot Peter Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250211225059.182533-8-peterx@redhat.com \
--to=peterx@redhat.com \
--cc=david@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).