All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] x86/pvh: copy data from low 1MB to Dom0 physmap instead of mapping it
@ 2018-09-14 11:16 Roger Pau Monne
  2018-09-17 10:27 ` Wei Liu
                   ` (3 more replies)
  0 siblings, 4 replies; 10+ messages in thread
From: Roger Pau Monne @ 2018-09-14 11:16 UTC (permalink / raw)
  To: xen-devel
  Cc: Roger Pau Monné,
	Wei Liu, Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper,
	Ian Jackson, Tim Deegan, Julien Grall, Stefano Stabellini,
	Jan Beulich, Roger Pau Monne

Identity mapping RAM regions on the low 1MB for Dom0 is not ideal,
since there's data there that could be used by Xen during runtime
(like the AP trampoline), so instead of identity mapping the low 1MB
into the Dom0 physmap populate those RAM regions and copy the data.

Note that this allows to remove unshare_xen_page_with_guest since the
only caller was the PVH Dom0 builder.

Signed-off-by: Roger Pau Monné <rogewr.pau@citrix.com>
---
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Julien Grall <julien.grall@arm.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Tim Deegan <tim@xen.org>
---
 xen/arch/x86/hvm/dom0_build.c | 51 +++++++++++------------------------
 xen/arch/x86/mm.c             | 16 -----------
 xen/include/xen/mm.h          |  1 -
 3 files changed, 16 insertions(+), 52 deletions(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 5724883d8c..ad4a074391 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -278,33 +278,6 @@ static int __init pvh_setup_vmx_realmode_helpers(struct domain *d)
     return 0;
 }
 
-/* Assign the low 1MB to Dom0. */
-static void __init pvh_steal_low_ram(struct domain *d, unsigned long start,
-                                     unsigned long nr_pages)
-{
-    unsigned long mfn;
-
-    ASSERT(start + nr_pages <= PFN_DOWN(MB(1)));
-
-    for ( mfn = start; mfn < start + nr_pages; mfn++ )
-    {
-        struct page_info *pg = mfn_to_page(_mfn(mfn));
-        int rc;
-
-        rc = unshare_xen_page_with_guest(pg, dom_io);
-        if ( rc )
-        {
-            printk("Unable to unshare Xen mfn %#lx: %d\n", mfn, rc);
-            continue;
-        }
-
-        share_xen_page_with_guest(pg, d, SHARE_rw);
-        rc = guest_physmap_add_entry(d, _gfn(mfn), _mfn(mfn), 0, p2m_ram_rw);
-        if ( rc )
-            printk("Unable to add mfn %#lx to p2m: %d\n", mfn, rc);
-    }
-}
-
 static __init void pvh_setup_e820(struct domain *d, unsigned long nr_pages)
 {
     struct e820entry *entry, *entry_guest;
@@ -420,16 +393,24 @@ static int __init pvh_setup_p2m(struct domain *d)
         addr = PFN_DOWN(d->arch.e820[i].addr);
         size = PFN_DOWN(d->arch.e820[i].size);
 
-        if ( addr >= MB1_PAGES )
-            rc = pvh_populate_memory_range(d, addr, size);
-        else
-        {
-            ASSERT(addr + size < MB1_PAGES);
-            pvh_steal_low_ram(d, addr, size);
-        }
-
+        rc = pvh_populate_memory_range(d, addr, size);
         if ( rc )
             return rc;
+
+        if ( addr < MB1_PAGES )
+        {
+             enum hvm_translation_result res =
+                 hvm_copy_to_guest_phys(mfn_to_maddr(_mfn(addr)),
+                                        mfn_to_virt(addr), size << PAGE_SHIFT,
+                                        v);
+
+            if ( res != HVMTRANS_okay )
+            {
+                printk("Failed to copy [%#lx, %#lx): %d\n",
+                       addr, addr + size, res);
+                return -EFAULT;
+            }
+        }
     }
 
     if ( cpu_has_vmx && paging_mode_hap(d) && !vmx_unrestricted_guest(v) )
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index d37eea53d1..955ff0bd78 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -511,22 +511,6 @@ void share_xen_page_with_guest(struct page_info *page, struct domain *d,
     spin_unlock(&d->page_alloc_lock);
 }
 
