Hi Roger,
On 06/10/17 11:36, Roger Pau Monné wrote:
On Fri, Oct 06, 2017 at 10:03:39AM +0000, Andrew Cooper wrote:
On 06/10/17 10:57, Roger Pau Monné wrote:
On Thu, Oct 05, 2017 at 06:23:41PM +0000, Andrew Cooper wrote:
@@ -612,14 +614,19 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
X86_HVM_NR_SPECIAL_PAGES) )
goto error_out;
- xc_hvm_param_set(xch, domid, HVM_PARAM_STORE_PFN,
- special_pfn(SPECIALPAGE_XENSTORE));
+ dom->xenstore_gfn = special_pfn(SPECIALPAGE_XENSTORE);
A pre-patch to s/special_pfn/special_gfn/ would be nice :) for
coherency.
Sorting out all terminology is a far larger problem than I have time for
atm. For HVM guests, pfn == gfn, so I chose not to dive down that
rabbit hole right now.
Heh, right.
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index ef834e6..0389a06 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -851,14 +851,9 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
if (ret != 0)
goto out;
- if (xc_dom_translated(dom)) {
- state->console_mfn = dom->console_pfn;
- state->store_mfn = dom->xenstore_pfn;
- state->vuart_gfn = dom->vuart_gfn;
This chunk should go with patch 1, it's a PVHv1 leftover also.
Sadly, no its not :(
ARM uses libxl__build_pv(), not libxl__build_hvm()
Really? That's seems very wrong^W confusing IMHO. I'm quite sure that
with the changes I've made to libxl in PVHv2 ARM could use the HVM
guest type.
Yes we use PV type for ARM. I think the reason was because HVM would
create QEMU by default. So PV was more closer here. It might be worth
having a look how we can re-use the PVH path if it helps maintaining libxl.
Although, this may imply some changes to the user? (I am thinking of
selecting pvh).
I have created a task on Jira (XEN-102) to keep track of this idea.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
