[PATCH v2 for-4.19 0/3] x86/EPT: avoid undue forcing of MMIO accesses to UC

[PATCH v2 for-4.19 0/3] x86/EPT: avoid undue forcing of MMIO accesses to UC

[Jan Beulich]

..., getting in the way of, in particular, PVH Dom0 accessing its video
frame buffer (if it has a console).

While especially the 1st one may not appear to be so, both of the earlier
patches are strictly prereqs to the last one.

1: correct special page checking in epte_get_entry_emt()
2: avoid marking non-present entries for re-configuring
3: drop questionable mfn_valid() from epte_get_entry_emt()

Jan

[PATCH v2 for-4.19 1/3] x86/EPT: correct special page checking in epte_get_entry_emt()

[Jan Beulich]

mfn_valid() granularity is (currently) 256Mb. Therefore the start of a
1Gb page passing the test doesn't necessarily mean all parts of such a
range would also pass. Yet using the result of mfn_to_page() on an MFN
which doesn't pass mfn_valid() checking is liable to result in a crash
(the invocation of mfn_to_page() alone is presumably "just" UB in such a
case).

Fixes: ca24b2ffdbd9 ("x86/hvm: set 'ipat' in EPT for special pages")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Of course we could leverage mfn_valid() granularity here to do an
increment by more than 1 if mfn_valid() returned false. Yet doing so
likely would want a suitable helper to be introduced first, rather than
open-coding such logic here.
---
v2: New.

--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -519,8 +519,12 @@ int epte_get_entry_emt(struct domain *d,
     }
 
     for ( special_pgs = i = 0; i < (1ul << order); i++ )