-int __init unshare_xen_page_with_guest(struct page_info *page,
-                                       struct domain *d)
-{
-    if ( page_get_owner(page) != d || !is_xen_heap_page(page) )
-        return -EINVAL;
-
-    if ( test_and_clear_bit(_PGC_allocated, &page->count_info) )
-        put_page(page);
-
-    /* Remove the owner and clear the flags. */
-    page->u.inuse.type_info = 0;
-    page_set_owner(page, NULL);
-
-    return 0;
-}
-
 void free_shared_domheap_page(struct page_info *page)
 {
     if ( test_and_clear_bit(_PGC_allocated, &page->count_info) )
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index b3d46ab56b..9595539aee 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -645,7 +645,6 @@ enum XENSHARE_flags {
 };
 void share_xen_page_with_guest(struct page_info *page, struct domain *d,
                                enum XENSHARE_flags flags);
-int unshare_xen_page_with_guest(struct page_info *page, struct domain *d);
 
 static inline void share_xen_page_with_privileged_guests(
     struct page_info *page, enum XENSHARE_flags flags)
-- 
2.18.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH] x86/pvh: copy data from low 1MB to Dom0 physmap instead of mapping it
  2018-09-14 11:16 [PATCH] x86/pvh: copy data from low 1MB to Dom0 physmap instead of mapping it Roger Pau Monne
@ 2018-09-17 10:27 ` Wei Liu
  2018-09-17 10:34   ` Roger Pau Monné
  2018-09-17 10:30 ` Wei Liu
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 10+ messages in thread
From: Wei Liu @ 2018-09-17 10:27 UTC (permalink / raw)
  To: Roger Pau Monne
  Cc: Roger Pau Monné,
	Wei Liu, Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper,
	Ian Jackson, Tim Deegan, Julien Grall, Stefano Stabellini,
	Jan Beulich, xen-devel

On Fri, Sep 14, 2018 at 01:16:11PM +0200, Roger Pau Monne wrote:
> Identity mapping RAM regions on the low 1MB for Dom0 is not ideal,
> since there's data there that could be used by Xen during runtime
> (like the AP trampoline), so instead of identity mapping the low 1MB
> into the Dom0 physmap populate those RAM regions and copy the data.

I assume you encountered some real issues or is it just precaution?

> 
> Note that this allows to remove unshare_xen_page_with_guest since the
> only caller was the PVH Dom0 builder.
> 
> Signed-off-by: Roger Pau Monné <rogewr.pau@citrix.com>
> ---
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: George Dunlap <George.Dunlap@eu.citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Julien Grall <julien.grall@arm.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: Tim Deegan <tim@xen.org>
> ---
>  xen/arch/x86/hvm/dom0_build.c | 51 +++++++++++------------------------
>  xen/arch/x86/mm.c             | 16 -----------
>  xen/include/xen/mm.h          |  1 -
>  3 files changed, 16 insertions(+), 52 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
> index 5724883d8c..ad4a074391 100644
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -278,33 +278,6 @@ static int __init pvh_setup_vmx_realmode_helpers(struct domain *d)
>      return 0;
>  }
>  
> -/* Assign the low 1MB to Dom0. */
> -static void __init pvh_steal_low_ram(struct domain *d, unsigned long start,
> -                                     unsigned long nr_pages)
> -{
> -    unsigned long mfn;
> -
> -    ASSERT(start + nr_pages <= PFN_DOWN(MB(1)));
> -
> -    for ( mfn = start; mfn < start + nr_pages; mfn++ )
> -    {
> -        struct page_info *pg = mfn_to_page(_mfn(mfn));
> -        int rc;
> -
> -        rc = unshare_xen_page_with_guest(pg, dom_io);
> -        if ( rc )
> -        {
> -            printk("Unable to unshare Xen mfn %#lx: %d\n", mfn, rc);
> -            continue;
> -        }
> -
> -        share_xen_page_with_guest(pg, d, SHARE_rw);
> -        rc = guest_physmap_add_entry(d, _gfn(mfn), _mfn(mfn), 0, p2m_ram_rw);
> -        if ( rc )
> -            printk("Unable to add mfn %#lx to p2m: %d\n", mfn, rc);
> -    }
> -}
> -
>  static __init void pvh_setup_e820(struct domain *d, unsigned long nr_pages)
>  {
>      struct e820entry *entry, *entry_guest;
> @@ -420,16 +393,24 @@ static int __init pvh_setup_p2m(struct domain *d)


Somewhere above the hunk you modified, there is a comment saying "Memory
below 1MB is identity mapped". Don't you need to change that as well?
Otherwise first 1MB still 1:1 maps to 1MB machine memory in guest p2m.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] x86/pvh: copy data from low 1MB to Dom0 physmap instead of mapping it
  2018-09-14 11:16 [PATCH] x86/pvh: copy data from low 1MB to Dom0 physmap instead of mapping it Roger Pau Monne
  2018-09-17 10:27 ` Wei Liu
