Re: [PATCH 6/6] xen: x86 pvh: use XENMEM_add_to_physmap_range for foreign gmfn mappings
On Wed, 17 Oct 2012, Ian Campbell wrote: > Squeezing the necessary fields into the existing XENMEM_add_to_physmap > interface was proving to be a bit tricky so we have decided to go with > a new interface upstream (the XENMAPSPACE_gmfn_foreign interface using > XENMEM_add_to_physmap was never committed anywhere). This interface > also allows for batching which was impossible to support at the same > time as foreign mfns in the old interface. > > This reverts the relevant parts of "PVH: basic and header changes, > elfnote changes, ..." and followups and trivially converts > pvh_add_to_xen_p2m over. > > Signed-off-by: Ian Campbell Acked-by: Stefano Stabellini -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] xen: x86 pvh: use XENMEM_add_to_physmap_range for foreign gmfn mappings
On Thu, 2012-10-18 at 00:57 +0100, Mukesh Rathor wrote: > On Wed, 17 Oct 2012 12:32:12 +0100 > Ian Campbell wrote: > > > Squeezing the necessary fields into the existing XENMEM_add_to_physmap > > interface was proving to be a bit tricky so we have decided to go with > > a new interface upstream (the XENMAPSPACE_gmfn_foreign interface using > > XENMEM_add_to_physmap was never committed anywhere). This interface > > also allows for batching which was impossible to support at the same > > time as foreign mfns in the old interface. > > > > This reverts the relevant parts of "PVH: basic and header changes, > > elfnote changes, ..." and followups and trivially converts > > pvh_add_to_xen_p2m over. > > > Hmm... I don't see xen side implementation of XENMEM_add_to_physmap_range, I said in the 0/6 patch, but should have repeated here: The final patch requires that XENMEM_add_to_physmap_range be implemented for x86 on the hypervisor side. For inspiration the ARM version can be found at <135031-17148-1-git-send-email-ian.campb...@citrix.com> (and will likely be in xen-unstable soon). In the end I checked it in yesterday. > and since I've already got my patches tested and cut, I'm going to send > them now. We can apply this change easily in konrad's tree. Sure, no problem. Ian. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] xen: x86 pvh: use XENMEM_add_to_physmap_range for foreign gmfn mappings
On Thu, 2012-10-18 at 00:57 +0100, Mukesh Rathor wrote: On Wed, 17 Oct 2012 12:32:12 +0100 Ian Campbell ian.campb...@citrix.com wrote: Squeezing the necessary fields into the existing XENMEM_add_to_physmap interface was proving to be a bit tricky so we have decided to go with a new interface upstream (the XENMAPSPACE_gmfn_foreign interface using XENMEM_add_to_physmap was never committed anywhere). This interface also allows for batching which was impossible to support at the same time as foreign mfns in the old interface. This reverts the relevant parts of PVH: basic and header changes, elfnote changes, ... and followups and trivially converts pvh_add_to_xen_p2m over. Hmm... I don't see xen side implementation of XENMEM_add_to_physmap_range, I said in the 0/6 patch, but should have repeated here: The final patch requires that XENMEM_add_to_physmap_range be implemented for x86 on the hypervisor side. For inspiration the ARM version can be found at 135031-17148-1-git-send-email-ian.campb...@citrix.com (and will likely be in xen-unstable soon). In the end I checked it in yesterday. and since I've already got my patches tested and cut, I'm going to send them now. We can apply this change easily in konrad's tree. Sure, no problem. Ian. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] xen: x86 pvh: use XENMEM_add_to_physmap_range for foreign gmfn mappings
On Wed, 17 Oct 2012, Ian Campbell wrote: Squeezing the necessary fields into the existing XENMEM_add_to_physmap interface was proving to be a bit tricky so we have decided to go with a new interface upstream (the XENMAPSPACE_gmfn_foreign interface using XENMEM_add_to_physmap was never committed anywhere). This interface also allows for batching which was impossible to support at the same time as foreign mfns in the old interface. This reverts the relevant parts of PVH: basic and header changes, elfnote changes, ... and followups and trivially converts pvh_add_to_xen_p2m over. Signed-off-by: Ian Campbell ian.campb...@citrix.com Acked-by: Stefano Stabellini stefano.stabell...@eu.citrix.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] xen: x86 pvh: use XENMEM_add_to_physmap_range for foreign gmfn mappings
On Wed, 17 Oct 2012 12:32:12 +0100 Ian Campbell wrote: > Squeezing the necessary fields into the existing XENMEM_add_to_physmap > interface was proving to be a bit tricky so we have decided to go with > a new interface upstream (the XENMAPSPACE_gmfn_foreign interface using > XENMEM_add_to_physmap was never committed anywhere). This interface > also allows for batching which was impossible to support at the same > time as foreign mfns in the old interface. > > This reverts the relevant parts of "PVH: basic and header changes, > elfnote changes, ..." and followups and trivially converts > pvh_add_to_xen_p2m over. Hmm... I don't see xen side implementation of XENMEM_add_to_physmap_range, and since I've already got my patches tested and cut, I'm going to send them now. We can apply this change easily in konrad's tree. thanks, mukesh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] xen: x86 pvh: use XENMEM_add_to_physmap_range for foreign gmfn mappings
Squeezing the necessary fields into the existing XENMEM_add_to_physmap
interface was proving to be a bit tricky so we have decided to go with
a new interface upstream (the XENMAPSPACE_gmfn_foreign interface using
XENMEM_add_to_physmap was never committed anywhere). This interface
also allows for batching which was impossible to support at the same
time as foreign mfns in the old interface.
This reverts the relevant parts of "PVH: basic and header changes,
elfnote changes, ..." and followups and trivially converts
pvh_add_to_xen_p2m over.
Signed-off-by: Ian Campbell
---
arch/x86/xen/mmu.c | 18 --
include/xen/interface/memory.h | 24 +++-
2 files changed, 23 insertions(+), 19 deletions(-)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index d779e96..e7edcdd 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2506,13 +2506,19 @@ static int pvh_add_to_xen_p2m(unsigned long lpfn,
unsigned long fgmfn,
unsigned int domid)
{
int rc;
- struct xen_add_to_physmap xatp = { .u.foreign_domid = domid };
+ struct xen_add_to_physmap_range xatp = {
+ .domid = DOMID_SELF,
+ .foreign_domid = domid,
+ .size = 1,
+ .space = XENMAPSPACE_gmfn_foreign,
+ };
+ xen_ulong_t idx = fgmfn;
+ xen_pfn_t gpfn = lpfn;
+
+ set_xen_guest_handle(xatp.idxs, );
+ set_xen_guest_handle(xatp.gpfns, );
- xatp.gpfn = lpfn;
- xatp.idx = fgmfn;
- xatp.domid = DOMID_SELF;
- xatp.space = XENMAPSPACE_gmfn_foreign;
- rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, );
+ rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, );
if (rc)
pr_warn("d0: Failed to map pfn (0x%lx) to mfn (0x%lx) rc:%d\n",
lpfn, fgmfn, rc);
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index eb2d3e5..b40a431 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -153,6 +153,14 @@ struct xen_machphys_mapping {
};
DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
+#define XENMAPSPACE_shared_info 0 /* shared info page */
+#define XENMAPSPACE_grant_table 1 /* grant table page */
+#define XENMAPSPACE_gmfn 2 /* GMFN */
+#define XENMAPSPACE_gmfn_range 3 /* GMFN range, XENMEM_add_to_physmap only.
*/
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
+ * XENMEM_add_to_physmap_range only.
+ */
+
/*
* Sets the GPFN at which a particular page appears in the specified guest's
* pseudophysical address space.
@@ -163,22 +171,12 @@ struct xen_add_to_physmap {
/* Which domain to change the mapping for. */
domid_t domid;
-union {
- /* Number of pages to go through for gmfn_range */
- uint16_tsize;
- /* IFF XENMAPSPACE_gmfn_foreign */
- domid_t foreign_domid;
-} u;
+/* Number of pages to go through for gmfn_range */
+uint16_tsize;
+
/* Source mapping space. */
-#define XENMAPSPACE_shared_info 0 /* shared info page */
-#define XENMAPSPACE_grant_table 1 /* grant table page */
-#define XENMAPSPACE_gmfn2 /* GMFN */
-#define XENMAPSPACE_gmfn_range 3 /* GMFN range */
-#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
unsigned int space;
-#define XENMAPIDX_grant_table_status 0x8000
-
/* Index into source mapping space. */
xen_ulong_t idx;
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] xen: x86 pvh: use XENMEM_add_to_physmap_range for foreign gmfn mappings
Squeezing the necessary fields into the existing XENMEM_add_to_physmap
interface was proving to be a bit tricky so we have decided to go with
a new interface upstream (the XENMAPSPACE_gmfn_foreign interface using
XENMEM_add_to_physmap was never committed anywhere). This interface
also allows for batching which was impossible to support at the same
time as foreign mfns in the old interface.
This reverts the relevant parts of PVH: basic and header changes,
elfnote changes, ... and followups and trivially converts
pvh_add_to_xen_p2m over.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
arch/x86/xen/mmu.c | 18 --
include/xen/interface/memory.h | 24 +++-
2 files changed, 23 insertions(+), 19 deletions(-)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index d779e96..e7edcdd 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2506,13 +2506,19 @@ static int pvh_add_to_xen_p2m(unsigned long lpfn,
unsigned long fgmfn,
unsigned int domid)
{
int rc;
- struct xen_add_to_physmap xatp = { .u.foreign_domid = domid };
+ struct xen_add_to_physmap_range xatp = {
+ .domid = DOMID_SELF,
+ .foreign_domid = domid,
+ .size = 1,
+ .space = XENMAPSPACE_gmfn_foreign,
+ };
+ xen_ulong_t idx = fgmfn;
+ xen_pfn_t gpfn = lpfn;
+
+ set_xen_guest_handle(xatp.idxs, idx);
+ set_xen_guest_handle(xatp.gpfns, gpfn);
- xatp.gpfn = lpfn;
- xatp.idx = fgmfn;
- xatp.domid = DOMID_SELF;
- xatp.space = XENMAPSPACE_gmfn_foreign;
- rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, xatp);
+ rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, xatp);
if (rc)
pr_warn(d0: Failed to map pfn (0x%lx) to mfn (0x%lx) rc:%d\n,
lpfn, fgmfn, rc);
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index eb2d3e5..b40a431 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -153,6 +153,14 @@ struct xen_machphys_mapping {
};
DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
+#define XENMAPSPACE_shared_info 0 /* shared info page */
+#define XENMAPSPACE_grant_table 1 /* grant table page */
+#define XENMAPSPACE_gmfn 2 /* GMFN */
+#define XENMAPSPACE_gmfn_range 3 /* GMFN range, XENMEM_add_to_physmap only.
*/
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
+ * XENMEM_add_to_physmap_range only.
+ */
+
/*
* Sets the GPFN at which a particular page appears in the specified guest's
* pseudophysical address space.
@@ -163,22 +171,12 @@ struct xen_add_to_physmap {
/* Which domain to change the mapping for. */
domid_t domid;
-union {
- /* Number of pages to go through for gmfn_range */
- uint16_tsize;
- /* IFF XENMAPSPACE_gmfn_foreign */
- domid_t foreign_domid;
-} u;
+/* Number of pages to go through for gmfn_range */
+uint16_tsize;
+
/* Source mapping space. */
-#define XENMAPSPACE_shared_info 0 /* shared info page */
-#define XENMAPSPACE_grant_table 1 /* grant table page */
-#define XENMAPSPACE_gmfn2 /* GMFN */
-#define XENMAPSPACE_gmfn_range 3 /* GMFN range */
-#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
unsigned int space;
-#define XENMAPIDX_grant_table_status 0x8000
-
/* Index into source mapping space. */
xen_ulong_t idx;
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] xen: x86 pvh: use XENMEM_add_to_physmap_range for foreign gmfn mappings
On Wed, 17 Oct 2012 12:32:12 +0100 Ian Campbell ian.campb...@citrix.com wrote: Squeezing the necessary fields into the existing XENMEM_add_to_physmap interface was proving to be a bit tricky so we have decided to go with a new interface upstream (the XENMAPSPACE_gmfn_foreign interface using XENMEM_add_to_physmap was never committed anywhere). This interface also allows for batching which was impossible to support at the same time as foreign mfns in the old interface. This reverts the relevant parts of PVH: basic and header changes, elfnote changes, ... and followups and trivially converts pvh_add_to_xen_p2m over. Hmm... I don't see xen side implementation of XENMEM_add_to_physmap_range, and since I've already got my patches tested and cut, I'm going to send them now. We can apply this change easily in konrad's tree. thanks, mukesh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