-        if ( is_special_page(mfn_to_page(mfn_add(mfn, i))) )
+    {
+        mfn_t cur = mfn_add(mfn, i);
+
+        if ( mfn_valid(cur) && is_special_page(mfn_to_page(cur)) )
             special_pgs++;
+    }
 
     if ( special_pgs )
     {

Re: [PATCH v2 for-4.19 1/3] x86/EPT: correct special page checking in epte_get_entry_emt()

[Roger Pau Monné]

On Wed, Jun 12, 2024 at 03:16:37PM +0200, Jan Beulich wrote:
> mfn_valid() granularity is (currently) 256Mb. Therefore the start of a
> 1Gb page passing the test doesn't necessarily mean all parts of such a
> range would also pass.

How would such a superpage end up in the EPT?

I would assume this can only happen when adding a superpage MMIO that
has part of it return success from mfn_valid()?

> Yet using the result of mfn_to_page() on an MFN
> which doesn't pass mfn_valid() checking is liable to result in a crash
> (the invocation of mfn_to_page() alone is presumably "just" UB in such a
> case).
> 
> Fixes: ca24b2ffdbd9 ("x86/hvm: set 'ipat' in EPT for special pages")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

> ---
> Of course we could leverage mfn_valid() granularity here to do an
> increment by more than 1 if mfn_valid() returned false. Yet doing so
> likely would want a suitable helper to be introduced first, rather than
> open-coding such logic here.

We would still need to call is_special_page() on each 4K chunk, at
which point taking advantage of the mfn_valid() granularity is likely
to make the code more complicated to follow IMO.

Thanks, Roger.

Re: [PATCH v2 for-4.19 1/3] x86/EPT: correct special page checking in epte_get_entry_emt()

[Jan Beulich]

On 12.06.2024 16:11, Roger Pau Monné wrote:
> On Wed, Jun 12, 2024 at 03:16:37PM +0200, Jan Beulich wrote:
>> mfn_valid() granularity is (currently) 256Mb. Therefore the start of a
>> 1Gb page passing the test doesn't necessarily mean all parts of such a
>> range would also pass.
> 
> How would such a superpage end up in the EPT?
> 
> I would assume this can only happen when adding a superpage MMIO that
> has part of it return success from mfn_valid()?

Yes, that's the only way I can think of.

>> Yet using the result of mfn_to_page() on an MFN
>> which doesn't pass mfn_valid() checking is liable to result in a crash
>> (the invocation of mfn_to_page() alone is presumably "just" UB in such a
>> case).
>>
>> Fixes: ca24b2ffdbd9 ("x86/hvm: set 'ipat' in EPT for special pages")
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks.

>> ---
>> Of course we could leverage mfn_valid() granularity here to do an
>> increment by more than 1 if mfn_valid() returned false. Yet doing so
>> likely would want a suitable helper to be introduced first, rather than
>> open-coding such logic here.
> 
> We would still need to call is_special_page() on each 4K chunk,

Why? Within any block for which mfn_valid() returns false, there can be
no RAM pages and hence also no special ones. It's only blocks where
mfn_valid() returns true that we'd need to iterate through page-by-page.

> at
> which point taking advantage of the mfn_valid() granularity is likely
> to make the code more complicated to follow IMO.

Right, this making it more complicated is the main counter argument. Hence
why I think that if to go such a route at all, it would need some new
helper(s) such that at the use sites things still would remain reasonably
clear.

Jan

Re: [PATCH v2 for-4.19 1/3] x86/EPT: correct special page checking in epte_get_entry_emt()

[Roger Pau Monné]

On Wed, Jun 12, 2024 at 04:47:12PM +0200, Jan Beulich wrote:
> On 12.06.2024 16:11, Roger Pau Monné wrote:
> > On Wed, Jun 12, 2024 at 03:16:37PM +0200, Jan Beulich wrote:
> >> mfn_valid() granularity is (currently) 256Mb. Therefore the start of a
> >> 1Gb page passing the test doesn't necessarily mean all parts of such a
> >> range would also pass.
> > 
> > How would such a superpage end up in the EPT?
> > 
> > I would assume this can only happen when adding a superpage MMIO that
> > has part of it return success from mfn_valid()?
> 
> Yes, that's the only way I can think of.
> 
> >> Yet using the result of mfn_to_page() on an MFN
> >> which doesn't pass mfn_valid() checking is liable to result in a crash
> >> (the invocation of mfn_to_page() alone is presumably "just" UB in such a
> >> case).
> >>
> >> Fixes: ca24b2ffdbd9 ("x86/hvm: set 'ipat' in EPT for special pages")
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > 
> > Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
> 
> Thanks.
> 
> >> ---
> >> Of course we could leverage mfn_valid() granularity here to do an
> >> increment by more than 1 if mfn_valid() returned false. Yet doing so
> >> likely would want a suitable helper to be introduced first, rather than
> >> open-coding such logic here.
> > 
> > We would still need to call is_special_page() on each 4K chunk,
> 
> Why? Within any block for which mfn_valid() returns false, there can be
> no RAM pages and hence also no special ones. It's only blocks where
> mfn_valid() returns true that we'd need to iterate through page-by-page.

Oh right, I was thinking the other way around (mfn_valid() returning
true), never mind.

> > at
> > which point taking advantage of the mfn_valid() granularity is likely
> > to make the code more complicated to follow IMO.
> 
> Right, this making it more complicated is the main counter argument. Hence
> why I think that if to go such a route at all, it would need some new
> helper(s) such that at the use sites things still would remain reasonably
> clear.

We could also add an extra check to exit the loop early if special
pages have been found but don't match the current loop index, as it's
all special pages or none.

Thanks, Roger.

Re: [PATCH v2 for-4.19 1/3] x86/EPT: correct special page checking in epte_get_entry_emt()

[Jan Beulich]

On 12.06.2024 17:02, Roger Pau Monné wrote:
> We could also add an extra check to exit the loop early if special
> pages have been found but don't match the current loop index, as it's
> all special pages or none.

I was actually considering to make such a change, but then concluded
that in the common case there'll be no special pages anyway, and hence
we need to run the loop to completion anyway.

Jan

Re: [PATCH v2 for-4.19 1/3] x86/EPT: correct special page checking in epte_get_entry_emt()

[Oleksii K.]

On Wed, 2024-06-12 at 15:16 +0200, Jan Beulich wrote:
> mfn_valid() granularity is (currently) 256Mb. Therefore the start of
> a
> 1Gb page passing the test doesn't necessarily mean all parts of such
> a
> range would also pass. Yet using the result of mfn_to_page() on an
> MFN
> which doesn't pass mfn_valid() checking is liable to result in a
> crash
> (the invocation of mfn_to_page() alone is presumably "just" UB in
> such a
> case).
> 
> Fixes: ca24b2ffdbd9 ("x86/hvm: set 'ipat' in EPT for special pages")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

~ Oleksii
> ---
> Of course we could leverage mfn_valid() granularity here to do an
> increment by more than 1 if mfn_valid() returned false. Yet doing so
> likely would want a suitable helper to be introduced first, rather
> than
> open-coding such logic here.
> ---
> v2: New.
> 
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -519,8 +519,12 @@ int epte_get_entry_emt(struct domain *d,
>      }
>  
>      for ( special_pgs = i = 0; i < (1ul << order); i++ )
> -        if ( is_special_page(mfn_to_page(mfn_add(mfn, i))) )
> +    {
> +        mfn_t cur = mfn_add(mfn, i);
> +
> +        if ( mfn_valid(cur) && is_special_page(mfn_to_page(cur)) )
>              special_pgs++;
> +    }
>  
>      if ( special_pgs )
>      {
> 

[PATCH v2 for-4.19 2/3] x86/EPT: avoid marking non-present entries for re-configuring

[Jan Beulich]

For non-present entries EMT, like most other fields, is meaningless to
hardware. Make the logic in ept_set_entry() setting the field (and iPAT)
conditional upon dealing with a present entry, leaving the value at 0
otherwise. This has two effects for epte_get_entry_emt() which we'll
want to leverage subsequently:
1) The call moved here now won't be issued with INVALID_MFN anymore (a
   respective BUG_ON() is being added).