@ 2018-09-17 10:30 ` Wei Liu
  2018-09-17 10:41 ` George Dunlap
  2018-09-17 13:03 ` Jan Beulich
  3 siblings, 0 replies; 10+ messages in thread
From: Wei Liu @ 2018-09-17 10:30 UTC (permalink / raw)
  To: Roger Pau Monne
  Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
	George Dunlap, Andrew Cooper, Ian Jackson, Tim Deegan,
	Julien Grall, Jan Beulich, xen-devel

On Fri, Sep 14, 2018 at 01:16:11PM +0200, Roger Pau Monne wrote:
> Identity mapping RAM regions on the low 1MB for Dom0 is not ideal,
> since there's data there that could be used by Xen during runtime
> (like the AP trampoline), so instead of identity mapping the low 1MB
> into the Dom0 physmap populate those RAM regions and copy the data.
> 
> Note that this allows to remove unshare_xen_page_with_guest since the
> only caller was the PVH Dom0 builder.
> 
> Signed-off-by: Roger Pau Monné <rogewr.pau@citrix.com>

And you seemed to have made a typo in your own email address.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] x86/pvh: copy data from low 1MB to Dom0 physmap instead of mapping it
  2018-09-17 10:27 ` Wei Liu
@ 2018-09-17 10:34   ` Roger Pau Monné
  2018-09-17 10:41     ` Wei Liu
  0 siblings, 1 reply; 10+ messages in thread
From: Roger Pau Monné @ 2018-09-17 10:34 UTC (permalink / raw)
  To: Wei Liu
  Cc: Roger Pau Monné,
	Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper, Ian Jackson,
	Tim Deegan, Julien Grall, Stefano Stabellini, Jan Beulich,
	xen-devel

On Mon, Sep 17, 2018 at 11:27:56AM +0100, Wei Liu wrote:
> On Fri, Sep 14, 2018 at 01:16:11PM +0200, Roger Pau Monne wrote:
> > Identity mapping RAM regions on the low 1MB for Dom0 is not ideal,
> > since there's data there that could be used by Xen during runtime
> > (like the AP trampoline), so instead of identity mapping the low 1MB
> > into the Dom0 physmap populate those RAM regions and copy the data.
> 
> I assume you encountered some real issues or is it just precaution?

It's simpler, and allowing Dom0 to modify the Xen AP trampoline code
is not a good idea.

