x86/shadow: further correct MMIO handling in _sh_propagate()

While c61a6f74f8 ("x86: enforce consistent cachability of MMIO
mappings") correctly converted one !mfn_valid() check there, two others
were wrongly left untouched: Both cachability control and log-dirty
tracking ought to be uniformly handled/excluded for all (non-)MMIO
ranges, not just ones qualifiable by mfn_valid().

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
This commit is contained in:
Jan Beulich committed 2023-01-20 09:20:26 +01:00
1 parent 321b1b5eb3
commit 1d99732f2b
1 file changed
+2 -4
+2 -4
View File
@@ -550,8 +550,7 @@ _sh_propagate(struct vcpu *v,
* caching attributes in the shadows to match what was asked for.
*/
if ( (level == 1) && is_hvm_domain(d) &&
(!mfn_valid(target_mfn) ||
!is_special_page(mfn_to_page(target_mfn))) )
(mmio_mfn || !is_special_page(mfn_to_page(target_mfn))) )
{
int type;
@@ -662,8 +661,7 @@ _sh_propagate(struct vcpu *v,
* (We handle log-dirty entirely inside the shadow code, without using the
* p2m_ram_logdirty p2m type: only HAP uses that.)
*/
if ( level == 1 && unlikely(shadow_mode_log_dirty(d)) &&
mfn_valid(target_mfn) )
if ( level == 1 && unlikely(shadow_mode_log_dirty(d)) && !mmio_mfn )
{
if ( ft & FETCH_TYPE_WRITE )
paging_mark_dirty(d, target_mfn);
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.