2) Neither of the other two calls could now be issued with a truncated
   form of INVALID_MFN anymore (as long as there's no bug anywhere
   marking an entry present when that was populated using INVALID_MFN).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: New.

--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -650,6 +650,8 @@ static int cf_check resolve_misconfig(st
             if ( e.emt != MTRR_NUM_TYPES )
                 break;
 
+            ASSERT(is_epte_present(&e));
+
             if ( level == 0 )
             {
                 for ( gfn -= i, i = 0; i < EPT_PAGETABLE_ENTRIES; ++i )
@@ -915,17 +917,6 @@ ept_set_entry(struct p2m_domain *p2m, gf
 
     if ( mfn_valid(mfn) || p2m_allows_invalid_mfn(p2mt) )
     {
-        bool ipat;
-        int emt = epte_get_entry_emt(p2m->domain, _gfn(gfn), mfn,
-                                     i * EPT_TABLE_ORDER, &ipat,
-                                     p2mt);
-
-        if ( emt >= 0 )
-            new_entry.emt = emt;
-        else /* ept_handle_misconfig() will need to take care of this. */
-            new_entry.emt = MTRR_NUM_TYPES;
-
-        new_entry.ipat = ipat;
         new_entry.sp = !!i;
         new_entry.sa_p2mt = p2mt;
         new_entry.access = p2ma;
@@ -941,6 +932,22 @@ ept_set_entry(struct p2m_domain *p2m, gf
             need_modify_vtd_table = 0;
 
         ept_p2m_type_to_flags(p2m, &new_entry);
+
+        if ( is_epte_present(&new_entry) )
+        {
+            bool ipat;
+            int emt = epte_get_entry_emt(p2m->domain, _gfn(gfn), mfn,
+                                         i * EPT_TABLE_ORDER, &ipat,
+                                         p2mt);
+
+            BUG_ON(mfn_eq(mfn, INVALID_MFN));
+
+            if ( emt >= 0 )
+                new_entry.emt = emt;
+            else /* ept_handle_misconfig() will need to take care of this. */
+                new_entry.emt = MTRR_NUM_TYPES;
+            new_entry.ipat = ipat;
+        }
     }
 
     if ( sve != -1 )

Re: [PATCH v2 for-4.19 2/3] x86/EPT: avoid marking non-present entries for re-configuring

[Roger Pau Monné]

On Wed, Jun 12, 2024 at 03:16:59PM +0200, Jan Beulich wrote:
> For non-present entries EMT, like most other fields, is meaningless to
> hardware. Make the logic in ept_set_entry() setting the field (and iPAT)
> conditional upon dealing with a present entry, leaving the value at 0
> otherwise. This has two effects for epte_get_entry_emt() which we'll
> want to leverage subsequently:
> 1) The call moved here now won't be issued with INVALID_MFN anymore (a
>    respective BUG_ON() is being added).
> 2) Neither of the other two calls could now be issued with a truncated
>    form of INVALID_MFN anymore (as long as there's no bug anywhere
>    marking an entry present when that was populated using INVALID_MFN).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> v2: New.
> 
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -650,6 +650,8 @@ static int cf_check resolve_misconfig(st
>              if ( e.emt != MTRR_NUM_TYPES )
>                  break;
>  
> +            ASSERT(is_epte_present(&e));

If this is added here, then there's a condition further below:

if ( !is_epte_valid(&e) || !is_epte_present(&e) )

That needs adjusting AFAICT.

However, in ept_set_entry() we seem to unconditionally call
resolve_misconfig() against the new entry to be populated, won't this
possibly cause resolve_misconfig() to be called against non-present
EPT entries?  I think this is fine because such non-present entries
will have emt == 0, and hence will take the break just ahead of the
added ASSERT().

> +
>              if ( level == 0 )
>              {
>                  for ( gfn -= i, i = 0; i < EPT_PAGETABLE_ENTRIES; ++i )
> @@ -915,17 +917,6 @@ ept_set_entry(struct p2m_domain *p2m, gf
>  
>      if ( mfn_valid(mfn) || p2m_allows_invalid_mfn(p2mt) )
>      {
> -        bool ipat;
> -        int emt = epte_get_entry_emt(p2m->domain, _gfn(gfn), mfn,
> -                                     i * EPT_TABLE_ORDER, &ipat,
> -                                     p2mt);
> -
> -        if ( emt >= 0 )
> -            new_entry.emt = emt;
> -        else /* ept_handle_misconfig() will need to take care of this. */
> -            new_entry.emt = MTRR_NUM_TYPES;
> -
> -        new_entry.ipat = ipat;
>          new_entry.sp = !!i;
>          new_entry.sa_p2mt = p2mt;
>          new_entry.access = p2ma;
> @@ -941,6 +932,22 @@ ept_set_entry(struct p2m_domain *p2m, gf
>              need_modify_vtd_table = 0;
>  
>          ept_p2m_type_to_flags(p2m, &new_entry);
> +
> +        if ( is_epte_present(&new_entry) )
> +        {
> +            bool ipat;
> +            int emt = epte_get_entry_emt(p2m->domain, _gfn(gfn), mfn,
> +                                         i * EPT_TABLE_ORDER, &ipat,
> +                                         p2mt);
> +
> +            BUG_ON(mfn_eq(mfn, INVALID_MFN));
> +
> +            if ( emt >= 0 )
> +                new_entry.emt = emt;
> +            else /* ept_handle_misconfig() will need to take care of this. */
> +                new_entry.emt = MTRR_NUM_TYPES;
> +            new_entry.ipat = ipat;
> +        }

Should we assert that if new_entry.emt == MTRR_NUM_TYPES the entry
must have the present bit set before the atomic_write_ept_entry()
call?

Thanks, Roger.

Re: [PATCH v2 for-4.19 2/3] x86/EPT: avoid marking non-present entries for re-configuring

[Jan Beulich]

On 12.06.2024 16:38, Roger Pau Monné wrote:
> On Wed, Jun 12, 2024 at 03:16:59PM +0200, Jan Beulich wrote:
>> For non-present entries EMT, like most other fields, is meaningless to
>> hardware. Make the logic in ept_set_entry() setting the field (and iPAT)
>> conditional upon dealing with a present entry, leaving the value at 0
>> otherwise. This has two effects for epte_get_entry_emt() which we'll
>> want to leverage subsequently:
>> 1) The call moved here now won't be issued with INVALID_MFN anymore (a
>>    respective BUG_ON() is being added).
>> 2) Neither of the other two calls could now be issued with a truncated
>>    form of INVALID_MFN anymore (as long as there's no bug anywhere
>>    marking an entry present when that was populated using INVALID_MFN).
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> v2: New.
>>
>> --- a/xen/arch/x86/mm/p2m-ept.c
>> +++ b/xen/arch/x86/mm/p2m-ept.c
>> @@ -650,6 +650,8 @@ static int cf_check resolve_misconfig(st
>>              if ( e.emt != MTRR_NUM_TYPES )
>>                  break;
>>  
>> +            ASSERT(is_epte_present(&e));
> 
> If this is added here, then there's a condition further below:
> 
> if ( !is_epte_valid(&e) || !is_epte_present(&e) )
> 
> That needs adjusting AFAICT.

I don't think so, because e was re-fetched in between.

> However, in ept_set_entry() we seem to unconditionally call
> resolve_misconfig() against the new entry to be populated, won't this
> possibly cause resolve_misconfig() to be called against non-present
> EPT entries?  I think this is fine because such non-present entries
> will have emt == 0, and hence will take the break just ahead of the
> added ASSERT().

Right, hence how I placed this assertion.

>> @@ -941,6 +932,22 @@ ept_set_entry(struct p2m_domain *p2m, gf
>>              need_modify_vtd_table = 0;
>>  
>>          ept_p2m_type_to_flags(p2m, &new_entry);
>> +
>> +        if ( is_epte_present(&new_entry) )
>> +        {
>> +            bool ipat;
>> +            int emt = epte_get_entry_emt(p2m->domain, _gfn(gfn), mfn,
>> +                                         i * EPT_TABLE_ORDER, &ipat,
>> +                                         p2mt);
>> +
>> +            BUG_ON(mfn_eq(mfn, INVALID_MFN));
>> +
>> +            if ( emt >= 0 )
>> +                new_entry.emt = emt;
>> +            else /* ept_handle_misconfig() will need to take care of this. */
>> +                new_entry.emt = MTRR_NUM_TYPES;
>> +            new_entry.ipat = ipat;
>> +        }
> 
> Should we assert that if new_entry.emt == MTRR_NUM_TYPES the entry
> must have the present bit set before the atomic_write_ept_entry()
> call?

This would feel excessive to me. All writing to new_entry is close together,
immediately ahead of that atomic_write_ept_entry(). And we're (now) writing
MTRR_NUM_TYPES only when is_epte_present() is true (note that it's not "the
present bit").

Jan

Re: [PATCH v2 for-4.19 2/3] x86/EPT: avoid marking non-present entries for re-configuring

[Roger Pau Monné]

On Wed, Jun 12, 2024 at 04:53:14PM +0200, Jan Beulich wrote:
> On 12.06.2024 16:38, Roger Pau Monné wrote:
> > On Wed, Jun 12, 2024 at 03:16:59PM +0200, Jan Beulich wrote:
> >> For non-present entries EMT, like most other fields, is meaningless to
> >> hardware. Make the logic in ept_set_entry() setting the field (and iPAT)
> >> conditional upon dealing with a present entry, leaving the value at 0
> >> otherwise. This has two effects for epte_get_entry_emt() which we'll
> >> want to leverage subsequently:
> >> 1) The call moved here now won't be issued with INVALID_MFN anymore (a
> >>    respective BUG_ON() is being added).
> >> 2) Neither of the other two calls could now be issued with a truncated
> >>    form of INVALID_MFN anymore (as long as there's no bug anywhere
> >>    marking an entry present when that was populated using INVALID_MFN).
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

> >> ---
> >> v2: New.
> >>
> >> --- a/xen/arch/x86/mm/p2m-ept.c
> >> +++ b/xen/arch/x86/mm/p2m-ept.c
> >> @@ -650,6 +650,8 @@ static int cf_check resolve_misconfig(st
> >>              if ( e.emt != MTRR_NUM_TYPES )
> >>                  break;
> >>  
> >> +            ASSERT(is_epte_present(&e));
> > 
> > If this is added here, then there's a condition further below:
> > 
> > if ( !is_epte_valid(&e) || !is_epte_present(&e) )
> > 
> > That needs adjusting AFAICT.
> 
> I don't think so, because e was re-fetched in between.

Oh, I see, we take the opportunity to do the recalculation for all the
EPT entries that share the same page table.

> > However, in ept_set_entry() we seem to unconditionally call
> > resolve_misconfig() against the new entry to be populated, won't this
> > possibly cause resolve_misconfig() to be called against non-present
> > EPT entries?  I think this is fine because such non-present entries
> > will have emt == 0, and hence will take the break just ahead of the
> > added ASSERT().
> 
> Right, hence how I placed this assertion.

OK, just wanted to double check.

> >> @@ -941,6 +932,22 @@ ept_set_entry(struct p2m_domain *p2m, gf
> >>              need_modify_vtd_table = 0;
> >>  
> >>          ept_p2m_type_to_flags(p2m, &new_entry);
> >> +
> >> +        if ( is_epte_present(&new_entry) )
> >> +        {
> >> +            bool ipat;
> >> +            int emt = epte_get_entry_emt(p2m->domain, _gfn(gfn), mfn,
> >> +                                         i * EPT_TABLE_ORDER, &ipat,
> >> +                                         p2mt);
> >> +
> >> +            BUG_ON(mfn_eq(mfn, INVALID_MFN));
> >> +
> >> +            if ( emt >= 0 )
> >> +                new_entry.emt = emt;
> >> +            else /* ept_handle_misconfig() will need to take care of this. */
> >> +                new_entry.emt = MTRR_NUM_TYPES;
> >> +            new_entry.ipat = ipat;
> >> +        }
> > 
> > Should we assert that if new_entry.emt == MTRR_NUM_TYPES the entry
> > must have the present bit set before the atomic_write_ept_entry()
> > call?
> 
> This would feel excessive to me. All writing to new_entry is close together,
> immediately ahead of that atomic_write_ept_entry(). And we're (now) writing
> MTRR_NUM_TYPES only when is_epte_present() is true (note that it's not "the
> present bit").

Fair enough.

Thanks, Roger.

Re: [PATCH v2 for-4.19 2/3] x86/EPT: avoid marking non-present entries for re-configuring

[Oleksii K.]

On Wed, 2024-06-12 at 15:16 +0200, Jan Beulich wrote:
> For non-present entries EMT, like most other fields, is meaningless
> to
> hardware. Make the logic in ept_set_entry() setting the field (and
> iPAT)
> conditional upon dealing with a present entry, leaving the value at 0
> otherwise. This has two effects for epte_get_entry_emt() which we'll
> want to leverage subsequently:
> 1) The call moved here now won't be issued with INVALID_MFN anymore
> (a
>    respective BUG_ON() is being added).
> 2) Neither of the other two calls could now be issued with a
> truncated
>    form of INVALID_MFN anymore (as long as there's no bug anywhere
>    marking an entry present when that was populated using
> INVALID_MFN).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>

~ Oleksii
> ---
> v2: New.
> 
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -650,6 +650,8 @@ static int cf_check resolve_misconfig(st
>              if ( e.emt != MTRR_NUM_TYPES )
>                  break;
>  
> +            ASSERT(is_epte_present(&e));
> +
>              if ( level == 0 )
>              {
>                  for ( gfn -= i, i = 0; i < EPT_PAGETABLE_ENTRIES;
> ++i )
> @@ -915,17 +917,6 @@ ept_set_entry(struct p2m_domain *p2m, gf
>  
>      if ( mfn_valid(mfn) || p2m_allows_invalid_mfn(p2mt) )
>      {
> -        bool ipat;
> -        int emt = epte_get_entry_emt(p2m->domain, _gfn(gfn), mfn,
> -                                     i * EPT_TABLE_ORDER, &ipat,
> -                                     p2mt);
> -
> -        if ( emt >= 0 )
> -            new_entry.emt = emt;
> -        else /* ept_handle_misconfig() will need to take care of
> this. */
> -            new_entry.emt = MTRR_NUM_TYPES;
> -
> -        new_entry.ipat = ipat;
>          new_entry.sp = !!i;
>          new_entry.sa_p2mt = p2mt;
>          new_entry.access = p2ma;
> @@ -941,6 +932,22 @@ ept_set_entry(struct p2m_domain *p2m, gf
>              need_modify_vtd_table = 0;
>  
>          ept_p2m_type_to_flags(p2m, &new_entry);
> +
> +        if ( is_epte_present(&new_entry) )
> +        {
> +            bool ipat;
> +            int emt = epte_get_entry_emt(p2m->domain, _gfn(gfn),
> mfn,
> +                                         i * EPT_TABLE_ORDER, &ipat,
> +                                         p2mt);
> +
> +            BUG_ON(mfn_eq(mfn, INVALID_MFN));
> +
> +            if ( emt >= 0 )
> +                new_entry.emt = emt;
> +            else /* ept_handle_misconfig() will need to take care of
> this. */
> +                new_entry.emt = MTRR_NUM_TYPES;
> +            new_entry.ipat = ipat;
> +        }
>      }
>  
>      if ( sve != -1 )
> 

[PATCH v2 for-4.19 3/3] x86/EPT: drop questionable mfn_valid() from epte_get_entry_emt()

[Jan Beulich]

mfn_valid() is RAM-focused; it will often return false for MMIO. Yet
access to actual MMIO space should not generally be restricted to UC
only; especially video frame buffer accesses are unduly affected by such
a restriction.

Since, as of ???????????? ("x86/EPT: avoid marking non-present entries
for re-configuring"), the function won't be called with INVALID_MFN or,
worse, truncated forms thereof anymore, we call fully drop that check.

Fixes: 81fd0d3ca4b2 ("x86/hvm: simplify 'mmio_direct' check in epte_get_entry_emt()")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
Considering that we've just declared PVH Dom0 "supported", this may well
qualify for 4.19. The issue was specifically very noticeable there.
---
v2: Different approach (and hence different title and description).

--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -501,12 +501,6 @@ int epte_get_entry_emt(struct domain *d,
         return -1;
     }
 
-    if ( !mfn_valid(mfn) )
-    {
-        *ipat = true;
-        return X86_MT_UC;
-    }
-
     /*
      * Conditional must be kept in sync with the code in
      * {iomem,ioports}_{permit,deny}_access().

Re: [PATCH v2 for-4.19 3/3] x86/EPT: drop questionable mfn_valid() from epte_get_entry_emt()

[Roger Pau Monné]

On Wed, Jun 12, 2024 at 03:17:38PM +0200, Jan Beulich wrote:
> mfn_valid() is RAM-focused; it will often return false for MMIO. Yet
> access to actual MMIO space should not generally be restricted to UC
> only; especially video frame buffer accesses are unduly affected by such
> a restriction.
> 
> Since, as of ???????????? ("x86/EPT: avoid marking non-present entries
> for re-configuring"), the function won't be called with INVALID_MFN or,
> worse, truncated forms thereof anymore, we call fully drop that check.
> 
> Fixes: 81fd0d3ca4b2 ("x86/hvm: simplify 'mmio_direct' check in epte_get_entry_emt()")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

I do think this is the way to go (removing quirks from
epte_get_entry_emt()), however it's a risky change to make at this
point in the release.

If this turns out to cause some unexpected damage, it would only
affect HVM guests with PCI passthrough and PVH dom0, which I consider
not great, but tolerable.

I would be more comfortable with making the change just not so close
to the release, but that's where we are.

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

I wonder if you should explicitly mention that if adding the
mfn_valid() check was done to ensure all mappings to MMIO are created
with effective UC caching attribute it won't be fully correct either.
Xen could map those using a different effective caching attribute by
virtue of host MTRRs being in effect plus Xen chosen PAT attributes.

Thanks, Roger.

Re: [PATCH v2 for-4.19 3/3] x86/EPT: drop questionable mfn_valid() from epte_get_entry_emt()

[Jan Beulich]

On 12.06.2024 17:00, Roger Pau Monné wrote:
> On Wed, Jun 12, 2024 at 03:17:38PM +0200, Jan Beulich wrote:
>> mfn_valid() is RAM-focused; it will often return false for MMIO. Yet
>> access to actual MMIO space should not generally be restricted to UC
>> only; especially video frame buffer accesses are unduly affected by such
>> a restriction.
>>
>> Since, as of ???????????? ("x86/EPT: avoid marking non-present entries
>> for re-configuring"), the function won't be called with INVALID_MFN or,
>> worse, truncated forms thereof anymore, we call fully drop that check.
>>
>> Fixes: 81fd0d3ca4b2 ("x86/hvm: simplify 'mmio_direct' check in epte_get_entry_emt()")
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> 
> I do think this is the way to go (removing quirks from
> epte_get_entry_emt()), however it's a risky change to make at this
> point in the release.
> 
> If this turns out to cause some unexpected damage, it would only
> affect HVM guests with PCI passthrough and PVH dom0, which I consider
> not great, but tolerable.
> 
> I would be more comfortable with making the change just not so close
> to the release, but that's where we are.

Certainly, and I could live with Oleksii revoking his R-a-b (or simply
not offering it for either of the two prereq changes). Main thing for
me is - PVH Dom0 finally isn't so horribly slow anymore. However, if it
doesn't go into the release, then I'd also be unsure about eventual
backporting.

> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks.

> I wonder if you should explicitly mention that if adding the
> mfn_valid() check was done to ensure all mappings to MMIO are created
> with effective UC caching attribute it won't be fully correct either.
> Xen could map those using a different effective caching attribute by
> virtue of host MTRRs being in effect plus Xen chosen PAT attributes.

Well, the mfn_valid() can't have been there to cover _all_ MMIO. It was
maybe a flawed initial attempt at doing so, and then wasn't properly
adjusted / dropped. So overall - no, I don't think extending the
description with anything along the lines of the above would make a lot
of sense.

Jan

Re: [PATCH v2 for-4.19 3/3] x86/EPT: drop questionable mfn_valid() from epte_get_entry_emt()

[Roger Pau Monné]

On Wed, Jun 12, 2024 at 05:14:37PM +0200, Jan Beulich wrote:
> On 12.06.2024 17:00, Roger Pau Monné wrote:
> > I wonder if you should explicitly mention that if adding the
> > mfn_valid() check was done to ensure all mappings to MMIO are created
> > with effective UC caching attribute it won't be fully correct either.
> > Xen could map those using a different effective caching attribute by
> > virtue of host MTRRs being in effect plus Xen chosen PAT attributes.
> 
> Well, the mfn_valid() can't have been there to cover _all_ MMIO. It was
> maybe a flawed initial attempt at doing so, and then wasn't properly
> adjusted / dropped. So overall - no, I don't think extending the
> description with anything along the lines of the above would make a lot
> of sense.

I realized myself when writing the paragraph that I wouldn't even know
how to word it properly, neither it would be much helpful without
knowing the exact intention the mfn_valid() check was added for.

Thanks, Roger.

Re: [PATCH v2 for-4.19 3/3] x86/EPT: drop questionable mfn_valid() from epte_get_entry_emt()

[Roger Pau Monné]

On Wed, Jun 12, 2024 at 05:14:37PM +0200, Jan Beulich wrote:
> On 12.06.2024 17:00, Roger Pau Monné wrote:
> > On Wed, Jun 12, 2024 at 03:17:38PM +0200, Jan Beulich wrote:
> >> mfn_valid() is RAM-focused; it will often return false for MMIO. Yet
> >> access to actual MMIO space should not generally be restricted to UC
> >> only; especially video frame buffer accesses are unduly affected by such
> >> a restriction.
> >>
> >> Since, as of ???????????? ("x86/EPT: avoid marking non-present entries
> >> for re-configuring"), the function won't be called with INVALID_MFN or,
> >> worse, truncated forms thereof anymore, we call fully drop that check.
> >>
> >> Fixes: 81fd0d3ca4b2 ("x86/hvm: simplify 'mmio_direct' check in epte_get_entry_emt()")
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >> Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> > 
> > I do think this is the way to go (removing quirks from
> > epte_get_entry_emt()), however it's a risky change to make at this
> > point in the release.
> > 
> > If this turns out to cause some unexpected damage, it would only
> > affect HVM guests with PCI passthrough and PVH dom0, which I consider
> > not great, but tolerable.
> > 
> > I would be more comfortable with making the change just not so close
> > to the release, but that's where we are.
> 
> Certainly, and I could live with Oleksii revoking his R-a-b (or simply
> not offering it for either of the two prereq changes). Main thing for
> me is - PVH Dom0 finally isn't so horribly slow anymore. However, if it
> doesn't go into the release, then I'd also be unsure about eventual
> backporting.

Thinking about this, it's also likely to fix issues with PCI
passthrough to HVM guests, so I'm quite sure we would need to
backport it.

David Woodhouse already had to fix it once:

https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=30921dc2df3665ca1b2593595aa6725ff013d386

And I'm quite sure this fix was not related to PVH dom0.

Thanks, Roger.