> > 
> > Note that this allows to remove unshare_xen_page_with_guest since the
> > only caller was the PVH Dom0 builder.
> > 
> > Signed-off-by: Roger Pau Monné <rogewr.pau@citrix.com>
> > ---
> > Cc: Jan Beulich <jbeulich@suse.com>
> > Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> > Cc: Wei Liu <wei.liu2@citrix.com>
> > Cc: George Dunlap <George.Dunlap@eu.citrix.com>
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > Cc: Julien Grall <julien.grall@arm.com>
> > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Cc: Stefano Stabellini <sstabellini@kernel.org>
> > Cc: Tim Deegan <tim@xen.org>
> > ---
> >  xen/arch/x86/hvm/dom0_build.c | 51 +++++++++++------------------------
> >  xen/arch/x86/mm.c             | 16 -----------
> >  xen/include/xen/mm.h          |  1 -
> >  3 files changed, 16 insertions(+), 52 deletions(-)
> > 
> > diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
> > index 5724883d8c..ad4a074391 100644
> > --- a/xen/arch/x86/hvm/dom0_build.c
> > +++ b/xen/arch/x86/hvm/dom0_build.c
> > @@ -278,33 +278,6 @@ static int __init pvh_setup_vmx_realmode_helpers(struct domain *d)
> >      return 0;
> >  }
> >  
> > -/* Assign the low 1MB to Dom0. */
> > -static void __init pvh_steal_low_ram(struct domain *d, unsigned long start,
> > -                                     unsigned long nr_pages)
> > -{
> > -    unsigned long mfn;
> > -
> > -    ASSERT(start + nr_pages <= PFN_DOWN(MB(1)));
> > -
> > -    for ( mfn = start; mfn < start + nr_pages; mfn++ )
> > -    {
> > -        struct page_info *pg = mfn_to_page(_mfn(mfn));
> > -        int rc;
> > -
> > -        rc = unshare_xen_page_with_guest(pg, dom_io);
> > -        if ( rc )
> > -        {
> > -            printk("Unable to unshare Xen mfn %#lx: %d\n", mfn, rc);
> > -            continue;
> > -        }
> > -
> > -        share_xen_page_with_guest(pg, d, SHARE_rw);
> > -        rc = guest_physmap_add_entry(d, _gfn(mfn), _mfn(mfn), 0, p2m_ram_rw);
> > -        if ( rc )
> > -            printk("Unable to add mfn %#lx to p2m: %d\n", mfn, rc);
> > -    }
> > -}
> > -
> >  static __init void pvh_setup_e820(struct domain *d, unsigned long nr_pages)
> >  {
> >      struct e820entry *entry, *entry_guest;
> > @@ -420,16 +393,24 @@ static int __init pvh_setup_p2m(struct domain *d)
> 
> 
> Somewhere above the hunk you modified, there is a comment saying "Memory
> below 1MB is identity mapped". Don't you need to change that as well?
> Otherwise first 1MB still 1:1 maps to 1MB machine memory in guest p2m.

Non-RAM regions are still identity mapped.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] x86/pvh: copy data from low 1MB to Dom0 physmap instead of mapping it
  2018-09-14 11:16 [PATCH] x86/pvh: copy data from low 1MB to Dom0 physmap instead of mapping it Roger Pau Monne
  2018-09-17 10:27 ` Wei Liu
  2018-09-17 10:30 ` Wei Liu
@ 2018-09-17 10:41 ` George Dunlap
  2018-09-17 13:03 ` Jan Beulich
  3 siblings, 0 replies; 10+ messages in thread
From: George Dunlap @ 2018-09-17 10:41 UTC (permalink / raw)
  To: Roger Pau Monne, xen-devel
  Cc: Roger Pau Monné,
	Wei Liu, Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper,
	Ian Jackson, Tim Deegan, Julien Grall, Stefano Stabellini,
	Jan Beulich

On 09/14/2018 12:16 PM, Roger Pau Monne wrote:
> Identity mapping RAM regions on the low 1MB for Dom0 is not ideal,
> since there's data there that could be used by Xen during runtime
> (like the AP trampoline), so instead of identity mapping the low 1MB
> into the Dom0 physmap populate those RAM regions and copy the data.
> 
> Note that this allows to remove unshare_xen_page_with_guest since the
> only caller was the PVH Dom0 builder.
> 
> Signed-off-by: Roger Pau Monné <rogewr.pau@citrix.com>

