[PATCH v2] xen: allow guest_remove_page to remove p2m_mmio_direct pages

[PATCH v2] xen: allow guest_remove_page to remove p2m_mmio_direct pages

[Roger Pau Monne]

IF a guest tries to do a foreign/grant mapping in a memory region
marked as p2m_mmio_direct Xen will complain with the following
message:

(XEN) memory.c:241:d0v0 Bad page free for domain 0

Albeit the mapping will succeed. This is specially problematic for PVH
Dom0, in which we map all the e820 holes and memory up to 4GB as
p2m_mmio_direct.

In order to deal with it, add a special casing for p2m_mmio_direct
regions in guest_remove_page if the domain is a hardware domain, that
calls clear_mmio_p2m_entry in order to remove the mappings.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
---
Changes since v1:
 - Remove the is_hardware_domain check.
---
 xen/common/memory.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/xen/common/memory.c b/xen/common/memory.c
index 257f4b0..c2dd31b 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -204,6 +204,12 @@ int guest_remove_page(struct domain *d, unsigned long gmfn)
         p2m_mem_paging_drop_page(d, gmfn, p2mt);
         return 1;
     }
+    if ( p2mt == p2m_mmio_direct )
+    {
+        clear_mmio_p2m_entry(d, gmfn);
+        put_gfn(d, gmfn);
+        return 1;
+    }
 #else
     mfn = gmfn_to_mfn(d, gmfn);
 #endif
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH v2] xen: allow guest_remove_page to remove p2m_mmio_direct pages

[Tim Deegan]

At 16:45 +0200 on 19 Jun (1403192739), Roger Pau Monne wrote:
> IF a guest tries to do a foreign/grant mapping in a memory region
> marked as p2m_mmio_direct Xen will complain with the following
> message:
> 
> (XEN) memory.c:241:d0v0 Bad page free for domain 0
> 
> Albeit the mapping will succeed. This is specially problematic for PVH
> Dom0, in which we map all the e820 holes and memory up to 4GB as
> p2m_mmio_direct.
> 
> In order to deal with it, add a special casing for p2m_mmio_direct
> regions in guest_remove_page if the domain is a hardware domain, that
> calls clear_mmio_p2m_entry in order to remove the mappings.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

Acked-by: Tim Deegan <tim@xen.org>

as being an improvement on what's there right now.  But as I said, I
think code that relies on this is probably doing the wrong thing -- in
this case having MMIOmaps og all non-RAM areas seems wrong; dom0 ought
to know what addresses are really hardware and map them appropriately.

Tim.

> ---
> Changes since v1:
>  - Remove the is_hardware_domain check.
> ---
>  xen/common/memory.c |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/common/memory.c b/xen/common/memory.c
> index 257f4b0..c2dd31b 100644
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -204,6 +204,12 @@ int guest_remove_page(struct domain *d, unsigned long gmfn)
>          p2m_mem_paging_drop_page(d, gmfn, p2mt);
>          return 1;
>      }
> +    if ( p2mt == p2m_mmio_direct )
> +    {
> +        clear_mmio_p2m_entry(d, gmfn);
> +        put_gfn(d, gmfn);
> +        return 1;
> +    }
>  #else
>      mfn = gmfn_to_mfn(d, gmfn);
>  #endif
> -- 
> 1.7.7.5 (Apple Git-26)
> 

Re: [PATCH v2] xen: allow guest_remove_page to remove p2m_mmio_direct pages

[Roger Pau Monné]

On 19/06/14 17:23, Tim Deegan wrote:
> At 16:45 +0200 on 19 Jun (1403192739), Roger Pau Monne wrote:
>> IF a guest tries to do a foreign/grant mapping in a memory region
>> marked as p2m_mmio_direct Xen will complain with the following
>> message:
>>
>> (XEN) memory.c:241:d0v0 Bad page free for domain 0
>>
>> Albeit the mapping will succeed. This is specially problematic for PVH
>> Dom0, in which we map all the e820 holes and memory up to 4GB as
>> p2m_mmio_direct.
>>
>> In order to deal with it, add a special casing for p2m_mmio_direct
>> regions in guest_remove_page if the domain is a hardware domain, that
>> calls clear_mmio_p2m_entry in order to remove the mappings.
>>
>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> 
> Acked-by: Tim Deegan <tim@xen.org>
> 
> as being an improvement on what's there right now.  But as I said, I
> think code that relies on this is probably doing the wrong thing -- in
> this case having MMIOmaps og all non-RAM areas seems wrong; dom0 ought
> to know what addresses are really hardware and map them appropriately.

Yes, the problem is mainly in the Xen Dom0 PVH domain builder, that maps
all holes and not assigned memory up to 4GB as MMIO in the p2m. I will
look into finding a better way to do this.

Roger.