Removing unshare_xen_page_with_guest() once it's not used:

Acked-by: George Dunlap <george.dunlap@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] x86/pvh: copy data from low 1MB to Dom0 physmap instead of mapping it
  2018-09-17 10:34   ` Roger Pau Monné
@ 2018-09-17 10:41     ` Wei Liu
  0 siblings, 0 replies; 10+ messages in thread
From: Wei Liu @ 2018-09-17 10:41 UTC (permalink / raw)
  To: Roger Pau Monné
  Cc: Roger Pau Monné,
	Wei Liu, Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper,
	Ian Jackson, Tim Deegan, Julien Grall, Stefano Stabellini,
	Jan Beulich, xen-devel

On Mon, Sep 17, 2018 at 12:34:19PM +0200, Roger Pau Monné wrote:
[...]
> > >  static __init void pvh_setup_e820(struct domain *d, unsigned long nr_pages)
> > >  {
> > >      struct e820entry *entry, *entry_guest;
> > > @@ -420,16 +393,24 @@ static int __init pvh_setup_p2m(struct domain *d)
> > 
> > 
> > Somewhere above the hunk you modified, there is a comment saying "Memory
> > below 1MB is identity mapped". Don't you need to change that as well?
> > Otherwise first 1MB still 1:1 maps to 1MB machine memory in guest p2m.
> 
> Non-RAM regions are still identity mapped.

I see. Got confused because it said "memory".

May I suggest you update the comment a bit to be more precise, something
like:

/*
 * Region below 1MB is identity mapped here, but RAM below 1MB will be
 * populated later when processing E820 map.
 */

In any case, the code looks fine:

Reviewed-by: Wei Liu <wei.liu2@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] x86/pvh: copy data from low 1MB to Dom0 physmap instead of mapping it
  2018-09-14 11:16 [PATCH] x86/pvh: copy data from low 1MB to Dom0 physmap instead of mapping it Roger Pau Monne
                   ` (2 preceding siblings ...)
  2018-09-17 10:41 ` George Dunlap
@ 2018-09-17 13:03 ` Jan Beulich
  2018-09-17 13:37   ` Roger Pau Monné
  3 siblings, 1 reply; 10+ messages in thread
From: Jan Beulich @ 2018-09-17 13:03 UTC (permalink / raw)
  To: Roger Pau Monne
  Cc: Roger Pau Monné,
	Wei Liu, Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper,
	Ian Jackson, Tim Deegan, Julien Grall, Stefano Stabellini,
	xen-devel

>>> On 14.09.18 at 13:16, <roger.pau@citrix.com> wrote:
> @@ -420,16 +393,24 @@ static int __init pvh_setup_p2m(struct domain *d)
>          addr = PFN_DOWN(d->arch.e820[i].addr);
>          size = PFN_DOWN(d->arch.e820[i].size);
>  
> -        if ( addr >= MB1_PAGES )
> -            rc = pvh_populate_memory_range(d, addr, size);
> -        else
> -        {
> -            ASSERT(addr + size < MB1_PAGES);
> -            pvh_steal_low_ram(d, addr, size);
> -        }
> -
> +        rc = pvh_populate_memory_range(d, addr, size);
>          if ( rc )
>              return rc;
> +
> +        if ( addr < MB1_PAGES )
> +        {
> +             enum hvm_translation_result res =
> +                 hvm_copy_to_guest_phys(mfn_to_maddr(_mfn(addr)),
> +                                        mfn_to_virt(addr), size << PAGE_SHIFT,
> +                                        v);
> +
> +            if ( res != HVMTRANS_okay )
> +            {
> +                printk("Failed to copy [%#lx, %#lx): %d\n",
> +                       addr, addr + size, res);
> +                return -EFAULT;
> +            }
> +        }
>      }

Is there any guarantee (in particular on, but not limited to EFI systems)
for E820_RAM regions to never span the 1Mb boundary? If not, you
may end up copying memory above 1Mb here.

Furthermore, what about RAM / non-RAM boundaries in the middle of
a page (which is quite common a situation for the first Mb)?

I also wonder whether it wouldn't be worthwhile to avoid calling
modify_identity_mmio() for RAM ranges (which are now going to be
re-mapped anyway).

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] x86/pvh: copy data from low 1MB to Dom0 physmap instead of mapping it
  2018-09-17 13:03 ` Jan Beulich
@ 2018-09-17 13:37   ` Roger Pau Monné
  2018-09-17 16:15     ` Jan Beulich
  0 siblings, 1 reply; 10+ messages in thread
From: Roger Pau Monné @ 2018-09-17 13:37 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Roger Pau Monné,
	Wei Liu, Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper,
	Ian Jackson, Tim Deegan, Julien Grall, Stefano Stabellini,
	xen-devel

On Mon, Sep 17, 2018 at 07:03:27AM -0600, Jan Beulich wrote:
> >>> On 14.09.18 at 13:16, <roger.pau@citrix.com> wrote:
> > @@ -420,16 +393,24 @@ static int __init pvh_setup_p2m(struct domain *d)
> >          addr = PFN_DOWN(d->arch.e820[i].addr);
> >          size = PFN_DOWN(d->arch.e820[i].size);
> >  
> > -        if ( addr >= MB1_PAGES )
> > -            rc = pvh_populate_memory_range(d, addr, size);
> > -        else
> > -        {
> > -            ASSERT(addr + size < MB1_PAGES);
> > -            pvh_steal_low_ram(d, addr, size);
> > -        }
> > -
> > +        rc = pvh_populate_memory_range(d, addr, size);
> >          if ( rc )
> >              return rc;
> > +
> > +        if ( addr < MB1_PAGES )
> > +        {
> > +             enum hvm_translation_result res =
> > +                 hvm_copy_to_guest_phys(mfn_to_maddr(_mfn(addr)),
> > +                                        mfn_to_virt(addr), size << PAGE_SHIFT,
> > +                                        v);
> > +
> > +            if ( res != HVMTRANS_okay )
> > +            {
> > +                printk("Failed to copy [%#lx, %#lx): %d\n",
> > +                       addr, addr + size, res);
> > +                return -EFAULT;
> > +            }
> > +        }
> >      }
> 
> Is there any guarantee (in particular on, but not limited to EFI systems)
> for E820_RAM regions to never span the 1Mb boundary? If not, you
> may end up copying memory above 1Mb here.

Right, I guess I could do something like:

end = min(MB(1), d->arch.e820[i].addr + d->arch.e820[i].size);

And calculate the size based on the 'end' value.

> Furthermore, what about RAM / non-RAM boundaries in the middle of
> a page (which is quite common a situation for the first Mb)?

There are no such RAM ranges in the guest memory map because
pvh_setup_e820 aligns the RAM regions start/end to page boundaries.
This is not ideal, so if you want I can do the following:

hvm_copy_to_guest_phys(d->arch.e820[i].addr, d->arch.e820[i].size, v);

And if pvh_setup_e820 is improved so that RAM regions are no longer
aligned to page boundaries the copy will work without issues.

> I also wonder whether it wouldn't be worthwhile to avoid calling
> modify_identity_mmio() for RAM ranges (which are now going to be
> re-mapped anyway).

I think it's easier (code-wise) to identity map the whole area and
then just populate the RAM regions as needed.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] x86/pvh: copy data from low 1MB to Dom0 physmap instead of mapping it
  2018-09-17 13:37   ` Roger Pau Monné
@ 2018-09-17 16:15     ` Jan Beulich
  2018-09-18  8:20       ` Roger Pau Monné
  0 siblings, 1 reply; 10+ messages in thread
From: Jan Beulich @ 2018-09-17 16:15 UTC (permalink / raw)
  To: Roger Pau Monne
  Cc: Roger Pau Monné,
	Wei Liu, Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper,
	Ian Jackson, Tim Deegan, Julien Grall, Stefano Stabellini,
	xen-devel

>>> On 17.09.18 at 15:37, <roger.pau@citrix.com> wrote:
> On Mon, Sep 17, 2018 at 07:03:27AM -0600, Jan Beulich wrote:
>> >>> On 14.09.18 at 13:16, <roger.pau@citrix.com> wrote:
>> > @@ -420,16 +393,24 @@ static int __init pvh_setup_p2m(struct domain *d)
>> >          addr = PFN_DOWN(d->arch.e820[i].addr);
>> >          size = PFN_DOWN(d->arch.e820[i].size);
>> >  
>> > -        if ( addr >= MB1_PAGES )
>> > -            rc = pvh_populate_memory_range(d, addr, size);
>> > -        else
>> > -        {
>> > -            ASSERT(addr + size < MB1_PAGES);
>> > -            pvh_steal_low_ram(d, addr, size);
>> > -        }
>> > -
>> > +        rc = pvh_populate_memory_range(d, addr, size);
>> >          if ( rc )
>> >              return rc;
>> > +
>> > +        if ( addr < MB1_PAGES )
>> > +        {
>> > +             enum hvm_translation_result res =
>> > +                 hvm_copy_to_guest_phys(mfn_to_maddr(_mfn(addr)),
>> > +                                        mfn_to_virt(addr), size << 
> PAGE_SHIFT,
>> > +                                        v);
>> > +
>> > +            if ( res != HVMTRANS_okay )
>> > +            {
>> > +                printk("Failed to copy [%#lx, %#lx): %d\n",
>> > +                       addr, addr + size, res);
>> > +                return -EFAULT;
>> > +            }
>> > +        }
>> >      }
>> 
>> Is there any guarantee (in particular on, but not limited to EFI systems)
>> for E820_RAM regions to never span the 1Mb boundary? If not, you
>> may end up copying memory above 1Mb here.
> 
> Right, I guess I could do something like:
> 
> end = min(MB(1), d->arch.e820[i].addr + d->arch.e820[i].size);
> 
> And calculate the size based on the 'end' value.

Right.

>> Furthermore, what about RAM / non-RAM boundaries in the middle of
>> a page (which is quite common a situation for the first Mb)?
> 
> There are no such RAM ranges in the guest memory map because
> pvh_setup_e820 aligns the RAM regions start/end to page boundaries.

Oh, right.

> This is not ideal, so if you want I can do the following:
> 
> hvm_copy_to_guest_phys(d->arch.e820[i].addr, d->arch.e820[i].size, v);
> 
> And if pvh_setup_e820 is improved so that RAM regions are no longer
> aligned to page boundaries the copy will work without issues.

Hmm, I guess I'm having difficulty understanding what you think the
goal ought to be: Would a page part of which is RAM be copied or
mapped in your opinion? I think only mapping can possibly work
reliably, and with your remark about pvh_setup_e820() I then think
no change would be needed.

>> I also wonder whether it wouldn't be worthwhile to avoid calling
>> modify_identity_mmio() for RAM ranges (which are now going to be
>> re-mapped anyway).
> 
> I think it's easier (code-wise) to identity map the whole area and
> then just populate the RAM regions as needed.

Well, okay then.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] x86/pvh: copy data from low 1MB to Dom0 physmap instead of mapping it
  2018-09-17 16:15     ` Jan Beulich
@ 2018-09-18  8:20       ` Roger Pau Monné
  0 siblings, 0 replies; 10+ messages in thread
From: Roger Pau Monné @ 2018-09-18  8:20 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Roger Pau Monné,
	Wei Liu, Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper,
	Ian Jackson, Tim Deegan, Julien Grall, Stefano Stabellini,
	xen-devel

On Mon, Sep 17, 2018 at 10:15:11AM -0600, Jan Beulich wrote:
> >>> On 17.09.18 at 15:37, <roger.pau@citrix.com> wrote:
> > On Mon, Sep 17, 2018 at 07:03:27AM -0600, Jan Beulich wrote:
> >> >>> On 14.09.18 at 13:16, <roger.pau@citrix.com> wrote:
> >> > @@ -420,16 +393,24 @@ static int __init pvh_setup_p2m(struct domain *d)
> >> >          addr = PFN_DOWN(d->arch.e820[i].addr);
> >> >          size = PFN_DOWN(d->arch.e820[i].size);
> >> >  
> >> > -        if ( addr >= MB1_PAGES )
> >> > -            rc = pvh_populate_memory_range(d, addr, size);
> >> > -        else
> >> > -        {
> >> > -            ASSERT(addr + size < MB1_PAGES);
> >> > -            pvh_steal_low_ram(d, addr, size);
> >> > -        }
> >> > -
> >> > +        rc = pvh_populate_memory_range(d, addr, size);
> >> >          if ( rc )
> >> >              return rc;
> >> > +
> >> > +        if ( addr < MB1_PAGES )
> >> > +        {
> >> > +             enum hvm_translation_result res =
> >> > +                 hvm_copy_to_guest_phys(mfn_to_maddr(_mfn(addr)),
> >> > +                                        mfn_to_virt(addr), size << 
> > PAGE_SHIFT,
> >> > +                                        v);
> >> > +
> >> > +            if ( res != HVMTRANS_okay )
> >> > +            {
> >> > +                printk("Failed to copy [%#lx, %#lx): %d\n",
> >> > +                       addr, addr + size, res);
> >> > +                return -EFAULT;
> >> > +            }
> >> > +        }
> >> >      }
> >> 
> >> Is there any guarantee (in particular on, but not limited to EFI systems)
> >> for E820_RAM regions to never span the 1Mb boundary? If not, you
> >> may end up copying memory above 1Mb here.
> > 
> > Right, I guess I could do something like:
> > 
> > end = min(MB(1), d->arch.e820[i].addr + d->arch.e820[i].size);
> > 
> > And calculate the size based on the 'end' value.
> 
> Right.

Let me fix this and resend.

> 
> >> Furthermore, what about RAM / non-RAM boundaries in the middle of
> >> a page (which is quite common a situation for the first Mb)?
> > 
> > There are no such RAM ranges in the guest memory map because
> > pvh_setup_e820 aligns the RAM regions start/end to page boundaries.
> 
> Oh, right.
> 
> > This is not ideal, so if you want I can do the following:
> > 
> > hvm_copy_to_guest_phys(d->arch.e820[i].addr, d->arch.e820[i].size, v);
> > 
> > And if pvh_setup_e820 is improved so that RAM regions are no longer
> > aligned to page boundaries the copy will work without issues.
> 
> Hmm, I guess I'm having difficulty understanding what you think the
> goal ought to be: Would a page part of which is RAM be copied or
> mapped in your opinion?

IMO start of RAM ranges should be ceiled, and the end should be
floored so that the resulting range is the same size or smaller, but
never greater than the original RAM range.

For example a RAM range like [0x10, 0x2001) will end up as [0x1000,
0x2000), so a page that's only partially RAM loses the RAM part in
pvh_setup_e820.

> I think only mapping can possibly work
> reliably, and with your remark about pvh_setup_e820() I then think
> no change would be needed.

I agree, only identity mapping can work with such pages.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2018-09-18  8:20 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-14 11:16 [PATCH] x86/pvh: copy data from low 1MB to Dom0 physmap instead of mapping it Roger Pau Monne
2018-09-17 10:27 ` Wei Liu
2018-09-17 10:34   ` Roger Pau Monné
2018-09-17 10:41     ` Wei Liu
2018-09-17 10:30 ` Wei Liu
2018-09-17 10:41 ` George Dunlap
2018-09-17 13:03 ` Jan Beulich
2018-09-17 13:37   ` Roger Pau Monné
2018-09-17 16:15     ` Jan Beulich
2018-09-18  8:20       ` Roger Pau Monné

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.