Re: [Xen-ia64-devel] Re: [PATCH] fix the ia64 p2m semantic
You (yamahata) said: Thanks. Attached updated one. I've tested this patch. PV-on-HVM driver worked correctly. Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH] fix the ia64 p2m semantic
Hi Isaku,
Sorry for late response.
You (yamahata) said:
Tsunehisa.
I haven't tested arch_memory_op(). Could you verify it?
I've checked this patch on the latest change set(cs:14513).
It occured hypervisor crash at that xen-platform.ko was inserted.
And, hypervisor said as follow:
(XEN) BUG at mm.c:1050
(XEN) FIXME: implement ia64 dump_execution_state()
(XEN)
(XEN)
(XEN) Panic on CPU 1:
(XEN) BUG at mm.c:1050
(XEN)
(XEN)
(XEN) Reboot in five seconds...
The code shown by it is...
1045
1046 static void
1047 adjust_page_count_info(struct page_info* page)
1048 {
1049 struct domain* d = page_get_owner(page);
1050 BUG_ON(page-count_info != 1); this point.
1051 if (d != NULL) {
1052 int ret = get_page(page, d);
1053 BUG_ON(ret == 0);
1054 } else {
1055 u64 x, nx, y;
1056
1057 y = *((u64*)page-count_info);
1058 do {
1059 x = y;
1060 nx = x + 1;
1061
1062 BUG_ON((x 32) != 0);
1063 BUG_ON((nx PGC_count_mask) != 2);
1064 y = cmpxchg((u64*)page-count_info, x, nx);
1065 } while (unlikely(y != x));
1066 }
1067 }
I'll check, which hypercall occures hyper crash.
Thanks,
- Tsunehisa Doi
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH] fix the ia64 p2m semantic
FYI.
Original change set is not crashed.
I (Doi.Tsunehisa) said:
Hi Isaku,
Sorry for late response.
You (yamahata) said:
Tsunehisa.
I haven't tested arch_memory_op(). Could you verify it?
I've checked this patch on the latest change set(cs:14513).
It occured hypervisor crash at that xen-platform.ko was inserted.
And, hypervisor said as follow:
(XEN) BUG at mm.c:1050
(XEN) FIXME: implement ia64 dump_execution_state()
(XEN)
(XEN)
(XEN) Panic on CPU 1:
(XEN) BUG at mm.c:1050
(XEN)
(XEN)
(XEN) Reboot in five seconds...
The code shown by it is...
1045
1046 static void
1047 adjust_page_count_info(struct page_info* page)
1048 {
1049 struct domain* d = page_get_owner(page);
1050 BUG_ON(page-count_info != 1); this point.
1051 if (d != NULL) {
1052 int ret = get_page(page, d);
1053 BUG_ON(ret == 0);
1054 } else {
1055 u64 x, nx, y;
1056
1057 y = *((u64*)page-count_info);
1058 do {
1059 x = y;
1060 nx = x + 1;
1061
1062 BUG_ON((x 32) != 0);
1063 BUG_ON((nx PGC_count_mask) != 2);
1064 y = cmpxchg((u64*)page-count_info, x, nx);
1065 } while (unlikely(y != x));
1066 }
1067 }
I'll check, which hypercall occures hyper crash.
Thanks,
- Tsunehisa Doi
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Re: [PATCH] fix the ia64 p2m semantic
Hi Isaku, I (Doi.Tsunehisa) said: If so, the BUG_ON() is bogus. Probably it should be something like BUG_ON(page-count_info != 1 page-count_info != (PGC_allocated | 1)). BUG_ON((page-count_info PGC_count_mask) != 1) is better, I think. I've checked this modification. PV-on-HVM driver worked correctly. Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] Fix for re-enabling PV-on-HVM on IPF
You (yamahata) said:
+
guest_physmap_remove_page(d, gpfn, mfn);
+
+/* post-set PGC_allocated flag */
+do {
+x = mfn_to_page(mfn)-count_info;
+if ((x PGC_count_mask) == 0)
+goto out;
+nx = x | PGC_allocated;
+} while (cmpxchg_acq(mfn_to_page(mfn)-count_info, x, nx)
!= x);
+}
checking == 0 is non-sense because we incremented it.
Probably you want to
if (!test_and_set_bit(page-count_info, _PGC_allocated)) {
put_page(page);
goto out;
}
guest_physmap_remove_page() unsets PGC_allocated flag, thus
this test_and_set_bit() returns zero allways, I think.
Sorry, I was somewhat confused.
Probably it should looks like the following.
if (page-count_info != 1) { /* no one but us is using this page */
put_page(page);
goto out;
}
__set_bit(page-count_info, _PGC_allocated);
Does `page-count_info' have to be operated with atomic ?
In this code, I assumed that hypervisor might be destructing the
domain. In this case, the page counter might be zero.
Such case doesn't occur because we called get_page().
It is the reason that the page reference counter exists for, isn't it?
I understand it.
Thanks,
- Tsunehisa Doi
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] Fix for re-enabling PV-on-HVM on IPF
You (yamahata) said:
Probably it should looks like the following.
if (page-count_info != 1) { /* no one but us is using this page */
put_page(page);
goto out;
}
__set_bit(page-count_info, _PGC_allocated);
Does `page-count_info' have to be operated with atomic ?
Atomic operation is safe bet.
XENMAPSPACE hypercall isn't performance critical.
If you want to be paranoia, use if (test_and_set_bit()) to check whether
some else set the bit.
I'll modify it with this policy.
Thanks,
- Tsunehisa Doi
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] Fix for re-enabling PV-on-HVM on IPF
Hi all,
I've modified it, so submit the patch.
[EMAIL PROTECTED] wrote:
You (yamahata) said:
Probably it should looks like the following.
if (page-count_info != 1) { /* no one but us is using this page */
put_page(page);
goto out;
}
__set_bit(page-count_info, _PGC_allocated);
Does `page-count_info' have to be operated with atomic ?
Atomic operation is safe bet.
XENMAPSPACE hypercall isn't performance critical.
If you want to be paranoia, use if (test_and_set_bit()) to check whether
some else set the bit.
I'll modify it with this policy.
Thanks,
- Tsunehisa Doi
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r 61eb6589e720 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.cTue Mar 06 21:11:37 2007 +0900
+++ b/xen/arch/ia64/xen/mm.cThu Mar 08 20:42:26 2007 +0900
@@ -2087,18 +2087,33 @@ arch_memory_op(int op, XEN_GUEST_HANDLE(
break;
case XENMAPSPACE_grant_table:
spin_lock(d-grant_table-lock);
+
+if ((xatp.idx = nr_grant_frames(d-grant_table))
+(xatp.idx max_nr_grant_frames))
+gnttab_grow_table(d, xatp.idx + 1);
+
if (xatp.idx nr_grant_frames(d-grant_table))
-mfn = virt_to_mfn(d-grant_table-shared) + xatp.idx;
+mfn = virt_to_mfn(d-grant_table-shared[xatp.idx]);
+
spin_unlock(d-grant_table-lock);
break;
default:
break;
}
+if (mfn == 0) {
+put_domain(d);
+return -EINVAL;
+}
+
LOCK_BIGLOCK(d);
+/* Check remapping necessity */
+prev_mfn = gmfn_to_mfn(d, xatp.gpfn);
+if (mfn == prev_mfn)
+goto out;
+
/* Remove previously mapped page if it was present. */
-prev_mfn = gmfn_to_mfn(d, xatp.gpfn);
if (prev_mfn mfn_valid(prev_mfn)) {
if (IS_XEN_HEAP_FRAME(mfn_to_page(prev_mfn)))
/* Xen heap frames are simply unhooked from this phys slot. */
@@ -2110,12 +2125,31 @@ arch_memory_op(int op, XEN_GUEST_HANDLE(
/* Unmap from old location, if any. */
gpfn = get_gpfn_from_mfn(mfn);
-if (gpfn != INVALID_M2P_ENTRY)
+if (gpfn != INVALID_M2P_ENTRY) {
+/*
+ * guest_physmap_remove_page() (for IPF) descrements page
+ * counter and unset PGC_allocated flag,
+ * so pre-increment page counter and post-set flag inserted
+ */
+/* pre-increment page counter */
+if (!get_page(mfn_to_page(mfn), d))
+goto out;
+
guest_physmap_remove_page(d, gpfn, mfn);
+
+/* post-set PGC_allocated flag */
+if ((mfn_to_page(mfn)-count_info PGC_count_mask) != 1) {
+/* no one but us is using this page */
+put_page(mfn_to_page(mfn));
+goto out;
+}
+set_bit(_PGC_allocated, mfn_to_page(mfn)-count_info);
+}
/* Map at new location. */
guest_physmap_add_page(d, xatp.gpfn, mfn);
+out:
UNLOCK_BIGLOCK(d);
put_domain(d);
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] Fix for re-enabling PV-on-HVM on IPF
Subject: Re: [Patch] Fix for re-enabling PV-on-HVM on IPF
Hi all,
I've modified the paches according to Yamahata-san's suggestion.
* pvfix.patch
- fix for compling PV-on-HVM driver on IPF.
- this is same as that I send in last week.
* hcall-rval.patch
- fix about a return value of hypercall from VT-i domain.
These patches are the same.
* dynmic-gnttab.patch
- follow dynamic grant_table for PV-on-HVM on IPF
This patch is modified to avoid hypervisor crash.
* avoid-crash.patch
- modify guest_physmap_add_page()
This patch is obsolated.
Therefore, I'll re-submit paches as follow:
* pvfix.patch
- fix for compling PV-on-HVM driver on IPF.
* hcall-rval.patch
- fix about a return value of hypercall from VT-i domain.
* dynmic-gnttab.patch2
- follow dynamic grant_table for PV-on-HVM on IPF
- It has be introduced pre-increment page counter and
post-set PGC_allocated flag.
And, it requires the patch of xen-unstable.hg(cs:14089) for
PV-on-HVM enabling.
In out simple test, PV-on-HVM on IPF works.
Thanks,
- Tsunehisa Doi
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1173182115 -32400
# Node ID 59655cf89ac90a1f566bf8a59dbb65cf76d980e5
# Parent 8a58ea36e4207e6d47f8870632ab8fe14e3622cb
Fix for compiling PV-on-HVM driver on IPF
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r 8a58ea36e420 -r 59655cf89ac9
unmodified_drivers/linux-2.6/platform-pci/xen_support.c
--- a/unmodified_drivers/linux-2.6/platform-pci/xen_support.c Thu Mar 01
15:02:09 2007 -0700
+++ b/unmodified_drivers/linux-2.6/platform-pci/xen_support.c Tue Mar 06
20:55:15 2007 +0900
@@ -45,7 +45,13 @@ unsigned long __hypercall(unsigned long
return __res;
}
EXPORT_SYMBOL(__hypercall);
-#endif
+
+int HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count)
+{
+ return xencomm_mini_hypercall_grant_table_op(cmd, uop, count);
+}
+EXPORT_SYMBOL(HYPERVISOR_grant_table_op);
+#endif /* __ia64__ */
void xen_machphys_update(unsigned long mfn, unsigned long pfn)
{
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1173183097 -32400
# Node ID c3fdaff60c05896fbbf13fa096eb1e4803c6ae8a
# Parent 4a02f5baf293c5f0dcfe425a42957b61aef619df
Fix about a return value of hypercall from VT-i domain
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r 4a02f5baf293 -r c3fdaff60c05 xen/arch/ia64/vmx/vmx_entry.S
--- a/xen/arch/ia64/vmx/vmx_entry.S Tue Mar 06 21:08:31 2007 +0900
+++ b/xen/arch/ia64/vmx/vmx_entry.S Tue Mar 06 21:11:37 2007 +0900
@@ -477,6 +477,11 @@ GLOBAL_ENTRY(ia64_leave_hypercall)
* resumes at .work_processed_syscall with p6 set to 1 if the
extra-work-check
* needs to be redone.
*/
+;;
+adds r16=PT(R8)+16,r12
+;;
+st8 [r16]=r8
+;;
(pUStk) rsm psr.i
cmp.eq pLvSys,p0=r0,r0 // pLvSys=1: leave from syscall
(pUStk) cmp.eq.unc p6,p0=r0,r0 // p6 - pUStk
@@ -484,6 +489,11 @@ GLOBAL_ENTRY(ia64_leave_hypercall)
br.call.sptk.many b0=leave_hypervisor_tail
.work_processed_syscall:
//clean up bank 1 registers
+;;
+adds r16=PT(R8)+16,r12
+;;
+ld8 r8=[r16]
+;;
mov r16=r0
mov r17=r0
mov r18=r0
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1173322666 -32400
# Node ID b602dd142385577c143b99e47c56b2a4f9dca90a
# Parent 61eb6589e720d95f0b26e435e9d3cd2b12718700
Follow dynamic grant_table for PV-on-HVM on IPF
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r 61eb6589e720 -r b602dd142385 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.cTue Mar 06 21:11:37 2007 +0900
+++ b/xen/arch/ia64/xen/mm.cThu Mar 08 11:57:46 2007 +0900
@@ -2087,18 +2087,33 @@ arch_memory_op(int op, XEN_GUEST_HANDLE(
break;
case XENMAPSPACE_grant_table:
spin_lock(d-grant_table-lock);
+
+if ((xatp.idx = nr_grant_frames(d-grant_table))
+(xatp.idx max_nr_grant_frames))
+gnttab_grow_table(d, xatp.idx + 1);
+
if (xatp.idx nr_grant_frames(d-grant_table))
-mfn = virt_to_mfn(d-grant_table-shared) + xatp.idx;
+mfn = virt_to_mfn(d-grant_table-shared[xatp.idx]);
+
spin_unlock(d-grant_table-lock);
break;
default:
break;
}
+if (mfn == 0) {
+put_domain(d);
+return -EINVAL;
+}
+
LOCK_BIGLOCK(d);
+/* Check remapping necessity */
+prev_mfn = gmfn_to_mfn(d, xatp.gpfn);
+if (mfn == prev_mfn)
+goto out;
+
/* Remove previously mapped page if it was present. */
-prev_mfn = gmfn_to_mfn(d, xatp.gpfn);
if (prev_mfn mfn_valid(prev_mfn)) {
if (IS_XEN_HEAP_FRAME(mfn_to_page(prev_mfn)))
/* Xen heap frames are simply unhooked from this phys slot. */
@@ -2110,12 +2125,31 @@ arch_memory_op(int op, XEN_GUEST_HANDLE(
/* Unmap
Re: [Xen-ia64-devel] [Patch] Fix for re-enabling PV-on-HVM on IPF
Hi Yamahata-san,
Thank you for your comment.
You (yamahata) said:
On Thu, Mar 08, 2007 at 01:06:04PM +0900, DOI Tsunehisa wrote:
diff -r 61eb6589e720 -r b602dd142385 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.cTue Mar 06 21:11:37 2007 +0900
+++ b/xen/arch/ia64/xen/mm.cThu Mar 08 11:57:46 2007 +0900
@@ -2110,12 +2125,31 @@ arch_memory_op(int op, XEN_GUEST_HANDLE(
/* Unmap from old location, if any. */
gpfn = get_gpfn_from_mfn(mfn);
-if (gpfn != INVALID_M2P_ENTRY)
+if (gpfn != INVALID_M2P_ENTRY) {
+unsigned long x, nx;
+/*
+ * guest_physmap_remove_page() (for IPF) descrements page
+ * counter and unset PGC_allocated flag,
+ * so pre-increment page counter and post-set flag inserte
d
+ */
+/* pre-increment page counter */
+get_page(mfn_to_page(mfn), d);
Please check the return value.
I agree. I'll modify it.
+
guest_physmap_remove_page(d, gpfn, mfn);
+
+/* post-set PGC_allocated flag */
+do {
+x = mfn_to_page(mfn)-count_info;
+if ((x PGC_count_mask) == 0)
+goto out;
+nx = x | PGC_allocated;
+} while (cmpxchg_acq(mfn_to_page(mfn)-count_info, x, nx)
!= x);
+}
checking == 0 is non-sense because we incremented it.
Probably you want to
if (!test_and_set_bit(page-count_info, _PGC_allocated)) {
put_page(page);
goto out;
}
guest_physmap_remove_page() unsets PGC_allocated flag, thus
this test_and_set_bit() returns zero allways, I think.
In this code, I assumed that hypervisor might be destructing the
domain. In this case, the page counter might be zero.
Thanks,
- Tsunehisa Doi
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch] Fix for re-enabling PV-on-HVM on IPF
Hi all,
In last week, I submitted the patch to fix for compiling PV-on-HVM.
But, it crashed hypervisor, so..
I (Doi.Tsunehisa) said:
We'll have to modify the arch_memory_op code to follow dynamic grant
table size feature in the hypervisor side.
I've be investigating this issue, thus I found the reason of it.
* That patch itself was correct.
* not follow dynamic grant_table for PV-on-HVM on IPF
- we have to modify the arch_memory_op code.
- we have to modify guest_physmap_add_page() to support it.
(this is straight reason of hypervisor crash)
* in some case, a return value of hypercall from VT-i domain is broken.
So, I'll submit these patch..
* pvfix.patch
- fix for compling PV-on-HVM driver on IPF.
- this is same as that I send in last week.
* dynmic-gnttab.patch
- follow dynamic grant_table for PV-on-HVM on IPF
* avoid-crash.patch
- modify guest_physmap_add_page()
* hcall-rval.patch
- fix about a return value of hypercall from VT-i domain.
And, it requires the patch of xen-unstable.hg(cs:14089) for
PV-on-HVM enabling.
In out simple test, PV-on-HVM on IPF works.
Thanks,
- Tsunehisa Doi
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1173182115 -32400
# Node ID 59655cf89ac90a1f566bf8a59dbb65cf76d980e5
# Parent 8a58ea36e4207e6d47f8870632ab8fe14e3622cb
Fix for compiling PV-on-HVM driver on IPF
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r 8a58ea36e420 -r 59655cf89ac9
unmodified_drivers/linux-2.6/platform-pci/xen_support.c
--- a/unmodified_drivers/linux-2.6/platform-pci/xen_support.c Thu Mar 01
15:02:09 2007 -0700
+++ b/unmodified_drivers/linux-2.6/platform-pci/xen_support.c Tue Mar 06
20:55:15 2007 +0900
@@ -45,7 +45,13 @@ unsigned long __hypercall(unsigned long
return __res;
}
EXPORT_SYMBOL(__hypercall);
-#endif
+
+int HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count)
+{
+ return xencomm_mini_hypercall_grant_table_op(cmd, uop, count);
+}
+EXPORT_SYMBOL(HYPERVISOR_grant_table_op);
+#endif /* __ia64__ */
void xen_machphys_update(unsigned long mfn, unsigned long pfn)
{
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1173182911 -32400
# Node ID 4a02f5baf293c5f0dcfe425a42957b61aef619df
# Parent 08949bfc0193e4bbecba470cee40e30816392699
Avoid hypervisor crash for PV-on-HVM on IPF
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r 08949bfc0193 -r 4a02f5baf293 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.cTue Mar 06 21:04:28 2007 +0900
+++ b/xen/arch/ia64/xen/mm.cTue Mar 06 21:08:31 2007 +0900
@@ -1710,11 +1710,17 @@ guest_physmap_add_page(struct domain *d,
int ret;
BUG_ON(!mfn_valid(mfn));
-ret = get_page(mfn_to_page(mfn), d);
-BUG_ON(ret == 0);
+if (!IS_XEN_HEAP_FRAME(mfn_to_page(mfn))) {
+ret = get_page(mfn_to_page(mfn), d);
+BUG_ON(ret == 0);
+}
set_gpfn_from_mfn(mfn, gpfn);
smp_mb();
-assign_domain_page_replace(d, gpfn PAGE_SHIFT, mfn,
+if (IS_XEN_HEAP_FRAME(mfn_to_page(mfn)))
+assign_domain_page_replace(d, gpfn PAGE_SHIFT, mfn,
+ ASSIGN_writable);
+else
+assign_domain_page_replace(d, gpfn PAGE_SHIFT, mfn,
ASSIGN_writable | ASSIGN_pgc_allocated);
//BUG_ON(mfn != ((lookup_domain_mpa(d, gpfn PAGE_SHIFT) _PFN_MASK)
PAGE_SHIFT));
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1173182668 -32400
# Node ID 08949bfc0193e4bbecba470cee40e30816392699
# Parent 59655cf89ac90a1f566bf8a59dbb65cf76d980e5
Follow dynamic grant_table for PV-on-HVM on IPF
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r 59655cf89ac9 -r 08949bfc0193 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.cTue Mar 06 20:55:15 2007 +0900
+++ b/xen/arch/ia64/xen/mm.cTue Mar 06 21:04:28 2007 +0900
@@ -2087,12 +2087,23 @@ arch_memory_op(int op, XEN_GUEST_HANDLE(
break;
case XENMAPSPACE_grant_table:
spin_lock(d-grant_table-lock);
+
+if ((xatp.idx = nr_grant_frames(d-grant_table))
+(xatp.idx max_nr_grant_frames))
+gnttab_grow_table(d, xatp.idx + 1);
+
if (xatp.idx nr_grant_frames(d-grant_table))
-mfn = virt_to_mfn(d-grant_table-shared) + xatp.idx;
+mfn = virt_to_mfn(d-grant_table-shared[xatp.idx]);
+
spin_unlock(d-grant_table-lock);
break;
default:
break;
+}
+
+if (mfn == 0) {
+put_domain(d);
+return -EINVAL;
}
LOCK_BIGLOCK(d);
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1173183097 -32400
# Node ID c3fdaff60c05896fbbf13fa096eb1e4803c6ae8a
# Parent 4a02f5baf293c5f0dcfe425a42957b61aef619df
Fix about a return value of hypercall from VT-i domain
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r 4a02f5baf293 -r c3fdaff60c05 xen/arch/ia64/vmx/vmx_entry.S
---
Re: [Xen-ia64-devel] [Patch] Fix for re-enabling PV-on-HVM on IPF
Hi Yamahata-san,
Thank you for your comment.
You (yamahata) said:
On Tue, Mar 06, 2007 at 09:56:14PM +0900, DOI Tsunehisa wrote:
- we have to modify guest_physmap_add_page() to support it.
(this is straight reason of hypervisor crash)
The patch breaks the the p2m/m2p table convension.
get_page() shouldn't fail because xen heap page must be owned
by the domain when guest_physmap_add_page() is called.
share_xen_page_with_guest() does it.
I've thought that this patch is tricky, but I didn't find the
correct way to modify to avoid hypervisor crash issue.
What kind of page was passed when you observed the panic?
Who allocated and passed it?
Currently, without this patch, hypervisor crashes in PV-on-HVM
initialization phase..
* at share_info page remapping: success
- called from HYPERVISOR_memory_op in init_xen_info()..
(unmodified_drivers/linux-2.6/platform-pci/platform-pci.c)
* at grant table page remapping: crash
- called from gnttab_init() in init_xen_info()
- call tree in driver code is
gnttab_init() - gnttab_resume() - gnttab_map()
- HYPERVISOR_memory_op
(linux-2.6-xen-sparse/drivers/xen/core/gnttab.c)
- at guest_physmap_add_page() in hypervisor code,
1706 void
1707 guest_physmap_add_page(struct domain *d, unsigned long gpfn,
1708 unsigned long mfn)
1709 {
1710 int ret;
1711
1712 BUG_ON(!mfn_valid(mfn));
1713 ret = get_page(mfn_to_page(mfn), d);
1714 BUG_ON(ret == 0); it crashes at this point.
1715 set_gpfn_from_mfn(mfn, gpfn);
1716 smp_mb();
So, at grant table page remapping, the hypervisor crashes,
I think.
Thanks,
- Tsunehisa Doi
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] Fix for re-enabling PV-on-HVM on IPF
You (yamahata) said:
Currently, without this patch, hypervisor crashes in PV-on-HVM
initialization phase..
* at share_info page remapping: success
- called from HYPERVISOR_memory_op in init_xen_info()..
(unmodified_drivers/linux-2.6/platform-pci/platform-pci.c)
* at grant table page remapping: crash
- called from gnttab_init() in init_xen_info()
- call tree in driver code is
gnttab_init() - gnttab_resume() - gnttab_map()
- HYPERVISOR_memory_op
(linux-2.6-xen-sparse/drivers/xen/core/gnttab.c)
- at guest_physmap_add_page() in hypervisor code,
The grant table shared pages are owned by the domain
so that get_page() shouldn't fail.
Why get_page() fails?
The c/s 14010:01476c7804b2 of xen-ia64-unstable.hg twists
the grant table initialization a little.
Does it affect on vt-i domain initialization?
I've checked the reason of get_page() failing, so the domain
owner is correct, but the reference counter becomes zero at the
crash point..
And, I've tracked the counter, so it be cleared below:
[xen/arch/ia64/xen/mm.c]
long
arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
{
/* Unmap from old location, if any. */
gpfn = get_gpfn_from_mfn(mfn);
if (gpfn != INVALID_M2P_ENTRY)
guest_physmap_remove_page(d, gpfn, mfn);
I'll investigate it more.
Thanks,
- Tsunehisa Doi
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] Fix for re-enabling PV-on-HVM on IPF
Hi Yamahata-san,
I (Doi.Tsunehisa) said:
And, I've tracked the counter, so it be cleared below:
[xen/arch/ia64/xen/mm.c]
long
arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
{
/* Unmap from old location, if any. */
gpfn = get_gpfn_from_mfn(mfn);
if (gpfn != INVALID_M2P_ENTRY)
guest_physmap_remove_page(d, gpfn, mfn);
I'll investigate it more.
The reason of this issue might be the spec difference of
guest_physmap_remove_page() between x86 and IPF.
In x86 code, guest_physmap_remove_page() clears only p2m entry
and m2p entry.
But, in IPF code, domain_put_page() (called from zap_domain_page_one())
clears the page reference counter, I think.
# Is it correct ?
How should we be modified it ?
[xen/arch/ia64/xen/mm.c]
void
guest_physmap_remove_page(struct domain *d, unsigned long gpfn,
unsigned long mfn)
{
BUG_ON(mfn == 0);//XXX
zap_domain_page_one(d, gpfn PAGE_SHIFT, mfn);
perfc_incrc(guest_physmap_remove_page);
}
static void
zap_domain_page_one(struct domain *d, unsigned long mpaddr, unsigned long mfn)
{
struct mm_struct *mm = d-arch.mm;
volatile pte_t *pte;
pte_t old_pte;
struct page_info *page;
..
// exchange_memory() calls
// steal_page()
// page owner is set to NULL
// guest_physmap_remove_page()
// zap_domain_page_one()
domain_put_page(d, mpaddr, pte, old_pte, (page_get_owner(page) != NULL));
perfc_incrc(zap_dcomain_page_one);
}
Thanks,
- Tsunehisa Doi
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] Fix for compiling PV-on-HVM on IPF
Hi, Sorry, I'm bulding the test environment, now. I'll check it. Thanks You (xiantao.zhang) said: Hi Tsunehisa, Unluckily, we met xen crash with this patch. Do you know which #Cse t is stable enough for us to use VBD driver for HVM domain? :) Thanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DOI Tsunehisa Sent: 2007$BDj(B2$BTB(B27$BHU(B 7:34 To: xen-ia64-devel Subject: [Xen-ia64-devel] [Patch] Fix for compiling PV-on-HVM on IPF Hi all, In the latest ia64-unstable tree, we can't build PV-on-HVM driver, because of a compile error about HYPERVISOR_grant_table_op(). I'll submit a patch to modify it. But, I don't have the test environment that I use at once, thus I did compile test only. Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] Fix for compiling PV-on-HVM on IPF
Hi, I've checked it. We'll have to modify the arch_memory_op code to follow dynamic grant table size feature in the hypervisor side. The latest change set (that is stable enough) is cs:13904, I think. This change set was confirmed by Kuwamura-san. I (Doi.Tsunehisa) said: Hi, Sorry, I'm bulding the test environment, now. I'll check it. Thanks You (xiantao.zhang) said: Hi Tsunehisa, Unluckily, we met xen crash with this patch. Do you know which #Cse t is stable enough for us to use VBD driver for HVM domain? :) Thanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DOI Tsunehisa Sent: 2007$BDj(B2$BTB(B27$BHU(B 7:34 To: xen-ia64-devel Subject: [Xen-ia64-devel] [Patch] Fix for compiling PV-on-HVM on IPF Hi all, In the latest ia64-unstable tree, we can't build PV-on-HVM driver, because of a compile error about HYPERVISOR_grant_table_op(). I'll submit a patch to modify it. But, I don't have the test environment that I use at once, thus I did compile test only. Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] Modify for compiling PV-on-HVM and following callback_via
Hi Alex, You (alex.williamson) said: --- a/xen/include/public/arch-ia64.hMon Feb 05 13:19:10 2007 +0900 +++ b/xen/include/public/arch-ia64.hMon Feb 05 13:20:48 2007 +0900 @@ -64,9 +64,11 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t); #define VIRQ_MCA_CMCVIRQ_ARCH_1 /* MCA cmc interrupt */ #define VIRQ_MCA_CPEVIRQ_ARCH_2 /* MCA cpe interrupt */ +#if 0 /* Arch specific callback irq definition */ /* using Requester-ID(RID) as callback irq */ #define IA64_CALLBACK_IRQ_RID(1 31) +#endif Is this ever going to be defined? If not, I'd rather see it deleted along with the associated code. Thanks, I'm waving to decide it. I think that we should delete the definition for the future, but we'll have to keep it for backward compatibility. This spec is not included in any release version, thus we should select to delete it, I think. What do you think about this ? Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] Modify for compiling PV-on-HVM and following callback_via
Hi Alex,
Alex Williamson wrote:
IMHO, if it's #if 0'd out, it's not really adding to backwards
compatibility anyway. This wasn't in 3.0.4, so I think we should
probably drop it. Thanks,
I agree. I've modified the patch.
Thanks,
- Tsunehisa Doi
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1170745418 -32400
# Node ID 32d787da5ff555fb8991ccbb97c75897a9595bbd
# Parent d7f7021902a2c6b5beee0abfdbdc89fce7892450
Follow to allow PV-on-HVM callback irq to be identified by PCI device.
and delete IA64 specific spec concerned with IA64_CALLBACK_IRQ_RID.
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r d7f7021902a2 -r 32d787da5ff5
unmodified_drivers/linux-2.6/platform-pci/platform-pci.c
--- a/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c Mon Feb 05
15:41:58 2007 -0700
+++ b/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c Tue Feb 06
16:03:38 2007 +0900
@@ -181,23 +181,18 @@ static int get_hypercall_stubs(void)
static uint64_t get_callback_via(struct pci_dev *pdev)
{
+ u8 pin;
#ifdef __ia64__
int irq, rid;
for (irq = 0; irq 16; irq++) {
if (isa_irq_to_vector(irq) == pdev-irq)
- return irq;
- }
- /* use Requester-ID as callback_irq */
- /* RID: '#bus(8)#dev(5)#func(3)' (cf. PCI-Express spec) */
- rid = ((pdev-bus-number 0xff) 8) | pdev-devfn;
- printk(KERN_INFO DRV_NAME :use Requester-ID(%04x) as callback irq\n,
- rid);
- return rid | IA64_CALLBACK_IRQ_RID;
+ return irq; /* ISA IRQ */
+ }
#else /* !__ia64__ */
- u8 pin;
if (pdev-irq 16)
return pdev-irq; /* ISA IRQ */
+#endif
#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,16)
pin = pdev-pin;
@@ -211,7 +206,6 @@ static uint64_t get_callback_via(struct
((uint64_t)pdev-bus-number 16) |
((uint64_t)(pdev-devfn 0xff) 8) |
((uint64_t)(pin - 1) 3));
-#endif
}
/* Invalidate foreign mappings (e.g., in qemu-based device model). */
diff -r d7f7021902a2 -r 32d787da5ff5 xen/arch/ia64/vmx/vmx_process.c
--- a/xen/arch/ia64/vmx/vmx_process.c Mon Feb 05 15:41:58 2007 -0700
+++ b/xen/arch/ia64/vmx/vmx_process.c Tue Feb 06 16:03:38 2007 +0900
@@ -227,17 +227,23 @@ void leave_hypervisor_tail(void)
local_irq_disable();
if (v-vcpu_id == 0) {
-int callback_irq =
+unsigned long callback_irq =
d-arch.hvm_domain.params[HVM_PARAM_CALLBACK_IRQ];
+/*
+ * val[63:56] == 1: val[55:0] is a delivery PCI INTx line:
+ * Domain = val[47:32], Bus = val[31:16],
+ * DevFn = val[15: 8], IntX = val[ 1: 0]
+ * val[63:56] == 0: val[55:0] is a delivery as GSI
+ */
if (callback_irq != 0 local_events_need_delivery()) {
/* change level for para-device callback irq */
/* use level irq to send discrete event */
-if (callback_irq IA64_CALLBACK_IRQ_RID) {
-/* case of using Requester-ID as callback irq */
-/* RID: '#bus(8)#dev(5)#func(3)' */
-int dev = (callback_irq 3) 0x1f;
-viosapic_set_pci_irq(d, dev, 0, 1);
-viosapic_set_pci_irq(d, dev, 0, 0);
+if ((uint8_t)(callback_irq 56) == 1) {
+/* case of using PCI INTx line as callback irq */
+int pdev = (callback_irq 11) 0x1f;
+int pintx = callback_irq 3;
+viosapic_set_pci_irq(d, pdev, pintx, 1);
+viosapic_set_pci_irq(d, pdev, pintx, 0);
} else {
/* case of using GSI as callback irq */
viosapic_set_irq(d, callback_irq, 1);
diff -r d7f7021902a2 -r 32d787da5ff5 xen/include/public/arch-ia64.h
--- a/xen/include/public/arch-ia64.hMon Feb 05 15:41:58 2007 -0700
+++ b/xen/include/public/arch-ia64.hTue Feb 06 16:03:38 2007 +0900
@@ -63,10 +63,6 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
#define VIRQ_ITCVIRQ_ARCH_0 /* V. Virtual itc timer */
#define VIRQ_MCA_CMCVIRQ_ARCH_1 /* MCA cmc interrupt */
#define VIRQ_MCA_CPEVIRQ_ARCH_2 /* MCA cpe interrupt */
-
-/* Arch specific callback irq definition */
-/* using Requester-ID(RID) as callback irq */
-#define IA64_CALLBACK_IRQ_RID(1 31)
/* Maximum number of virtual CPUs in multi-processor guests. */
/* WARNING: before changing this, check that shared_info fits on a page */
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH] Optimize hypercall path in VTI domain
Hi Anthony-san, Thank you for your information. We'll try with latest changeset (cs:13837). You (anthony.xu) said: Hi Doi-san, I think you should try Cs13774 or latest Cset, The patch of Optimize hypercall path in VTI domain was checked in at Cs 13774. And this patch is a must for PV-on-HVM. - Anthony -Original Message- From: Tomonari Horikoshi [mailto:[EMAIL PROTECTED] Sent: 2007$BG/(B2$B7n(B2$BF|(B 16:35 To: [EMAIL PROTECTED]; Xu, Anthony Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel][PATCH] Optimize hypercall path in VTI domai n Hi Anthony-san Thank you for your patch. I tried to compile of PV-on-HVM in cs13773. But, It made an compile error because there was no CONFIG_VMX_GUEST. Compile is possible according to the attached patch. But Guest did Hung when insmod xenbus.ko was executed. We have not investigated the cause yet. Do you know the problem of looking like this? Thanks, - Tomonari Horikoshi -- (XEN) ivt_base: 0xf401 (XEN) arch_boot_vcpu: vcpu 1 awaken 04007f20! (XEN) Warning xen_hypercall should not be called 17 (XEN) Warning xen_hypercall should not be called 12 (XEN) Warning xen_hypercall should not be called 12 (XEN) Warning xen_hypercall should not be called 34 (XEN) Warning xen_hypercall should not be called 34 (XEN) Warning xen_hypercall should not be called 34 (XEN) $ PANIC in domain 2 (k6=0xf7b28000): This memory access instr can't be emulated: 80891325c0 pc= a00200090b30 (XEN) domain_crash_sync called from xenmisc.c:175 (XEN) Domain 2 (vcpu#0) crashed on cpu#2: (XEN) d 0xf7b1c080 domid 2 (XEN) vcpu 0xf7b28000 vcpu 0 (XEN) (XEN) CPU 2 (XEN) psr : 5210089a6010 ifs : 8206 ip : [a00200090 b31] (XEN) ip is at ??? (XEN) unat: pfs : 0409 rsc : 000 3 (XEN) rnat: bsps: e0001ed80ed8 pr : 0555a55 9 (XEN) ldrs: 00f8 ccv : fpsr: 0009804c8a70033 f (XEN) csd : ssd : (XEN) b0 : a00200090d60 b6 : a00100204680 b7 : a0010020386 0 (XEN) f6 : 0 f7 : 1003e0007 (XEN) f8 : 1003e0218 f9 : 1003e00199d10e381 (XEN) f10 : 1003e585da8c236353111 f11 : 1003e0012 (XEN) r1 : a0020029 r2 : r3 : a002000a288 8 (XEN) r8 : e0001ed80dd4 r9 : e0001ed87df0 r10 : 000 1 (XEN) r11 : 0001 r12 : e0001ed87dd0 r13 : e0001ed8000 0 (XEN) r14 : r15 : r16 : c000c2000e0 0 (XEN) r17 : c000c2000e00 r18 : fffe r19 : c000c20 0 (XEN) r20 : r21 : r22 : c000c20 0 (XEN) r23 : r24 : r25 : 000 0 (XEN) r26 : r27 : e0001ed87df4 r28 : 000 1 (XEN) r29 : a0020021aaa0 r30 : r31 : e0001c52983 0 (XEN) (XEN) Call Trace: (XEN) [f40b0b20] show_stack+0x80/0xa0 (XEN) sp=f7b2fa70 bsp=f7b 29418 (XEN) [f401f920] __domain_crash+0x110/0x150 (XEN) sp=f7b2fc40 bsp=f7b 293e8 (XEN) [f401f9a0] __domain_crash_synchronous+0x40/0xf0 (XEN) sp=f7b2fc40 bsp=f7b 293c0 (XEN) [f40869d0] panic_domain+0x140/0x150 (XEN) sp=f7b2fc40 bsp=f7b 29360 (XEN) [f408d940] emulate_io_inst+0x1c0/0xba0 (XEN) sp=f7b2fd70 bsp=f7b 29308 (XEN) [f4097d10] vmx_hpw_miss+0x3c0/0x900 (XEN) sp=f7b2fde0 bsp=f7b 292a8 (XEN) [f4093000] ia64_leave_hypervisor_prepare+0x0/0x40 (XEN) sp=f7b2fe00 bsp=f7b 292a8 (XEN) (XEN) Call Trace: (XEN) [f40b0b20] show_stack+0x80/0xa0 (XEN) sp=f7b2fa70 bsp=f7b 29418 (XEN) [f401f930] __domain_crash+0x120/0x150 (XEN) sp=f7b2fc40 bsp=f7b 293e8 (XEN) [f401f9a0] __domain_crash_synchronous+0x40/0xf0 (XEN) sp=f7b2fc40 bsp=f7b 293c0 (XEN) [f40869d0] panic_domain+0x140/0x150 (XEN) sp=f7b2fc40 bsp=f7b 29360 (XEN) [f408d940] emulate_io_inst+0x1c0/0xba0 (XEN) sp=f7b2fd70 bsp=f7b 29308 (XEN) [f4097d10] vmx_hpw_miss+0x3c0/0x900 (XEN) sp=f7b2fde0 bsp=f7b 292a8 (XEN) [f4093000]
Re: [Xen-ia64-devel][PATCH] Optimize hypercall path in VTI domain
Hi Anthony-san, I've checked it latest changeset (cs:13837). VNIF is available with the patch. I'll submit the patch and following patch. Thanks, - Tsunehisa Doi I (Doi.Tsunehisa) said: Hi Anthony-san, Thank you for your information. We'll try with latest changeset (cs:13837). You (anthony.xu) said: Hi Doi-san, I think you should try Cs13774 or latest Cset, The patch of Optimize hypercall path in VTI domain was checked in at Cs 13774. And this patch is a must for PV-on-HVM. - Anthony -Original Message- From: Tomonari Horikoshi [mailto:[EMAIL PROTECTED] Sent: 2007$BG/(B2$B7n(B2$BF|(B 16:35 To: [EMAIL PROTECTED]; Xu, Anthony Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel][PATCH] Optimize hypercall path in VTI dom ai n Hi Anthony-san Thank you for your patch. I tried to compile of PV-on-HVM in cs13773. But, It made an compile error because there was no CONFIG_VMX_GUEST. Compile is possible according to the attached patch. But Guest did Hung when insmod xenbus.ko was executed. We have not investigated the cause yet. Do you know the problem of looking like this? Thanks, - Tomonari Horikoshi -- (XEN) ivt_base: 0xf401 (XEN) arch_boot_vcpu: vcpu 1 awaken 04007f20! (XEN) Warning xen_hypercall should not be called 17 (XEN) Warning xen_hypercall should not be called 12 (XEN) Warning xen_hypercall should not be called 12 (XEN) Warning xen_hypercall should not be called 34 (XEN) Warning xen_hypercall should not be called 34 (XEN) Warning xen_hypercall should not be called 34 (XEN) $ PANIC in domain 2 (k6=0xf7b28000): This memory acce ss instr can't be emulated: 80891325c0 pc= a00200090b30 (XEN) domain_crash_sync called from xenmisc.c:175 (XEN) Domain 2 (vcpu#0) crashed on cpu#2: (XEN) d 0xf7b1c080 domid 2 (XEN) vcpu 0xf7b28000 vcpu 0 (XEN) (XEN) CPU 2 (XEN) psr : 5210089a6010 ifs : 8206 ip : [a002000 90 b31] (XEN) ip is at ??? (XEN) unat: pfs : 0409 rsc : 0 00 3 (XEN) rnat: bsps: e0001ed80ed8 pr : 0555a 55 9 (XEN) ldrs: 00f8 ccv : fpsr: 0009804c8a700 33 f (XEN) csd : ssd : (XEN) b0 : a00200090d60 b6 : a00100204680 b7 : a00100203 86 0 (XEN) f6 : 0 f7 : 1003e0007 (XEN) f8 : 1003e0218 f9 : 1003e00199d10e381 (XEN) f10 : 1003e585da8c236353111 f11 : 1003e0012 (XEN) r1 : a0020029 r2 : r3 : a002000a2 88 8 (XEN) r8 : e0001ed80dd4 r9 : e0001ed87df0 r10 : 0 00 1 (XEN) r11 : 0001 r12 : e0001ed87dd0 r13 : e0001ed80 00 0 (XEN) r14 : r15 : r16 : c000c2000 e0 0 (XEN) r17 : c000c2000e00 r18 : fffe r19 : c000c2000 00 0 (XEN) r20 : r21 : r22 : c000c2000 00 0 (XEN) r23 : r24 : r25 : 0 00 0 (XEN) r26 : r27 : e0001ed87df4 r28 : 0 00 1 (XEN) r29 : a0020021aaa0 r30 : r31 : e0001c529 83 0 (XEN) (XEN) Call Trace: (XEN) [f40b0b20] show_stack+0x80/0xa0 (XEN) sp=f7b2fa70 bsp=f 7b 29418 (XEN) [f401f920] __domain_crash+0x110/0x150 (XEN) sp=f7b2fc40 bsp=f 7b 293e8 (XEN) [f401f9a0] __domain_crash_synchronous+0x40/0xf0 (XEN) sp=f7b2fc40 bsp=f 7b 293c0 (XEN) [f40869d0] panic_domain+0x140/0x150 (XEN) sp=f7b2fc40 bsp=f 7b 29360 (XEN) [f408d940] emulate_io_inst+0x1c0/0xba0 (XEN) sp=f7b2fd70 bsp=f 7b 29308 (XEN) [f4097d10] vmx_hpw_miss+0x3c0/0x900 (XEN) sp=f7b2fde0 bsp=f 7b 292a8 (XEN) [f4093000] ia64_leave_hypervisor_prepare+0x0/0x40 (XEN) sp=f7b2fe00 bsp=f 7b 292a8 (XEN) (XEN) Call Trace: (XEN) [f40b0b20] show_stack+0x80/0xa0 (XEN) sp=f7b2fa70 bsp=f 7b 29418 (XEN) [f401f930] __domain_crash+0x120/0x150 (XEN) sp=f7b2fc40 bsp=f 7b 293e8 (XEN) [f401f9a0] __domain_crash_synchronous+0x40/0xf0 (XEN) sp=f7b2fc40 bsp=f 7b 293c0 (XEN) [f40869d0] panic_domain+0x140/0x150 (XEN)
[Xen-ia64-devel] [Patch] Modify for compiling PV-on-HVM and following callback_via
Hi all,
I modified to fix for compiling PV-on-HVM driver on IPF, and follow
to allow PV-on-HVM callback irq to be identified by PCI device.
In x86 code, callback irq spec was appended few weeks ago. The purpose
of appended spec was same with that we had introduced using RID for
callback irq. So, I modified to follow this change on IPF.
* comp-fix.patch
- Modify for compiling PV-on-HVM on IPF with latest changeset
(cs:13837)
* follow-pciintx.patch
- Follow to allow PV-on-HVM callback irq to be identifyed by
PCI device.
I tested with our simple test of PV-on-HVM on RHEL4 U4.
Thanks,
- Tsunehisa Doi
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1170649150 -32400
# Node ID 46d5f4863cfd4016b216f9ae5e1446b00a4ccc8e
# Parent fbc128aafdeb9c3726495211e0b017951672912a
Fix for compiling PV-on-HVM driver on IPF
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
Signed-off-by: Tomonari Horikoshi [EMAIL PROTECTED]
Signed-off-by: Anthony Xu [EMAIL PROTECTED]
diff -r fbc128aafdeb -r 46d5f4863cfd unmodified_drivers/linux-2.6/overrides.mk
--- a/unmodified_drivers/linux-2.6/overrides.mk Sun Feb 04 12:24:53 2007 -0700
+++ b/unmodified_drivers/linux-2.6/overrides.mk Mon Feb 05 13:19:10 2007 +0900
@@ -6,3 +6,6 @@
# a Xen kernel to find the right headers)
EXTRA_CFLAGS += -D__XEN_INTERFACE_VERSION__=0x00030202
EXTRA_CFLAGS += -I$(M)/include -I$(M)/compat-include
-DHAVE_XEN_PLATFORM_COMPAT_H
+ifeq ($(ARCH),ia64)
+ EXTRA_CFLAGS += -DCONFIG_VMX_GUEST
+endif
diff -r fbc128aafdeb -r 46d5f4863cfd
unmodified_drivers/linux-2.6/platform-pci/xen_support.c
--- a/unmodified_drivers/linux-2.6/platform-pci/xen_support.c Sun Feb 04
12:24:53 2007 -0700
+++ b/unmodified_drivers/linux-2.6/platform-pci/xen_support.c Mon Feb 05
13:19:10 2007 +0900
@@ -30,6 +30,23 @@
#include xen/platform-compat.h
#endif
+#if defined (__ia64__)
+unsigned long __hypercall(unsigned long a1, unsigned long a2,
+unsigned long a3, unsigned long a4,
+unsigned long a5, unsigned long cmd)
+{
+ unsigned long __res;
+ __asm__ __volatile__ (;;\n
+ mov r2=%1\n
+ break 0x1000 ;;\n
+ mov %0=r8 ;;\n
+ : =r(__res) : r(cmd) : r2, r8, memory);
+
+ return __res;
+}
+EXPORT_SYMBOL(__hypercall);
+#endif
+
void xen_machphys_update(unsigned long mfn, unsigned long pfn)
{
BUG();
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1170649248 -32400
# Node ID 69ded6c4860a3ab4e83179bda048c536d21af679
# Parent 46d5f4863cfd4016b216f9ae5e1446b00a4ccc8e
Follow to allow PV-on-HVM callback irq to be identified by PCI device.
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r 46d5f4863cfd -r 69ded6c4860a
unmodified_drivers/linux-2.6/platform-pci/platform-pci.c
--- a/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c Mon Feb 05
13:19:10 2007 +0900
+++ b/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c Mon Feb 05
13:20:48 2007 +0900
@@ -181,23 +181,26 @@ static int get_hypercall_stubs(void)
static uint64_t get_callback_via(struct pci_dev *pdev)
{
+ u8 pin;
#ifdef __ia64__
int irq, rid;
for (irq = 0; irq 16; irq++) {
if (isa_irq_to_vector(irq) == pdev-irq)
- return irq;
- }
+ return irq; /* ISA IRQ */
+ }
+#ifdef IA64_CALLBACK_IRQ_RID
/* use Requester-ID as callback_irq */
/* RID: '#bus(8)#dev(5)#func(3)' (cf. PCI-Express spec) */
rid = ((pdev-bus-number 0xff) 8) | pdev-devfn;
printk(KERN_INFO DRV_NAME :use Requester-ID(%04x) as callback irq\n,
rid);
return rid | IA64_CALLBACK_IRQ_RID;
+#endif /* IA64_CALLBACK_IRQ_RID */
#else /* !__ia64__ */
- u8 pin;
if (pdev-irq 16)
return pdev-irq; /* ISA IRQ */
+#endif
#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,16)
pin = pdev-pin;
@@ -211,7 +214,6 @@ static uint64_t get_callback_via(struct
((uint64_t)pdev-bus-number 16) |
((uint64_t)(pdev-devfn 0xff) 8) |
((uint64_t)(pin - 1) 3));
-#endif
}
/* Invalidate foreign mappings (e.g., in qemu-based device model). */
diff -r 46d5f4863cfd -r 69ded6c4860a xen/arch/ia64/vmx/vmx_process.c
--- a/xen/arch/ia64/vmx/vmx_process.c Mon Feb 05 13:19:10 2007 +0900
+++ b/xen/arch/ia64/vmx/vmx_process.c Mon Feb 05 13:20:48 2007 +0900
@@ -227,17 +227,33 @@ void leave_hypervisor_tail(void)
local_irq_disable();
if (v-vcpu_id == 0) {
-int callback_irq =
+unsigned long callback_irq =
d-arch.hvm_domain.params[HVM_PARAM_CALLBACK_IRQ];
+/*
+ * val[63:56] == 1: val[55:0] is a delivery PCI INTx line:
+ * Domain = val[47:32], Bus = val[31:16],
+ * DevFn = val[15: 8], IntX = val[ 1: 0]
+ * val[63:56] == 0: val[55:0] is a
Re: [Xen-ia64-devel][PATCH] Optimize hypercall path in VTI domain
You (anthony.xu) said: Hi Doi-san I know you are working on PV-ON-HVM, Applying both attatchments can make VBD work on VTI-domain on Cset 13465, I didn't try VNIF. In case we are doing the duplicated thing. Hi Anthony-san, Thank you!! I'll try it. BTW, in x86 code, the spec of callback irq was appended. It became to use PCI INTx line as callback irq. I'll modify to follow it. Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch] Follow new interrupt deliver mechanism for PV-on-HVM/IPF
Hi all,
I modified to follow new interrupt deliver mechanism for PV-on-HVM/IPF.
New interrupt deliver mechanism changed GSI of pseudo hardware for
PV-on-HVM. So, old get_callback_irq function can't get GSI of it.
In this case, I modified that PV-driver notices Requester-ID(RID) to
hypervisor as callback irq with RID marker(MSB).
RID contains a bus number, a device number and a function number.
(cf. PCI-Express spec)
* pvdrv.patch
- Modify to change the spec of callback IRQ in PV-driver side.
* hyper.patch
- Modify to change the spec of callback IRQ in hypervisor side.
I tested with our simple test of PV-on-HVM on RHEL4 U4.
Thanks,
- Tsunehisa Doi
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 656f00fcd551061c268b73bfe9d7b92a2f53bdcc
# Parent 6e68e8a8cc99717b372c482efa0e153e868ae6f4
Follow new interrupt deliver mechanism for PV-on-HVM/IPF (driver side)
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r 6e68e8a8cc99 -r 656f00fcd551
unmodified_drivers/linux-2.6/platform-pci/platform-pci.c
--- a/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c Mon Dec 18
10:56:34 2006 -0700
+++ b/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c Tue Dec 19
18:22:05 2006 +0900
@@ -182,12 +182,16 @@ static int get_callback_irq(struct pci_d
static int get_callback_irq(struct pci_dev *pdev)
{
#ifdef __ia64__
- int irq;
+ int irq, rid;
for (irq = 0; irq 16; irq++) {
if (isa_irq_to_vector(irq) == pdev-irq)
return irq;
}
- return 0;
+ /* use Requester-ID as callback_irq */
+ /* RID: '#bus(8)#dev(5)#func(3)' (cf. PCI-Express spec) */
+ rid = ((pdev-bus-number 0xff) 8) | pdev-devfn;
+ printk(KERN_INFO DRV_NAME :use Requester-ID(%04x) as callback irq\n,
rid);
+ return rid | (1 31); /* with RID marker(MSB) */
#else /* !__ia64__ */
return pdev-irq;
#endif
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 8217a7ba6d9adbadeda939756346bcedb080a0f8
# Parent 656f00fcd551061c268b73bfe9d7b92a2f53bdcc
Follow new interrupt deliver mechanism for PV-on-HVM/IPF (hypervisor side)
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r 656f00fcd551 -r 8217a7ba6d9a xen/arch/ia64/vmx/vmx_process.c
--- a/xen/arch/ia64/vmx/vmx_process.c Tue Dec 19 18:22:05 2006 +0900
+++ b/xen/arch/ia64/vmx/vmx_process.c Tue Dec 19 18:23:33 2006 +0900
@@ -212,8 +212,18 @@ void leave_hypervisor_tail(struct pt_reg
if (callback_irq != 0 local_events_need_delivery()) {
/* change level for para-device callback irq */
/* use level irq to send discrete event */
-viosapic_set_irq(d, callback_irq, 1);
-viosapic_set_irq(d, callback_irq, 0);
+if (callback_irq (1 31) /* RID marker(MSB) */) {
+/* case of using Requester-ID as callback irq */
+/* RID: '#bus(8)#dev(5)#func(3)' */
+int rid = (callback_irq ~(1 31));
+viosapic_set_pci_irq(d, ((rid 3) 0x1f), 0, 1);
+viosapic_set_pci_irq(d, ((rid 3) 0x1f), 0, 0);
+}
+else {
+/* case of using GSI as callback irq */
+viosapic_set_irq(d, callback_irq, 1);
+viosapic_set_irq(d, callback_irq, 0);
+}
}
}
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] Follow new interrupt deliver mechanism for PV-on-HVM/IPF
Hi Alex, Thank you for your comment. You (alex.williamson) said: +return rid | (1 31); /* with RID marker(MSB) */ Ok, except (1 31) needs to be defined in a common header somewhere so it's not just a random magic bit. Thanks, I agree it. I think that the definition should be in xen/include/public/hvm/params.h or xen/include/public/arch-ia64.h. What do you think about this ? - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] Follow new interrupt deliver mechanism for PV-on-HVM/IPF
You (alex.williamson) said: I think that the definition should be in xen/include/public/hvm/params.h or xen/include/public/arch-ia64.h. What do you think about this ? It's ia64 specific, so arch-ia64.h seems more appropriate. Thank you for your advice. I'll modify the code with your opinion. Just an FYI, I think we're close enough to when Keir wants to make a final 3.0.4 release that I don't plan to request another pull of the xen-ia64 tree unless it's absolutely necessary. If you think this is necessary for 3.0.4, please provide justification. Thanks, In current xen-ia64 tree, PV-on-HVM feature does not work, thus this fix is necessary, I think. Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] Follow new interrupt deliver mechanism for PV-on-HVM/IPF
Hi Alex,
[EMAIL PROTECTED] wrote:
You (alex.williamson) said:
I think that the definition should be in xen/include/public/hvm/params.h
or xen/include/public/arch-ia64.h.
What do you think about this ?
It's ia64 specific, so arch-ia64.h seems more appropriate.
Thank you for your advice. I'll modify the code with your opinion.
I modified this patch, and tested it.
Just an
FYI, I think we're close enough to when Keir wants to make a final 3.0.4
release that I don't plan to request another pull of the xen-ia64 tree
unless it's absolutely necessary. If you think this is necessary for
3.0.4, please provide justification. Thanks,
In current xen-ia64 tree, PV-on-HVM feature does not work, thus
this fix is necessary, I think.
My opinion is that..
* New interrupt deliver mechanism broke PV-on-HVM feature, thus
it doesn't work with current xen-ia64 tree.
* This fix is necessary for re-enabling PV-on-HVM feature on IPF.
Thanks,
- Tsunehisa Doi
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 6870c9948e5c63cd9ba8d9427b70f91ec467605e
# Parent 934315daf75988b8b5b6cc370d6114ec014ed20b
Follow new interrupt deliver mechanism for PV-on-HVM/IPF (driver side)
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r 934315daf759 -r 6870c9948e5c
unmodified_drivers/linux-2.6/platform-pci/platform-pci.c
--- a/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c Wed Dec 20
11:36:49 2006 +0900
+++ b/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c Wed Dec 20
11:38:31 2006 +0900
@@ -182,12 +182,16 @@ static int get_callback_irq(struct pci_d
static int get_callback_irq(struct pci_dev *pdev)
{
#ifdef __ia64__
- int irq;
+ int irq, rid;
for (irq = 0; irq 16; irq++) {
if (isa_irq_to_vector(irq) == pdev-irq)
return irq;
}
- return 0;
+ /* use Requester-ID as callback_irq */
+ /* RID: '#bus(8)#dev(5)#func(3)' (cf. PCI-Express spec) */
+ rid = ((pdev-bus-number 0xff) 8) | pdev-devfn;
+ printk(KERN_INFO DRV_NAME :use Requester-ID(%04x) as callback irq\n,
rid);
+ return rid | HVM_PARAM_CALLBACK_IRQ_USING_RID;
#else /* !__ia64__ */
return pdev-irq;
#endif
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 934315daf75988b8b5b6cc370d6114ec014ed20b
# Parent c3b455c4676c6446cd541d4c67a521609d046ddb
Follow new interrupt deliver mechanism for PV-on-HVM/IPF (hypervisor side)
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r c3b455c4676c -r 934315daf759 xen/arch/ia64/vmx/vmx_process.c
--- a/xen/arch/ia64/vmx/vmx_process.c Tue Dec 19 13:31:48 2006 -0700
+++ b/xen/arch/ia64/vmx/vmx_process.c Wed Dec 20 11:36:49 2006 +0900
@@ -212,8 +212,18 @@ void leave_hypervisor_tail(struct pt_reg
if (callback_irq != 0 local_events_need_delivery()) {
/* change level for para-device callback irq */
/* use level irq to send discrete event */
-viosapic_set_irq(d, callback_irq, 1);
-viosapic_set_irq(d, callback_irq, 0);
+if (callback_irq HVM_PARAM_CALLBACK_IRQ_USING_RID) {
+/* case of using Requester-ID as callback irq */
+/* RID: '#bus(8)#dev(5)#func(3)' */
+int rid = callback_irq ~HVM_PARAM_CALLBACK_IRQ_USING_RID;
+viosapic_set_pci_irq(d, ((rid 3) 0x1f), 0, 1);
+viosapic_set_pci_irq(d, ((rid 3) 0x1f), 0, 0);
+}
+else {
+/* case of using GSI as callback irq */
+viosapic_set_irq(d, callback_irq, 1);
+viosapic_set_irq(d, callback_irq, 0);
+}
}
}
diff -r c3b455c4676c -r 934315daf759 xen/include/public/arch-ia64.h
--- a/xen/include/public/arch-ia64.hTue Dec 19 13:31:48 2006 -0700
+++ b/xen/include/public/arch-ia64.hWed Dec 20 11:36:49 2006 +0900
@@ -61,6 +61,10 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
#define VIRQ_ITCVIRQ_ARCH_0 /* V. Virtual itc timer */
#define VIRQ_MCA_CMCVIRQ_ARCH_1 /* MCA cmc interrupt */
#define VIRQ_MCA_CPEVIRQ_ARCH_2 /* MCA cpe interrupt */
+
+/* Arch specific callback irq definition */
+/* using Requester-ID(RID) as callback irq */
+#define HVM_PARAM_CALLBACK_IRQ_USING_RID(1 31)
/* Maximum number of virtual CPUs in multi-processor guests. */
/* WARNING: before changing this, check that shared_info fits on a page */
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH]Change to new interrupt deliver mechanism
You (anthony.xu) said: BTW, in my experience, the vector doesn't set to VIOSAPIC at HVMOP_set_param hypercall. Thus I'll implement to find the GSI at interrupt injection phase. In this case, Can we call set_callback_irq with hardware irq inside Qemu rather than platform_pci, just after platform_pci is initiated in Qemu? It seems resolve this issue. What's your opinion about this? Sorry, I don't know this issue for detail. I think that the guest OS sets interrupt mask register of VIOSAPIC until setting own vector. I assume that the guest OS might change the vector for such hardware in active state. BTW I found we use viosapic_set_irq to pend the platform_pci interrupt. It may be no correct, because platform_pic interrupt is like edge triggered interrupt, but VIOSAPIC for this irq is programmed to a level triggered due to it is PCI device. I'll fix this. Thank you. - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH]Change to new interrupt deliver mechanism
Hi Anthony, You (anthony.xu) said: Sorry, I don't know this issue for detail. I think that the guest OS sets interrupt mask register of VIOSAPIC until setting own vector. I assume that the guest OS might change the vector for such hardware in active state. Hi Doi, This issue is from you, guest linux uses vector, while there is no function like vector_to_irq. Sorry, I might misunderstand your comment. Yes, I think so. Because the hardware irq for platform_pci will not be changes. We can call set_callback_irq with hardware irq inside Qemu, Thus, platform_pci driver don't need to call set_callback_irq. Yes, guest OS can change the vector for platform_pci hardware irq, But the hardware irq is not changed, and HV know how to translate hardware irq to level through VIOSAPIC, And HV still use viosapic_set_irq to pend platform_pci interrupt. So I think it works. Do you meen that we have to modify qemu code to solve this isssue ? Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH]Change to new interrupt deliver mechanism
Hi Anthony,
This issue is from you, guest linux uses vector, while there is no
function like vector_to_irq.
Sorry, I might misunderstand your comment.
I've been thinking more about your comment.
We may be able to call set_callback_irq inside qemu, but I don't
think that it's good solution for this issue. Because qemu doesn't
have such interface in current implementation, and HV can't know
that PV-on-HVM driver is initiated or not, I think.
I've thought that we can get GSI for platform_pci from Device ID
in HV, if mapping betweeen devid and gsi is fixed.
There is hvm_pci_intx_gsi() macro in xen/arch/ia64/vmx/viosapic.c
[xen/arch/ia64/vmx/viosapic.c]-
#define hvm_pci_intx_gsi(dev, intx) \
(dev) 2) + ((dev) 3) + (intx)) 31) + 16)
void viosapic_set_pci_irq(struct domain *d, int device, int intx, int level)
{
int irq;
irq = hvm_pci_intx_gsi(device, intx);
viosapic_set_irq(d, irq, level);
}
---
It seems that device to gsi mapping is fixed. If it's correct,
we can get GSI in HV from device ID which is notified from PV-driver
with set_callback_irq.
What do you think about this ?
Thanks,
- Tsunehisa Doi
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH]Change to new interrupt deliver mechanism
Hi Anthony, You (anthony.xu) said: Do you meen that we have to modify qemu code to solve this isssue ? Doi, I think it's a clean way to handle both windows and linux guest in IPF side. And it is a very little modification in Qemu. But maybe IA32 can not use this method, because there may be two hardware irq for platform_pci, one is for PIC(i8259, irq 10 or 11), the other is for IOAPIC( maybe irq 28). In IPF side, there is only IOSAPIC, so there is only un-changed hardware irq (28) for platfrom_pci device. If IA32 platform can not use this method, we must find anothger aproach to resolve this issue, I think. Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH]Change to new interrupt deliver mechanism
Hi Anthony, You (anthony.xu) said: * Hypervisor becomes to be able to use both GSI and Vector for callback irq. - For example, if it is normal value, HV accepts it as GSI. If it is value which is set MSB, HV accepts it as Vector. * If hypervisor gets Vector as callback irq, hypervisor finds the GSI for the pseudo device from virtual interrupt controller setting. What do you think about this method ? Hi Doi, There is only one IOAPIC in IPF, So irq is equal to GSI, Hardware IRQ is equal to GSI, but the IRQ in IPF-linux world is abstruct value not GSI. So we need to get GSI for platform-pci from IPF-linux world's IRQ. But I didn't find it. - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH]Change to new interrupt deliver mechanism
Hi Anthony, Thank you for your comment. You (anthony.xu) said: Hardware IRQ is equal to GSI, but the IRQ in IPF-linux world is abstruct value not GSI. So we need to get GSI for platform-pci from IPF-linux world's IRQ. But I didn't find it. * Hypervisor becomes to be able to use both GSI and Vector for callback irq. - For example, if it is normal value, HV accepts it as GSI. If it is value which is set MSB, HV accepts it as Vector. * If hypervisor gets Vector as callback irq, hypervisor finds the GSI for the pseudo device from virtual interrupt controller setting. Hi Doi, Understand you question now. Linux-irq is equal to vector in VIOSAPIC, I think linux-irq will not alter after guest linux boot, So platform_pci can call set_callback_irq using vector (linux-irq). HV will directly pend this vector without looking for VIOSAPIC. We had implemented older PV-on-HVM with the method like this. But, we found the issue that interrupt was injected during interrupt masking of VIOSAPIC. So we changed to implement it. In this time, we have to implement it that interrupt injection follows VIOSAPIC status. Thus, HV should look for VIOSAPIC, I think. Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH]Change to new interrupt deliver mechanism
Hi Anthony, You (anthony.xu) said: We had implemented older PV-on-HVM with the method like this. But, we found the issue that interrupt was injected during interrupt masking of VIOSAPIC. So we changed to implement it. In this time, we have to implement it that interrupt injection follows VIOSAPIC status. Thus, HV should look for VIOSAPIC, I think. Hi Dio, If platform_pci conforms to IOSAPIC, I has below suggestion. 1. platform_pci calls set_callback_irq using vector, 2. since HVMOP_set_param hypercall is arch-specific, HV can translate vector to irq, ( VIOSAPIC can provide this interface), 3. if there is event to besent, HV calls viosapic_set_irq to pend interrupt. What's your opinion about this? Basically, I agree your suggestion in Linux guest. But in Windows guest, PV-driver can't get vector with own driver interface. So, I think that HV has to have the interfaces about callback irq in both cases, using GSI and Vector. BTW, in my experience, the vector doesn't set to VIOSAPIC at HVMOP_set_param hypercall. Thus I'll implement to find the GSI at interrupt injection phase. Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH]Change to new interrupt deliver mechanism
Hi, I (Doi.Tsunehisa) said: Hmm.. Current implement needs the GSI for platform-pci to follow status of virtual IOSAPIC in hypervisor side. But, it's not certain value from virtual IOSAPIC at calling set_callback_irq hypercall. I'll be thinking more... I've investigated it, but I couldn't find the method to get GSI of platform-pci for PV-on-HVM driver. There is convert functions like isa_irq_to_vector() in linux kernel source. [arch/ia64/kernel/apci.c] int acpi_gsi_to_irq(u32 gsi, unsigned int *irq) [arch/ia64/kernel/iosapic.c] inline int gsi_to_vector (unsigned int gsi) But, these functions are not EXPORT_SYMBOLE, thus we can't use them for kernel module. So, I think that.. * Hypervisor becomes to be able to use both GSI and Vector for callback irq. - For example, if it is normal value, HV accepts it as GSI. If it is value which is set MSB, HV accepts it as Vector. * If hypervisor gets Vector as callback irq, hypervisor finds the GSI for the pseudo device from virtual interrupt controller setting. What do you think about this method ? Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH]Change to new interrupt deliver mechanism
Hi Anthony, You (anthony.xu) said: Due to we are using pci irq(15) for platform_pci, We may need to revert back this patch(Issue about interrupt for PV-on-HVM on IPF). Sorry, please tell me about the change. Actually, what will GSI for platform_pci become ? Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH]Change to new interrupt deliver mechanism
Due to we are using pci irq(15) for platform_pci, We may need to revert back this patch(Issue about interrupt for PV-on-HVM on IPF). Sorry, please tell me about the change. Actually, what will GSI for platform_pci become ? It becomes 28. $B!!(BThanks... Hmm.. I'll have to think of the conversion from vector to GSI. - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH]Change to new interrupt deliver mechanism
You (anthony.xu) said: [EMAIL PROTECTED] write on 2006$BG/(B12$B7n(B1$BF|(B 17:53: Due to we are using pci irq(15) for platform_pci, We may need to revert back this patch(Issue about interrupt for PV-on-HVM on IPF). Sorry, please tell me about the change. Actually, what will GSI for platform_pci become ? It becomes 28. $B!!(BThanks... Hmm.. I'll have to think of the conversion from vector to GSI. I think we can use pdev-irq directly in platform-pci.c at least in guest linux, I'm not sure about guest Windows. Hmm.. Current implement needs the GSI for platform-pci to follow status of virtual IOSAPIC in hypervisor side. But, it's not certain value from virtual IOSAPIC at calling set_callback_irq hypercall. I'll be thinking more... Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [IPF-xenU] xm destroy xenU may make xen0 crash
Hi, It's a temporary solution to avoid hypervisor crash... We can avoid to crash hypervisor with `xm network-detach' command. Before the domain destruction, you should detach all VNIF of the domain with `xm network-detach domid nifid' command, if you want to avoid crash hypervisor. Thanks, - Tsunehisa Doi You (jingke.zhang) said: Good, this issue also exists on newest #Cset12520. Wish it will be solved by the patch soon! Thanks, Zhangjingke -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, November 21, 2006 6:18 PM To: Zhang, Jingke Cc: Akio Takebe; xen-ia64-devel Subject: Re: [Xen-ia64-devel] [IPF-xenU] xm destroy xenU may make xen0 crash Hi, You (jingke.zhang) said: (XEN) BUG at mm.c:407 (XEN) FIXME: implement ia64 dump_execution_state() (XEN) (XEN) (XEN) Panic on CPU 1: (XEN) BUG at mm.c:407 (XEN) (XEN) (XEN) Reboot in five seconds... This issue is that it occurs in a race condition between p2m table destruction and gnttab_copy for VNIF copy receiver. We've been investigating it recently. We'll submit a patch to solve it one of these days, I think. Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Modify to introduce delayed p2m table destruction
Thank you for your suggestion.
We'll study it.
Thanks,
- Tsunehisa Doi
You (yamahata) said:
However during shadow_teardown_xxx() in your patch
other domain might access the p2m table and struct page_info.
Page reference convension must be kept right during them.
Yes, it might access them. In past, I thought so, but after
discussion about delayed p2m table destruction of shadow2, I've be
satisfied that get_page avoids memory corruption finally.
You might understand x86 shadow code.
However you must understand IA64 code too.
It would be effective to understand IA64 code by analogy of
x86 shadow code, But they're different.
Hmm, I don't understand the difference.
Can you give me suggestion about the difference ?
The Xen/IA64 p2m table is lockless while Xen/x86 shadow p2m table
is protected by shadow_lock()/shadow_unlock().
This is a burden to the Xen/IA64 p2m maintenance.
So we must be very carefull when modifying it.
Especially we must be aware of memory ordering.
This is the reason why volatile is sprinckled.
In Xen/IA64 p2m case
page reference count must be increased before you add the new entry,
page reference count must be decreased after removing the entry.
The only exception is relinquish_pte() because it assumes that
the p2m itself is freed. (But this assumption is wrong.)
However Xen/x86 shadow p2m doesn't care abount page reference count.
The blktap patches which I sent out last night impose a one more new rule
which is related to PGC_allocated flag.
The patch introduces _PAGE_PGC_ALLOCATED.
When the p2m entry is removed and _PAGE_PGC_ALLOCATED bit is set,
something like
if (pte_pgc_allocated(old_pte)) {
if (test_and_clear(_PGC_allocated, page-count_info))
put_page(page)
}
must be done. domain_put_page() takes care of it.
Thanks.
--
yamahata
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Modify to introduce delayed p2m table destruction
Hi, You (yamahata) said: - Probably IA64 specific code paths assume that if the p2m conversion gives valid mfn, then the page isn't free. Your patch breaks it. I haven't check it though. In our investigation, the domain is paused at domain_kill phase, thus it don't occur the issue, and x86 code had introduced same logic. Although all vcpus of the domain are paused, how about another domain's vcpu? It might be possible for another domain's vcpu to modify the p2m table. I think, the p2m table of the domain (during destruction indeed) is not modified by any domain. Gran table reference has a possiblity of p2m table modified by other domain, but in this case, grant table reference releases before `shadow_teardown'. In other hand, p2m table of other domain might become to refer the same page frame which has used by destructing domain. In this case, get_page() is final guard to avoid memory coruption. In x86 code, it is introduced same logic. I discussed about the delayed p2m table destruction in xen-devel community, thus I confirmed it. I suppose that it avoids to be too heavy to comform. And one more comment. - your patch breaks page reference convension. During domain creation and destruction, it might be broken, but it has to do, I think. - Why shadow prefix? it isn't related to shadow. In IA64 code, it doesn't have shadow page table, but it regards that it has shadow mode, I think. Thus I adopted shadow prefix to follow other arch. Shadow prefix is confusing here. (At least for me) I don't have so good idea. What do you think about below ? - shadow_teardown- teardown_mm - shadow_final_teardown - final_teardown_mm - shadow_p2m_teardown- final_p2m_teardown Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Modify to introduce delayed p2m table destruction
You (yamahata) said: I think, the p2m table of the domain (during destruction indeed) is not modified by any domain. Gran table reference has a possiblity of p2m table modified by other domain, but in this case, grant table reference releases before `shadow_teardown'. Grant table page transfer does. (So In fact before this issue raise, the p2m destruction code was already broken. Fortunately no one hit this.) Hmm, I've thought that gnttab_release_mapping() ensures it... - your patch breaks page reference convension. During domain creation and destruction, it might be broken, but it has to do, I think. What do you mean by destruction? I meen domain destruction. It's so sutble that you had to defer the p2m table freeing, didn't you? Yes, I wanted to defer the p2m table freeing. After arch_domain_destroy() no other domain modify the p2m table, so breaking the page reference convesion is O.K. after that. Yes, but arch_domain_destroy() is final stage of domain destruction called by domain_destroy() which is called until d-refcnt becomes zero. I think that it has to do during p2m table destruction. However during shadow_teardown_xxx() in your patch other domain might access the p2m table and struct page_info. Page reference convension must be kept right during them. Yes, it might access them. In past, I thought so, but after discussion about delayed p2m table destruction of shadow2, I've be satisfied that get_page avoids memory corruption finally. Shadow prefix is confusing here. (At least for me) I don't have so good idea. What do you think about below ? - shadow_teardown- teardown_mm - shadow_final_teardown - final_teardown_mm - shadow_p2m_teardown- final_p2m_teardown How about s/shadow/mm/ ? Oh! It's good idea. I'll change prefix with this idea. Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Modify to introduce delayed p2m table destruction
You (yamahata) said: Hmm, I've thought that gnttab_release_mapping() ensures it... No. gnttab_release_mapping() is for a domain which maps a page granted by another domain. Not for a domain which grants page mapping. Ok. I understood it. However during shadow_teardown_xxx() in your patch other domain might access the p2m table and struct page_info. Page reference convension must be kept right during them. Yes, it might access them. In past, I thought so, but after discussion about delayed p2m table destruction of shadow2, I've be satisfied that get_page avoids memory corruption finally. You might understand x86 shadow code. However you must understand IA64 code too. It would be effective to understand IA64 code by analogy of x86 shadow code, But they're different. Hmm, I don't understand the difference. Can you give me suggestion about the difference ? Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Modify to introduce delayed p2m table destruction
You (yamahata) said: Some comments. - Probably IA64 specific code paths assume that if the p2m conversion gives valid mfn, then the page isn't free. Your patch breaks it. I haven't check it though. In our investigation, the domain is paused at domain_kill phase, thus it don't occur the issue, and x86 code had introduced same logic. - Why shadow prefix? it isn't related to shadow. In IA64 code, it doesn't have shadow page table, but it regards that it has shadow mode, I think. Thus I adopted shadow prefix to follow other arch. Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel][PATCH][RESEND] PV drivers for HVM guests
Hi Ian, You (Ian.Campbell) said: I'd much prefer it if we can find a way to avoid encoding specific RHEL kernel versions as you had in your patch. I've gone with #define gfp_t unsigned which basically ignores any existing typedef. I think this is OK in this instance since gfp_t has always been . My current patch is below, it cross-compiles for IA64 without warnings against RHEL4.4 and SLES9sp3. Could you let me know if it works for you? If so would you mind submitting the ia64 bits via the ia64 maintainer. I'll apply the unmodified_drivers bits. Takanori (he is my co-worker) checked this patch, but it occures compile error in linux-xen. We are investigating it. BTW, I might find a issue about NET_IP_ALIGN in the compatible shim. Currentry, its value is 0, but the value should be matched a value of netback module. Thus, its value should be 2, I think. What do you think about the issue ? My thinking was that since those older kernels don't define NET_IP_ALIGN and don't hardcode the number 2 anywhere they don't expect any extra alignment. Therefore using 0 seems correct in terms of behaving the same as native drivers do on those versions. I'm not sure I would want to backport the addition of the extra padding in our drivers, the distros haven't seen the need for example... Hmm, I thought that NET_IF_ALIGN mismatch between netfront and netback occures a confusion of VNIF. But I might be imagining if it was used correctly. Is it used on SLES9 guest ? I don't have the environment. Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] BUG at mm.c:605
Hi Alex,
Alex Williamson wrote:
Ok, should I simply revert xen-ia64-unstable cset 11636:3470d9cd27e5?
Basically, yes. But we can't avoid hypervisor crash during domain
destruction.
I think to modify above patch to remove VT-i domain checker like
attaced patch, until we will success to seek for the right fix.
This seems worse. Instead of having an identifiable crash footprint,
the system just hangs with this patch. Thanks,
I see. In this time, I inserted dump_stack() at the condition.
What do you think about it ?
Thanks
- Tsuneshisa Doi
Preliminary fix to avoid hypervisor crash during domain destruction
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r ee7799388ab1 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.cWed Oct 18 22:07:18 2006 -0600
+++ b/xen/arch/ia64/xen/mm.cThu Oct 19 17:01:41 2006 +0900
@@ -399,11 +399,11 @@ gmfn_to_mfn_foreign(struct domain *d, un
unsigned long pte;
// This function may be called from __gnttab_copy()
- // during destruction of VT-i domain with PV-on-HVM driver.
+ // during domain destruction with VNIF copy receiver.
// ** FIXME: This is not SMP-safe yet about p2m table. **
if (unlikely(d-arch.mm.pgd == NULL)) {
- if (VMX_DOMAIN(d-vcpu[0]))
- return INVALID_MFN;
+ dump_stack(); // collect footprint
+ return INVALID_MFN;
}
pte = lookup_domain_mpa(d,gpfn PAGE_SHIFT, NULL);
if (!pte) {
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Thanks!
Hi Tristan, Thank you for many advices and suggestion. I've been fortunate to have good time to work with you. You (Tristan.Gingold) said: Hi, before leaving Bull I'd like to thanks everyone. Thanks to HP for initiating Xen/ia64 and managing the project in a very democratic way. Thanks to Intel for bringing its OEM to Xen. Thanks to every contributors. The xen/ia64 community is small but very active. Xen/ia64 has made amazing progresses. If any thanks to those I have forgotten! If you need to reach me, my private email is [EMAIL PROTECTED] Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] BUG at mm.c:605
Hi Alex,
Alex Williamson wrote:
I think the issue is same as reported in the below thread.
http://lists.xensource.com/archives/html/xen-ia64-devel/2006-09/msg00204.html
I tried to convince him, but failed.
I think that the best way is to revert the patch and we should seek
for the right fix.
I agree with Isaku's opinion. I think that the patch was preliminary
to avoid crash hypervisor.
Ok, should I simply revert xen-ia64-unstable cset 11636:3470d9cd27e5?
Basically, yes. But we can't avoid hypervisor crash during domain
destruction.
I think to modify above patch to remove VT-i domain checker like
attaced patch, until we will success to seek for the right fix.
Thanks
- Tsunehisa Doi
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 29cae9cfc9e5b8d1893dc67fc455f5fedb323805
# Parent da717c160155a99c90e91049400ef32bff2a579f
Preliminary fix to avoid hypervisor crash during domain destruction
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r da717c160155 -r 29cae9cfc9e5 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.cWed Oct 18 15:27:08 2006 +0900
+++ b/xen/arch/ia64/xen/mm.cWed Oct 18 15:33:53 2006 +0900
@@ -399,11 +399,10 @@ gmfn_to_mfn_foreign(struct domain *d, un
unsigned long pte;
// This function may be called from __gnttab_copy()
- // during destruction of VT-i domain with PV-on-HVM driver.
+ // during domain destruction with VNIF copy receiver.
// ** FIXME: This is not SMP-safe yet about p2m table. **
if (unlikely(d-arch.mm.pgd == NULL)) {
- if (VMX_DOMAIN(d-vcpu[0]))
- return INVALID_MFN;
+ return INVALID_MFN;
}
pte = lookup_domain_mpa(d,gpfn PAGE_SHIFT, NULL);
if (!pte) {
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Please try PV-on-HVM on IPF
] On Behalf Of DOI Tsunehisa Sent: 2006$BDj(B10$BTB(B16$BHU(B 20:31 To: xen-ia64-devel Subject: [Xen-ia64-devel] Please try PV-on-HVM on IPF Hi all, We've ported PV-on-HVM drivers for IPF. But I think that only few tries it. Thus, I try to describe to use it. And I attach several patches about PV-on-HVM. + fix-warning.patch - warning fix for HVM PV driver + notsafe-comment.patch - add not-SMP-safe comment about PV-on-HVM - to take Isaku's suggestion. + pv-backport.patch (preliminary) - current HVM PV driver for only 2.6.16 or 2.6.16.* kernel - this is preliminary patch for backporting to before 2.6.16 kernel - we tested only compiling on RHEL4. [Usage of PV-on-HVM] 1) get xen-ia64-unstable.hg tree (after cs:11805) and built it. 2) create a guest system image. - simply, install guest system on VT-i domain 3) build linux-2.6.16 kernel for guest system - get linux-2.6.16 kernel source and build 4) change guest kernel in the image to linux-2.6.16 kernel - edit config file of boot loader 5) build PV-on-HVM drivers # cd xen-ia64-unstable.hg/unmodified_drivers/linux-2.6 # sh mkbuildtree # make -C /usr/src/linux-2.6.16 M=$PWD modules 6) copy the drivers to guest system image - mount guest system image with lomount command. - copy the drivers to guest system image # cp -p */*.ko guest_system... 7) start VT-i domain 8) attach drivers domvti# insmod xen-platform-pci.ko domvti# insmod xenbus.ko domvti# insmod xen-vbd.ko domvti# insmod xen-vnif.ko 9) attach devices with xm block-attach/network-attach - this operation is same for dom-u Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Please try PV-on-HVM on IPF
You (yongkang.you) said: Does it output this trace back message when you detach vnif with xm network-detach command ? No. I didn't use above command to detach vnif. Usually I used following ways to enable vnif NIC. 1. create VTI with vif = [ '' ] 2. After VTI boot up, insert 3 related PV drivers to enable VNIF. 3. If there is a /etc/sysconfig/network-script/ifcfg-eth0, I need not do anything, VNIF eth0 will be brought up. The trace back message will happen when I just inserted vnif driver into VTI, when I used 2 NICs for VTI (1 is IOEMU, the other is VNIF). I've looked `netif_release_rx_bufs: fix me for copying receiver.' message sometimes at vnif detaching. But I've not met domain-vti crash. The crashing happened if I also use IOEMU NIC for VTI domain. The VTI vif config should like: vif = [ 'type=ioemu, bridge=xenbr0', '' ] Thanks. I'll try it. What is the guest OS vesion ? The VTI guest OS is RHEL4u3. Did you change kernel to linux-2.6.16 ? - Tsunehisa ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Please try PV-on-HVM on IPF
You (Tristan.Gingold) said: On RHEL4 U2 kernel (Linux version 2.6.9-22.EL), xen-platform-pci includes `PCI Bus :00', but it should be the leaf node, I think. To insmod xen-platform-pci, this iomem space was conflicted with the inner device, thus it can't be attached. At least RHEL4 U2 is coherent! Yes. But I do not understand where 'c200-c2000fff : PCI Bus :00' comes from. According to your lspci, there is nothing here. Maybe it was added by the ACPI table ? Thank you. I'll try to look. - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Please try PV-on-HVM on IPF
Hi all,
I (Doi.Tsunehisa) said:
We've ported PV-on-HVM drivers for IPF. But I think that
only few tries it. Thus, I try to describe to use it.
And I attach several patches about PV-on-HVM.
+ fix-warning.patch
- warning fix for HVM PV driver
+ notsafe-comment.patch
- add not-SMP-safe comment about PV-on-HVM
- to take Isaku's suggestion.
+ pv-backport.patch (preliminary)
- current HVM PV driver for only 2.6.16 or 2.6.16.* kernel
- this is preliminary patch for backporting to before 2.6.16
kernel
- we tested only compiling on RHEL4.
Today, I was testing my preliminary patch on RHEL4 U2.
But, xen-platform-pci.ko could not be attached with RHEL4 U2 original
kernel. Thus I was investigating it. So, I found a strange movement about
PCI configuration.
I tested on two envrionments, linux-2.6.16.29 and RHEL4 U2 original.
Outputs of lspci command are same on both environment.
The output is follow:
[Both environment of VT-i domain]
# lspci -v
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
Flags: fast devsel
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
Flags: medium devsel
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
(prog-if 80 [Master])
Flags: bus master, fast devsel, latency 0
I/O ports at 1100 [size=16]
00:02.0 VGA compatible controller: Cirrus Logic GD 5446 (prog-if 00 [VGA])
Flags: bus master, fast devsel, latency 0
Memory at c000 (32-bit, prefetchable) [size=32M]
Memory at c300 (32-bit, non-prefetchable) [size=4K]
00:03.0 Class ff80: Unknown device 5853:0001 (rev 01)
Flags: fast devsel
I/O ports at 1000 [disabled] [size=256]
Memory at c200 (32-bit, prefetchable) [disabled] [size=16M]
There is `Unknown device' in thie message. It's pyseudo-device for
PV-on-HVM called `xen-platform-pci'.
Next, I showed IO-memory maps with /proc/iomem. But, IO-memory maps
are different on both environment.
[linux-2.6.16.29 on VT-i domain]
# cat /proc/iomem
-0009 : System RAM
000a-000b : reserved
000c-000f : reserved
0010-03ff : System RAM
0400-04bf3fff : System RAM
0400-046d34bf : Kernel code
046d34c0-04bf373f : Kernel data
04bf4000-3c458fff : System RAM
deleted *
3ff7-3fffdfff : System RAM
3fffe000-3fff : reserved
c000-c1ff : :00:02.0
c200-c2ff : :00:03.0
c300-c3000fff : :00:02.0
e000-e033dcf7 : PCI Bus :00 I/O Ports -0cf7
e0340d00-e3ff : PCI Bus :00 I/O Ports 0d00-
[RHEL4 U2 on VT-i domain]
# cat /proc/iomem
c000-c1ff : PCI Bus :00
c000-c1ff : :00:02.0
c200-c2ff : :00:03.0
c200-c2000fff : PCI Bus :00
c300-c3000fff : :00:02.0
On RHEL4 U2 environment, I could show only this message. It's
strange, and it's the reason that xen-platform-pci.ko module can't
be attached, I think.
I don't understand what is happend. Does anyone know the reason ?
Thanks,
- Tsunehisa Doi
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Please try PV-on-HVM on IPF
Sorry, I forgot to write about my test environment. I tested with xen-ia64-unstable.hg (cs:11810). I (Doi.Tsunehisa) said: Hi all, I (Doi.Tsunehisa) said: We've ported PV-on-HVM drivers for IPF. But I think that only few tries it. Thus, I try to describe to use it. And I attach several patches about PV-on-HVM. + fix-warning.patch - warning fix for HVM PV driver + notsafe-comment.patch - add not-SMP-safe comment about PV-on-HVM - to take Isaku's suggestion. + pv-backport.patch (preliminary) - current HVM PV driver for only 2.6.16 or 2.6.16.* kernel - this is preliminary patch for backporting to before 2.6.16 kernel - we tested only compiling on RHEL4. Today, I was testing my preliminary patch on RHEL4 U2. But, xen-platform-pci.ko could not be attached with RHEL4 U2 original kernel. Thus I was investigating it. So, I found a strange movement about PCI configuration. I tested on two envrionments, linux-2.6.16.29 and RHEL4 U2 original. Outputs of lspci command are same on both environment. The output is follow: [Both environment of VT-i domain] # lspci -v 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) Flags: fast devsel 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II ] Flags: medium devsel 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] (prog-if 80 [Master]) Flags: bus master, fast devsel, latency 0 I/O ports at 1100 [size=16] 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 (prog-if 00 [VGA] ) Flags: bus master, fast devsel, latency 0 Memory at c000 (32-bit, prefetchable) [size=32M] Memory at c300 (32-bit, non-prefetchable) [size=4K] 00:03.0 Class ff80: Unknown device 5853:0001 (rev 01) Flags: fast devsel I/O ports at 1000 [disabled] [size=256] Memory at c200 (32-bit, prefetchable) [disabled] [siz e=16M] There is `Unknown device' in thie message. It's pyseudo-device for PV-on-HVM called `xen-platform-pci'. Next, I showed IO-memory maps with /proc/iomem. But, IO-memory maps are different on both environment. [linux-2.6.16.29 on VT-i domain] # cat /proc/iomem -0009 : System RAM 000a-000b : reserved 000c-000f : reserved 0010-03ff : System RAM 0400-04bf3fff : System RAM 0400-046d34bf : Kernel code 046d34c0-04bf373f : Kernel data 04bf4000-3c458fff : System RAM deleted * 3ff7-3fffdfff : System RAM 3fffe000-3fff : reserved c000-c1ff : :00:02.0 c200-c2ff : :00:03.0 c300-c3000fff : :00:02.0 e000-e033dcf7 : PCI Bus :00 I/O Ports -0cf7 e0340d00-e3ff : PCI Bus :00 I/O Ports 0d00- [RHEL4 U2 on VT-i domain] # cat /proc/iomem c000-c1ff : PCI Bus :00 c000-c1ff : :00:02.0 c200-c2ff : :00:03.0 c200-c2000fff : PCI Bus :00 c300-c3000fff : :00:02.0 On RHEL4 U2 environment, I could show only this message. It's strange, and it's the reason that xen-platform-pci.ko module can't be attached, I think. I don't understand what is happend. Does anyone know the reason ? Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Please try PV-on-HVM on IPF
Hi Tristan,
Thank you for your comment.
You (Tristan.Gingold) said:
[linux-2.6.16.29 on VT-i domain]
# cat /proc/iomem
-0009 : System RAM
000a-000b : reserved
000c-000f : reserved
0010-03ff : System RAM
0400-04bf3fff : System RAM
0400-046d34bf : Kernel code
046d34c0-04bf373f : Kernel data
04bf4000-3c458fff : System RAM
deleted *
3ff7-3fffdfff : System RAM
3fffe000-3fff : reserved
c000-c1ff : :00:02.0
c200-c2ff : :00:03.0
c300-c3000fff : :00:02.0
e000-e033dcf7 : PCI Bus :00 I/O Ports -0cf7
e0340d00-e3ff : PCI Bus :00 I/O Ports 0d00-
[RHEL4 U2 on VT-i domain]
# cat /proc/iomem
c000-c1ff : PCI Bus :00
c000-c1ff : :00:02.0
c200-c2ff : :00:03.0
c200-c2000fff : PCI Bus :00
c300-c3000fff : :00:02.0
On RHEL4 U2 environment, I could show only this message. It's
strange, and it's the reason that xen-platform-pci.ko module can't
be attached, I think.
I don't understand what is happend. Does anyone know the reason ?
I do not really understand what is strange for you.
The output is not the same but:
* it may be due to kernel version
* the xen pseudo device appears in both version.
I think that the diffence are noticed..
[linux-2.6.16.29 on VT-i domain]
c200-c2ff : :00:03.0
[RHEL4 U2 on VT-i domain]
c200-c2ff : :00:03.0
c200-c2000fff : PCI Bus :00
On RHEL4 U2 kernel (Linux version 2.6.9-22.EL), xen-platform-pci
includes `PCI Bus :00', but it should be the leaf node, I think.
To insmod xen-platform-pci, this iomem space was conflicted with
the inner device, thus it can't be attached.
What is the error message when you try to insmod xen-platform-pci ?
Have you ever succeed to insmod it in RHEL 4 ?
I've never succeeded to insmod it in RHEL 4 original kernel.
The error message is follows:
# insmod xen-platform-pci.ko
PCI: Enabling device :00:03.0 (0010 - 0013)
:MEM I/O resource 0xc200 @ 0x100 busy
xen-platform-pci: probe of :00:03.0 failed with error -16
This message is outputted from follow codes:
[unmodified_drivers/linux-2.6/platform-pci/platform-pci.c] 202
181 static int __devinit platform_pci_init(struct pci_dev *pdev,
182 const struct pci_device_id *ent)
183 {
184 int i, ret;
185 long ioaddr, iolen;
186 long mmio_addr, mmio_len;
187
...
202
203 if (request_mem_region(mmio_addr, mmio_len, DRV_NAME) == NULL)
204 {
205 printk(KERN_ERR :MEM I/O resource 0x%lx @ 0x%lx
busy\n,
206 mmio_addr, mmio_len);
207 return -EBUSY;
208 }
I've tried to insert checking code before request_mem_region()
to show the resource tree. So, I found the reason that it can't be
attaced.
- Tsunehisa Doi
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] BUG at mm.c:605
Hi,
You (yamahata) said:
I think the issue is same as reported in the below thread.
http://lists.xensource.com/archives/html/xen-ia64-devel/2006-09/msg00204.html
I tried to convince him, but failed.
I think that the best way is to revert the patch and we should seek
for the right fix.
I agree with Isaku's opinion. I think that the patch was preliminary
to avoid crash hypervisor.
I guess that making xennet.rx_copy default enabled is the beginning.
The root cause is that relinquish_memory() writes the P2M simulteniously
with __acquire_grant_for_copy().
I think so.
relinquish_memory() of IA64 assumes that no one else read the P2M
table at the same time. However the such assumption is wrong now.
In my investigation, it was right the assumption before shadow2 on
x86. But shadow2 changed it. In shadow2 code, the P2M table destruction
was moved from domain_kill phase to domain_destroy() phase. I guess
that the spec change is for VNIF copy receiver indeed.
Although I haven't dug into its details, I suspect that
the race between relinquish_memory() and get_page()
(or __acquire_grant_for_copy()) exists not only on ia64,
but also on x86.
Before shadow2 age, the P2M table can be destructed in
domain_relinquish_resource(), because gnttab_release_mapping() releases
P2M table referencing concerned with grant table.
203 void domain_kill(struct domain *d)
204 {
205 domain_pause(d);
206
207 if ( test_and_set_bit(_DOMF_dying, d-domain_flags) )
208 return;
209
210 gnttab_release_mappings(d);
211 domain_relinquish_resources(d);
212 put_domain(d);
213
214 send_guest_global_virq(dom0, VIRQ_DOM_EXC);
215 }
But after the copy receiver of VNIF intruduction,
gnttab_release_mapping() became not to be able to release to reference
P2M table. Thus, shadow2 introduced `delayed destruction of P2M table',
I think.
I'm afraid that P2M table may be available after the page body
releasing in shadow2. But I've not spend to investigate this issue.
Thanks
- Tsunehisa Doi
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Please try PV-on-HVM on IPF
Hi all,
We've ported PV-on-HVM drivers for IPF. But I think that
only few tries it. Thus, I try to describe to use it.
And I attach several patches about PV-on-HVM.
+ fix-warning.patch
- warning fix for HVM PV driver
+ notsafe-comment.patch
- add not-SMP-safe comment about PV-on-HVM
- to take Isaku's suggestion.
+ pv-backport.patch (preliminary)
- current HVM PV driver for only 2.6.16 or 2.6.16.* kernel
- this is preliminary patch for backporting to before 2.6.16
kernel
- we tested only compiling on RHEL4.
[Usage of PV-on-HVM]
1) get xen-ia64-unstable.hg tree (after cs:11805) and built it.
2) create a guest system image.
- simply, install guest system on VT-i domain
3) build linux-2.6.16 kernel for guest system
- get linux-2.6.16 kernel source and build
4) change guest kernel in the image to linux-2.6.16 kernel
- edit config file of boot loader
5) build PV-on-HVM drivers
# cd xen-ia64-unstable.hg/unmodified_drivers/linux-2.6
# sh mkbuildtree
# make -C /usr/src/linux-2.6.16 M=$PWD modules
6) copy the drivers to guest system image
- mount guest system image with lomount command.
- copy the drivers to guest system image
# cp -p */*.ko guest_system...
7) start VT-i domain
8) attach drivers
domvti# insmod xen-platform-pci.ko
domvti# insmod xenbus.ko
domvti# insmod xen-vbd.ko
domvti# insmod xen-vnif.ko
9) attach devices with xm block-attach/network-attach
- this operation is same for dom-u
Thanks,
- Tsunehisa Doi
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 199aa46b3aa2bd3e9e684344e000d4ad40177541
# Parent bf0a6f241c5eb7bea8b178b490ed32178c7b5bff
warning fix for HVM PV driver
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r bf0a6f241c5e -r 199aa46b3aa2
linux-2.6-xen-sparse/arch/ia64/xen/xencomm.c
--- a/linux-2.6-xen-sparse/arch/ia64/xen/xencomm.c Mon Oct 16 20:00:12
2006 +0900
+++ b/linux-2.6-xen-sparse/arch/ia64/xen/xencomm.c Mon Oct 16 20:20:16
2006 +0900
@@ -36,8 +36,10 @@ unsigned long
unsigned long
xencomm_vaddr_to_paddr(unsigned long vaddr)
{
+#ifndef CONFIG_VMX_GUEST
struct page *page;
struct vm_area_struct *vma;
+#endif
if (vaddr == 0)
return 0;
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID bf0a6f241c5eb7bea8b178b490ed32178c7b5bff
# Parent fcd746cf4647e06b8e88e620c29610ba43e3ad7c
Add not-SMP-safe comment about PV-on-HVM
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r fcd746cf4647 -r bf0a6f241c5e xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.cSat Oct 14 18:10:08 2006 -0600
+++ b/xen/arch/ia64/xen/mm.cMon Oct 16 20:00:12 2006 +0900
@@ -400,6 +400,7 @@ gmfn_to_mfn_foreign(struct domain *d, un
// This function may be called from __gnttab_copy()
// during destruction of VT-i domain with PV-on-HVM driver.
+ // ** FIXME: This is not SMP-safe yet about p2m table. **
if (unlikely(d-arch.mm.pgd == NULL)) {
if (VMX_DOMAIN(d-vcpu[0]))
return INVALID_MFN;
diff -r fcd746cf4647 -r bf0a6f241c5e xen/arch/ia64/xen/vhpt.c
--- a/xen/arch/ia64/xen/vhpt.c Sat Oct 14 18:10:08 2006 -0600
+++ b/xen/arch/ia64/xen/vhpt.c Mon Oct 16 20:00:12 2006 +0900
@@ -216,6 +216,7 @@ void vcpu_flush_vtlb_all(struct vcpu *v)
grant_table share page from guest_physmap_remove_page()
in arch_memory_op() XENMEM_add_to_physmap to realize
PV-on-HVM feature. */
+ /* FIXME: This is not SMP-safe yet about p2m table */
/* Purge vTLB for VT-i domain */
thash_purge_all(v);
}
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 7089d11a9e0b723079c83697c529970d7b3b0750
# Parent 199aa46b3aa2bd3e9e684344e000d4ad40177541
Modify for PV-on-HVM backport
diff -r 199aa46b3aa2 -r 7089d11a9e0b
linux-2.6-xen-sparse/arch/ia64/xen/xencomm.c
--- a/linux-2.6-xen-sparse/arch/ia64/xen/xencomm.c Mon Oct 16 20:20:16
2006 +0900
+++ b/linux-2.6-xen-sparse/arch/ia64/xen/xencomm.c Mon Oct 16 20:21:40
2006 +0900
@@ -22,6 +22,10 @@
#include asm/page.h
#include asm/xen/xencomm.h
+#ifdef HAVE_COMPAT_H
+#include compat.h
+#endif
+
static int xencomm_debug = 0;
static unsigned long kernel_start_pa;
diff -r 199aa46b3aa2 -r 7089d11a9e0b
linux-2.6-xen-sparse/drivers/xen/blkfront/blkfront.c
--- a/linux-2.6-xen-sparse/drivers/xen/blkfront/blkfront.c Mon Oct 16
20:20:16 2006 +0900
+++ b/linux-2.6-xen-sparse/drivers/xen/blkfront/blkfront.c Mon Oct 16
20:21:40 2006 +0900
@@ -48,6 +48,10 @@
#include asm/hypervisor.h
#include asm/maddr.h
+#ifdef HAVE_COMPAT_H
+#include compat.h
+#endif
+
#define BLKIF_STATE_DISCONNECTED 0
#define BLKIF_STATE_CONNECTED1
#define BLKIF_STATE_SUSPENDED2
@@ -468,6 +472,27 @@ int blkif_ioctl(struct inode *inode, str
command, (long)argument,
Re: [Xen-ia64-devel] Patch for PV-on-HVM for IPF
You (yamahata) said: It might take a while for you to fix it. Can you add comments to mark them until fix? e.g. XXX not-SMP-safe. Sorry. I can't spend for the issue, now. Could you add them ? Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Patch for PV-on-HVM for IPF
You (yamahata) said: Although I haven't dug into its details, I want to check my suspicion. The relinquishing mm code assumes that there's no racy reference. So your patch seems too easy and not-SMP-safe to me. For example, mm-pgd isn't protected. What do you think? You are right. Hypervisor may crash in gnttab_copy code during p2m table destruction in relinquish_mm code. At least, mm-pgd should be nullify before destruction of the body of p2m table. I'll investigate it. BTW, I suppose that you also have the another SMP issue related to PV-on-HVM. What's going on it? Sorry, I could not spend to investigate this issue in last few weeks. Could you help me ? Thanks, - Doi Tsunehisa ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Patch for PV-on-HVM for IPF
You (yamahata) said: Although I haven't dug into its details, I want to check my suspicion. The relinquishing mm code assumes that there's no racy reference. So your patch seems too easy and not-SMP-safe to me. For example, mm-pgd isn't protected. What do you think? You are right. Hypervisor may crash in gnttab_copy code during p2m table destruction in relinquish_mm code. At least, mm-pgd should be nullify before destruction of the body of p2m table. I'll investigate it. Simple setting NULL to mm-pgd before the p2m destruction isn't SMP-safe again. I think so. I'll study more. Another cpu might see the p2m destruction and mm-pgd != NULL. Be carefull of memory ordering. Thank for your comment. - Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] xencomm_privcmd_sched_op
Hi Tristan, You (Tristan.Gingold) said: Do you want me to implement them ? Yes, I hope to I've attached the log of compiling PV-on-HVM driver, and my modification for compiling them. Hi, here is my patch. xen_vnif seems to work. Can you try and confirm ? Have you ever tested xen_vbd ? Thank you !! I have tried and confirmed that vbd and vnif work normaly. Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] xencomm_privcmd_sched_op
Hi Tristan, You (Tristan.Gingold) said: Tristan seems to have forgotten to implement xencomm_privcmd_sched_op(). When I tried to reboot a VTI domain, I got the dom0's message privcmd_hypercall: unknown hcall (29) and couldn't reboot. Thank you for filling the holes. I may have forgotten other hypercalls... Did you try PV drivers on HVM ? I'm trying to build PV drivers on HVM, but I don't success it. I have modified the build rule and some files, but some hypercall seem to be unimplemented. like xencomm_mini_hypercall_hvm_op, xencomm_mini_hypercall_xen_version. Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Bind event channel of VT-i domain to vcpu 0
Hi all,
In x86 code, it was fixed about PV-on-HVM event channel in
xen-unstable.hg(cs:11698).
I fixed with same logic in IPF code.
* bind-evtchn.patch
+ bind event channels of VT-i domain to vcpu 0.
I tested that PV-on-HVM works.
Thanks,
- Tsunehisa Doi
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 124ef96ccd1db218e798514bd306a5a727462a47
# Parent 2bfd19fc1b79c6a6712c99f875f1fbf883af3f35
Bind event channels of VT-i domain to vcpu 0
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
diff -r 2bfd19fc1b79 -r 124ef96ccd1d xen/arch/ia64/vmx/vmx_process.c
--- a/xen/arch/ia64/vmx/vmx_process.c Sun Oct 01 19:10:18 2006 -0600
+++ b/xen/arch/ia64/vmx/vmx_process.c Mon Oct 02 20:30:53 2006 +0900
@@ -198,7 +198,7 @@ void leave_hypervisor_tail(struct pt_reg
{
struct domain *d = current-domain;
struct vcpu *v = current;
-int callback_irq;
+
// FIXME: Will this work properly if doing an RFI???
if (!is_idle_domain(d) ) { // always comes from guest
//struct pt_regs *user_regs = vcpu_regs(current);
@@ -226,11 +226,14 @@ void leave_hypervisor_tail(struct pt_reg
// v-arch.irq_new_pending = 1;
// }
-callback_irq = d-arch.hvm_domain.params[HVM_PARAM_CALLBACK_IRQ];
-if (callback_irq != 0 local_events_need_delivery()) {
-/*inject para-device call back irq*/
-v-vcpu_info-evtchn_upcall_mask = 1;
-vmx_vcpu_pend_interrupt(v, callback_irq);
+if (v-vcpu_id == 0) {
+int callback_irq =
+d-arch.hvm_domain.params[HVM_PARAM_CALLBACK_IRQ];
+if (callback_irq != 0 local_events_need_delivery()) {
+/*inject para-device call back irq*/
+v-vcpu_info-evtchn_upcall_mask = 1;
+vmx_vcpu_pend_interrupt(v, callback_irq);
+}
}
if ( v-arch.irq_new_pending ) {
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Patch for PV-on-HVM for IPF
Hi all, Currently, we are testing PV-on-HVM driver for IPF. so, we found a problem that hypervisor crashes during VT-i domain destruction with PV-on-HVM driver. The procedure to reproduce this problem are: * Create a VT-i domain. [dom0]# xm create -f hvm.conf * Insert modules for PV-on-HVM on the domain. [domvti]# insmod xen-platform-pci.ko [domvti]# insmod xenbus.ko [domvti]# insmod xen-vbd.ko [domvti]# insmod xen-vnif.ko * Activate VNIF network interface. [dom0]# xm network-attach domid eth1 [domvti]# ifconfig eth1 up * Destruct the domain [dom0]# xm destroy domid . hypervisor crash We were investigating the hypervisor crash mechanism, thus we found a reason of it. * VNIF of PV-on-HVM uses gnttab_copy() function. - it's used for copy-method of VNIF backend. - it needs to refer p2m table. * gnttab_copy() function may be called during the domain destruction. - it's called by dom0 VNIF backend. * Hypervisor invalidates p2m table at first during the destruction. - gnttab_copy() won't be able to refer p2m table, thus it occurs hypervisor crash. - In x86 code, p2m table invalidation is delayed at last phase of domain destruction. = but we don't like it. it seems that p2m table exists after memory relinquised. So, I'll post a patch to avoid hypervisor crash. * pv-avoid-crash.patch + modify p2m table converter (gmfn_to_mfn_foreign()) - return INVALID_MFN during VT-i domain destruction We tested that the problem is solved. Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Patch for PV-on-HVM for IPF
Sorry, I forgot to attach the patch.
DOI Tsunehisa wrote:
Hi all,
Currently, we are testing PV-on-HVM driver for IPF. so, we found
a problem that hypervisor crashes during VT-i domain destruction
with PV-on-HVM driver.
The procedure to reproduce this problem are:
* Create a VT-i domain.
[dom0]# xm create -f hvm.conf
* Insert modules for PV-on-HVM on the domain.
[domvti]# insmod xen-platform-pci.ko
[domvti]# insmod xenbus.ko
[domvti]# insmod xen-vbd.ko
[domvti]# insmod xen-vnif.ko
* Activate VNIF network interface.
[dom0]# xm network-attach domid eth1
[domvti]# ifconfig eth1 up
* Destruct the domain
[dom0]# xm destroy domid
. hypervisor crash
We were investigating the hypervisor crash mechanism, thus we found
a reason of it.
* VNIF of PV-on-HVM uses gnttab_copy() function.
- it's used for copy-method of VNIF backend.
- it needs to refer p2m table.
* gnttab_copy() function may be called during the domain destruction.
- it's called by dom0 VNIF backend.
* Hypervisor invalidates p2m table at first during the destruction.
- gnttab_copy() won't be able to refer p2m table, thus it occurs
hypervisor crash.
- In x86 code, p2m table invalidation is delayed at last phase of
domain destruction.
= but we don't like it. it seems that p2m table exists after
memory relinquised.
So, I'll post a patch to avoid hypervisor crash.
* pv-avoid-crash.patch
+ modify p2m table converter (gmfn_to_mfn_foreign())
- return INVALID_MFN during VT-i domain destruction
We tested that the problem is solved.
Thanks,
- Tsunehisa Doi
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 354f40902eb9e3f92fdf8b5e9268052cd955230b
# Parent f34e37d0742d80ccfefd017a91f93310ebc2dfe8
Modify p2m converter to avoid hypervisor crash
during destruction of VT-i domain with PV-on-HVM.
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
Signed-off-by: Tomonari Horikoshi [EMAIL PROTECTED]
diff -r f34e37d0742d -r 354f40902eb9 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.cTue Sep 26 19:11:33 2006 -0600
+++ b/xen/arch/ia64/xen/mm.cWed Sep 27 17:24:58 2006 +0900
@@ -396,6 +396,12 @@ gmfn_to_mfn_foreign(struct domain *d, un
{
unsigned long pte;
+ // This function may be called from __gnttab_copy()
+ // during destruction of VT-i domain with PV-on-HVM driver.
+ if (unlikely(d-arch.mm.pgd == NULL)) {
+ if (VMX_DOMAIN(d-vcpu[0]))
+ return INVALID_MFN;
+ }
pte = lookup_domain_mpa(d,gpfn PAGE_SHIFT, NULL);
if (!pte) {
panic(gmfn_to_mfn_foreign: bad gpfn. spinning...\n);
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Patch for PV-on-HVM for IPF
You (yamahata) said: On Wed, Sep 27, 2006 at 06:44:27PM +0900, DOI Tsunehisa wrote: - In x86 code, p2m table invalidation is delayed at last phase of domain destruction. = but we don't like it. it seems that p2m table exists after memory relinquised. What's the problem? I don't see why. In x86 code, it checks ownership of pages before actual memcpy() in gnttab_copy() function. thus it doesn't have any problem actually. But, it's strange that referencer exists although referencee doesn't exist, I think. Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Patch for PV-on-HVM for IPF
You (yamahata) said: - In x86 code, p2m table invalidation is delayed at last phase of domain destruction. = but we don't like it. it seems that p2m table exists after memory relinquised. What's the problem? I don't see why. In x86 code, it checks ownership of pages before actual memcpy() in gnttab_copy() function. thus it doesn't have any problem actually. But, it's strange that referencer exists although referencee doesn't exist, I think. So it's what you should fix, I'm not sure what you described though. I will investigate it in x86 code more, and ask it to x86 community. -- ÅÚÈî¤Ç¤·¤¿¡¥¡¥¡¥ ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Cleanup for PV-on-HVM for IPF
Hi Alex, Please import xen-unstable.hg(cs:11464:3bff5c5b9206) for enabling PV-on-HVM for IPF. changeset: 11464:3bff5c5b9206 user:[EMAIL PROTECTED] date:Wed Sep 13 14:34:34 2006 +0100 summary: Fix unmodified drivers for PV-on-HVM on IA64. Thanks, - Tsunehisa ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] please pull xen-ia64-unstable.hg
Hi,
Alex Williamson wrote:
This includes a fairly small number of changesets that I'd like to get
in before 3.0.3. Changes include: finishing the PV-on-HVM driver
support for ia64, fix an error when an FPSWA interface is not installed,
add a few EFI calls to support hwclock, add some more perfc counters,
and fix ia64 HVM domain creation. Thanks,
Please apply these patches, also.
These patches are needed to be enabling the PV-on-HVM driver for IPF.
* cutoff.patch
+ cut off unused codes for IA64
- get_hypercall_stabs() is x86 specific function. We don't use
it, and it occurrs compile error on ia64 platform.
Thus it is cut off.
* build.patch
+ modify build rule for IA64
- This patch appends a build rule for ia64 platform to
mkbuildtree command.
They are same with the patches posted last week, except that they are
based on current tree. (xen-unstable.hg(cs:11440))
Thanks,
- Tsunehisa Doi
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 1701214917e68a271f19a1a528b68253bbfab3b4
# Parent bfd00b317815f2d1c8989b55a4cfd174da043e43
Modify platform-pci for PV-on-HVM on IA64
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
Signed-off-by: Tomonari Horikoshi [EMAIL PROTECTED]
diff -r bfd00b317815 -r 1701214917e6
unmodified_drivers/linux-2.6/platform-pci/platform-pci.c
--- a/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c Mon Sep 11
01:55:03 2006 +0100
+++ b/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c Tue Sep 12
16:24:14 2006 +0900
@@ -117,6 +117,7 @@ unsigned long alloc_xen_mmio(unsigned lo
return addr;
}
+#ifndef __ia64__
/* Lifted from hvmloader.c */
static int get_hypercall_stubs(void)
{
@@ -162,6 +163,7 @@ static int get_hypercall_stubs(void)
return 0;
}
+#endif /* !__ia64__ */
static int __devinit platform_pci_init(struct pci_dev *pdev,
const struct pci_device_id *ent)
@@ -203,10 +205,12 @@ static int __devinit platform_pci_init(s
platform_mmio = mmio_addr;
platform_mmiolen = mmio_len;
+#ifndef __ia64__
ret = get_hypercall_stubs();
if (ret 0)
goto out;
+#endif /* __ia64__ */
if ((ret = init_xen_info()))
goto out;
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 2d7aa6bd24ba5bf832bac948539803f046b3981d
# Parent 1701214917e68a271f19a1a528b68253bbfab3b4
Modify build rule for PV-on-HVM on IA64
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
Signed-off-by: Tomonari Horikoshi [EMAIL PROTECTED]
diff -r 1701214917e6 -r 2d7aa6bd24ba unmodified_drivers/linux-2.6/mkbuildtree
--- a/unmodified_drivers/linux-2.6/mkbuildtree Tue Sep 12 16:24:14 2006 +0900
+++ b/unmodified_drivers/linux-2.6/mkbuildtree Tue Sep 12 16:25:30 2006 +0900
@@ -42,6 +42,12 @@ i[34567]86)
ln -sf ${XL}/include/asm-i386/mach-xen/asm/synch_bitops.h include/asm
ln -sf ${XL}/include/asm-i386/mach-xen/asm/maddr.h include/asm
;;
+ia64)
+ ln -sf ${XL}/include/asm-ia64/hypervisor.h include/asm
+ ln -sf ${XL}/include/asm-ia64/hypercall.h include/asm
+ ln -sf ${XL}/include/asm-ia64/synch_bitops.h include/asm
+ ln -sf ${XL}/include/asm-ia64/maddr.h include/asm
+ ;;
*)
echo unknown architecture $uname
exit 1
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PV-on-HVM for IPF (take 3)
Hi. You (yamahata) said: Your patch isn't SMP-safe. domVTi code assumes that the p2m table is build at the domain creation and read-only after that. However your patch breaks the assumption and opened the door to SMP world. Especially you must resolve the race between tlb insert and tlb purge. Do you have any plan to fix it? I had recognized this problem. It shall be fixed refer to domU codes, I think. But I think that it is rare case normaly, because the effect of it occurs in a phase of guest initialization. Currently, we are studying a way to fix it, whitch don't affect to performance and code structures. Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Cleanup for PV-on-HVM for IPF
Hi all,
I will post patche for PV-on-HVM on ia64 platform to cleanup for
common code modification minimized.
These patch include:
* cleanup.patch
- ia64_xenmem_reservation_op() and is_running_on_xen() are
macro-nize if CONFIG_VMX_GUEST is defined.
- xen_machphys_update() is funcition-ize if CONFIG_VMX_GUEST
is defined.
We have tested compiling.
Thanks,
- Tsunehisa Doi
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 4a17792e0a5a05caad68244abfe09948a6f2d90d
# Parent 1bab7d65171b762bb3cf1ae426bc6c403f847ebf
Cleanup for PV-on-HVM on IPF
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
Signed-off-by: Tomonari Horikoshi [EMAIL PROTECTED]
diff -r 1bab7d65171b -r 4a17792e0a5a
linux-2.6-xen-sparse/include/asm-ia64/hypercall.h
--- a/linux-2.6-xen-sparse/include/asm-ia64/hypercall.h Fri Sep 01 13:04:02
2006 -0600
+++ b/linux-2.6-xen-sparse/include/asm-ia64/hypercall.h Mon Sep 04 16:04:27
2006 +0900
@@ -205,8 +205,12 @@ HYPERVISOR_memory_op(
}
#include xen/interface/memory.h
+#ifdef CONFIG_VMX_GUEST
+# define ia64_xenmem_reservation_op(op, xmr) (0)
+#else /* CONFIG_VMX_GUEST */
int ia64_xenmem_reservation_op(unsigned long op,
struct xen_memory_reservation* reservation__);
+#endif /* CONFIG_XEN_HVM_GUEST */
static inline int
HYPERVISOR_memory_op(
unsigned int cmd, void *arg)
diff -r 1bab7d65171b -r 4a17792e0a5a
linux-2.6-xen-sparse/include/asm-ia64/hypervisor.h
--- a/linux-2.6-xen-sparse/include/asm-ia64/hypervisor.hFri Sep 01
13:04:02 2006 -0600
+++ b/linux-2.6-xen-sparse/include/asm-ia64/hypervisor.hMon Sep 04
16:04:27 2006 +0900
@@ -33,13 +33,17 @@
#ifndef __HYPERVISOR_H__
#define __HYPERVISOR_H__
-#if !defined(CONFIG_XEN) !defined(CONFIG_VMX_GUEST)
-#define is_running_on_xen()(0)
-#define HYPERVISOR_ioremap(offset, size) (offset)
-#else
+#ifdef CONFIG_XEN
extern int running_on_xen;
#define is_running_on_xen()(running_on_xen)
-#endif
+#else /* CONFIG_XEN */
+# ifdef CONFIG_VMX_GUEST
+# define is_running_on_xen() (1)
+# else /* CONFIG_VMX_GUEST */
+# define is_running_on_xen() (0)
+# define HYPERVISOR_ioremap(offset, size) (offset)
+# endif /* CONFIG_VMX_GUEST */
+#endif /* CONFIG_XEN */
#if defined(CONFIG_XEN) || defined(CONFIG_VMX_GUEST)
#include linux/config.h
diff -r 1bab7d65171b -r 4a17792e0a5a
linux-2.6-xen-sparse/include/asm-ia64/maddr.h
--- a/linux-2.6-xen-sparse/include/asm-ia64/maddr.h Fri Sep 01 13:04:02
2006 -0600
+++ b/linux-2.6-xen-sparse/include/asm-ia64/maddr.h Mon Sep 04 16:04:27
2006 +0900
@@ -60,6 +60,8 @@ mfn_to_local_pfn(unsigned long mfn)
return pfn;
}
+#define xen_machphys_update(mfn, pfn) do { } while (0)
+
#else /* !CONFIG_XEN */
#define pfn_to_mfn_for_dma(pfn) (pfn)
@@ -67,6 +69,8 @@ mfn_to_local_pfn(unsigned long mfn)
#define phys_to_machine_for_dma(phys) (phys)
#define machine_to_phys_for_dma(machine) (machine)
#define mfn_to_local_pfn(mfn) (mfn)
+
+extern void xen_machphys_update(unsigned long mfn, unsigned long pfn);
#endif /* !CONFIG_XEN */
@@ -81,7 +85,6 @@ mfn_to_local_pfn(unsigned long mfn)
#define virt_to_machine(virt) __pa(virt) // for tpmfront.c
#define set_phys_to_machine(pfn, mfn) do { } while (0)
-#define xen_machphys_update(mfn, pfn) do { } while (0)
typedef unsigned long maddr_t; // to compile netback, netfront
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Cleanup for PV-on-HVM for IPF
Hi,
Thank you for your comment.
Alex Williamson wrote:
On Mon, 2006-09-04 at 16:57 +0900, DOI Tsunehisa wrote:
#include xen/interface/memory.h
+#ifdef CONFIG_VMX_GUEST
+# define ia64_xenmem_reservation_op(op, xmr) (0)
+#else /* CONFIG_VMX_GUEST */
int ia64_xenmem_reservation_op(unsigned long op,
struct xen_memory_reservation* reservation__);
+#endif /* CONFIG_XEN_HVM_GUEST */
Typo, CONFIG_XEN_HVM_GUEST? Personally I'd leave out the comment
next to the #else and #endif for such a short block of code.
Yes, it's typo. And I have removed the comment.
#define pfn_to_mfn_for_dma(pfn) (pfn)
@@ -67,6 +69,8 @@ mfn_to_local_pfn(unsigned long mfn)
#define phys_to_machine_for_dma(phys) (phys)
#define machine_to_phys_for_dma(machine) (machine)
#define mfn_to_local_pfn(mfn) (mfn)
+
+extern void xen_machphys_update(unsigned long mfn, unsigned long pfn);
Isn't this going to be bad for the !CONFIG_XEN !CONFIG_VMX_GUEST
case? I think we still want the old empty definition then. Thanks,
I agree. I have modified it.
Thanks,
- Tsunehisa Doi
Cleanup for PV-on-HVM on IPF
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
Signed-off-by: Tomonari Horikoshi [EMAIL PROTECTED]
diff -r 1bab7d65171b linux-2.6-xen-sparse/include/asm-ia64/hypercall.h
--- a/linux-2.6-xen-sparse/include/asm-ia64/hypercall.h Fri Sep 01 13:04:02
2006 -0600
+++ b/linux-2.6-xen-sparse/include/asm-ia64/hypercall.h Tue Sep 05 08:13:57
2006 +0900
@@ -205,8 +205,12 @@ HYPERVISOR_memory_op(
}
#include xen/interface/memory.h
+#ifdef CONFIG_VMX_GUEST
+# define ia64_xenmem_reservation_op(op, xmr) (0)
+#else
int ia64_xenmem_reservation_op(unsigned long op,
struct xen_memory_reservation* reservation__);
+#endif
static inline int
HYPERVISOR_memory_op(
unsigned int cmd, void *arg)
diff -r 1bab7d65171b linux-2.6-xen-sparse/include/asm-ia64/hypervisor.h
--- a/linux-2.6-xen-sparse/include/asm-ia64/hypervisor.hFri Sep 01
13:04:02 2006 -0600
+++ b/linux-2.6-xen-sparse/include/asm-ia64/hypervisor.hTue Sep 05
08:13:57 2006 +0900
@@ -33,13 +33,17 @@
#ifndef __HYPERVISOR_H__
#define __HYPERVISOR_H__
-#if !defined(CONFIG_XEN) !defined(CONFIG_VMX_GUEST)
-#define is_running_on_xen()(0)
-#define HYPERVISOR_ioremap(offset, size) (offset)
-#else
+#ifdef CONFIG_XEN
extern int running_on_xen;
#define is_running_on_xen()(running_on_xen)
-#endif
+#else /* CONFIG_XEN */
+# ifdef CONFIG_VMX_GUEST
+# define is_running_on_xen() (1)
+# else /* CONFIG_VMX_GUEST */
+# define is_running_on_xen() (0)
+# define HYPERVISOR_ioremap(offset, size) (offset)
+# endif /* CONFIG_VMX_GUEST */
+#endif /* CONFIG_XEN */
#if defined(CONFIG_XEN) || defined(CONFIG_VMX_GUEST)
#include linux/config.h
diff -r 1bab7d65171b linux-2.6-xen-sparse/include/asm-ia64/maddr.h
--- a/linux-2.6-xen-sparse/include/asm-ia64/maddr.h Fri Sep 01 13:04:02
2006 -0600
+++ b/linux-2.6-xen-sparse/include/asm-ia64/maddr.h Tue Sep 05 08:13:57
2006 +0900
@@ -81,7 +81,11 @@ mfn_to_local_pfn(unsigned long mfn)
#define virt_to_machine(virt) __pa(virt) // for tpmfront.c
#define set_phys_to_machine(pfn, mfn) do { } while (0)
+#ifdef CONFIG_VMX_GUEST
+extern void xen_machphys_update(unsigned long mfn, unsigned long pfn);
+#else /* CONFIG_VMX_GUEST */
#define xen_machphys_update(mfn, pfn) do { } while (0)
+#endif /* CONFIG_VMX_GUEST */
typedef unsigned long maddr_t; // to compile netback, netfront
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PV-on-HVM for IPF (take 3)
Hi Alex, You (alex.williamson) said: I'll post new expand-memory-op.patch2. I applied this, but I did have to fix mm.h to make it build. Thanks, Thank you, and sorry. I forgot to append mm.h patch with expand-memory-op.patch2. -- ÅÚÈî¤Ç¤·¤¿¡¥¡¥¡¥ ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Catch up for PV_on_HVM (cont..)
Hi Anthony, Thank you for your comment. You (anthony.xu) said: I noticed that you use do_yield instead of do_block in xen-event.patch. I think do_yield will incur some unnecessary schedule before it can resume to Guest. Is this comment about vmx_send_assist_req() ? So, it sets _VCPUF_blocked_in_xen flags before the code to use do_yield. Thus, the VTi domain will be blocked until clear flags via new xen-evtchn notification, I think. ** cf. evtchn_send() in xen/common/event_channel.c -- $BEZHn$G$7$?!%!%!%(B ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] Porting PV-on-HVM for ia64 platform
Hi,
[EMAIL PROTECTED] wrote:
Currently, we are trying to modify PV-on-HVM feature for IPF with
the same method of x86 code. And in preliminary implement, we could do
the feature.
I will post patches for PV-on-HVM on ia64 platform. These patches
modify common code for PV-on-HVM on IPF.
We ported PV-on-HVM for IPF under this consideration:
* Expand memory_op hypercall
+ Introduce XENMEM_add_to_physmap
- A virtual space allocated on HVM-guest OS is remapped original
shared_info and grant_table page with this hypercall.
- This method is same as x86 method.
* Reduce hvm_op hypercall
+ Delete functions introduced for old PV-on-HVM on IPF.
* Revert domain destroy logic
+ revert arch_domain_destroy() for old PV-on-HVM on IPF.
* Modify unmodified_drivers initialization
+ cut off unused codes for IPF
+ modify build rule for IPF
These patch include: (common code)
* unmodified-driver.patch
- unmodified_drivers modification for IPF
* unmodified-build.patch
- unmodified_drivers build rule modification for IPF
We have tested that this patch doesn't affect dom0, domVTi without
pv-on-hvm driver attaching, and domVTi using pv-on-hvm driver works
VBD/VNIF on IPF.
Thanks,
- Tsunehisa Doi
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 96749232df478225e939252e704927be89dbae07
# Parent 259aea558618ad79219d838dcb520142a5f04897
Modify unmodified_drivers code for IPF
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
Signed-off-by: Tomonari Horikoshi [EMAIL PROTECTED]
diff -r 259aea558618 -r 96749232df47
unmodified_drivers/linux-2.6/platform-pci/platform-pci.c
--- a/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c Tue Aug 29
18:42:04 2006 +0900
+++ b/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c Tue Aug 29
18:45:43 2006 +0900
@@ -115,6 +115,7 @@ unsigned long alloc_xen_mmio(unsigned lo
return addr;
}
+#ifndef __ia64__
/* Lifted from hvmloader.c */
static int get_hypercall_stubs(void)
{
@@ -160,6 +161,7 @@ static int get_hypercall_stubs(void)
return 0;
}
+#endif /* !__ia64__ */
static int __devinit platform_pci_init(struct pci_dev *pdev,
const struct pci_device_id *ent)
@@ -201,9 +203,11 @@ static int __devinit platform_pci_init(s
platform_mmio = mmio_addr;
platform_mmiolen = mmio_len;
+#ifndef __ia64__
ret = get_hypercall_stubs();
if (ret 0)
goto out;
+#endif /* __ia64__ */
if ((ret = init_xen_info()))
diff -r 259aea558618 -r 96749232df47
unmodified_drivers/linux-2.6/platform-pci/xen_support.c
--- a/unmodified_drivers/linux-2.6/platform-pci/xen_support.c Tue Aug 29
18:42:04 2006 +0900
+++ b/unmodified_drivers/linux-2.6/platform-pci/xen_support.c Tue Aug 29
18:45:43 2006 +0900
@@ -26,11 +26,13 @@
#include asm/hypervisor.h
#include platform-pci.h
+#ifndef __ia64__
void xen_machphys_update(unsigned long mfn, unsigned long pfn)
{
BUG();
}
EXPORT_SYMBOL(xen_machphys_update);
+#endif /* __ia64__ */
void balloon_update_driver_allowance(long delta)
{
@@ -41,3 +43,15 @@ void balloon_release_driver_page(struct
{
}
EXPORT_SYMBOL(balloon_release_driver_page);
+
+#ifdef __ia64__
+int running_on_xen=1;
+EXPORT_SYMBOL(running_on_xen);
+
+int ia64_xenmem_reservation_op(unsigned long op,
+ struct xen_memory_reservation* reservation__)
+{
+ return 0;
+}
+EXPORT_SYMBOL(ia64_xenmem_reservation_op);
+#endif /* __ia64__ */
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID b5cafa21c61f2789b6a78c5980a2414486917f69
# Parent 96749232df478225e939252e704927be89dbae07
Modify unmodified_drivers build rule for IPF
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
Signed-off-by: Tomonari Horikoshi [EMAIL PROTECTED]
diff -r 96749232df47 -r b5cafa21c61f unmodified_drivers/linux-2.6/mkbuildtree
--- a/unmodified_drivers/linux-2.6/mkbuildtree Tue Aug 29 18:45:43 2006 +0900
+++ b/unmodified_drivers/linux-2.6/mkbuildtree Tue Aug 29 18:46:45 2006 +0900
@@ -42,6 +42,12 @@ i[34567]86)
ln -sf ${XL}/include/asm-i386/mach-xen/asm/synch_bitops.h include/asm
ln -sf ${XL}/include/asm-i386/mach-xen/asm/maddr.h include/asm
;;
+ia64)
+ ln -sf ${XL}/include/asm-ia64/hypervisor.h include/asm
+ ln -sf ${XL}/include/asm-ia64/hypercall.h include/asm
+ ln -sf ${XL}/include/asm-ia64/synch_bitops.h include/asm
+ ln -sf ${XL}/include/asm-ia64/maddr.h include/asm
+ ;;
*)
echo unknown architecture $uname
exit 1
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PV-on-HVM for IPF (take 3)
Hi all,
We have been porting PV-on-HVM feature for ia64 platform.
I will post patches for PV-on-HVM on ia64 platform. These patches modify
common code for PV-on-HVM on IPF.
We ported PV-on-HVM for IPF under this consideration:
* Expand memory_op hypercall
+ Introduce XENMEM_add_to_physmap
- A virtual space allocated on HVM-guest OS is remapped original
shared_info and grant_table page with this hypercall.
- This method is same as x86 method.
* Reduce hvm_op hypercall
+ Delete functions introduced for old PV-on-HVM on IPF.
* Revert domain destroy logic
+ revert arch_domain_destroy() for old PV-on-HVM on IPF.
* Modify unmodified_drivers initialization
+ cut off unused codes for IPF
+ modify build rule for IPF
These patch include: (ia64 specific code)
* expand-memory-op.patch
- introduce XENMEM_add_to_physmap feature for PV-on-HVM on IPF
* reduce-hvmop.patch
- reduce hvm_op hypercall for old PV-on-HVM on IPF
* revert-destroy.patch
- revert arch_domain_destory() for old PV-on-HVM on IPF
We have tested that this patch doesn't affect dom0, domVTi without
pv-on-hvm driver attaching, and domVTi using pv-on-hvm driver works
VBD/VNIF on IPF.
Thanks,
- Tsunehisa Doi
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 127e7a6c9f5636aea69d47bdeae0b938ea0d2d88
# Parent 684fdcfb251a443fa885c142b427d253ec033212
Reduce HYPERVISOR_hvmop for IPF
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
Signed-off-by: Tomonari Horikoshi [EMAIL PROTECTED]
diff -r 684fdcfb251a -r 127e7a6c9f56 xen/arch/ia64/vmx/vmx_hypercall.c
--- a/xen/arch/ia64/vmx/vmx_hypercall.c Mon Aug 28 16:26:37 2006 -0600
+++ b/xen/arch/ia64/vmx/vmx_hypercall.c Tue Aug 29 18:31:43 2006 +0900
@@ -37,91 +37,6 @@
#include public/version.h
#include asm/dom_fw.h
#include xen/domain.h
-#include xen/compile.h
-#include xen/event.h
-
-static void
-vmx_free_pages(unsigned long pgaddr, int npg)
-{
-for (; npg 0; npg--, pgaddr += PAGE_SIZE) {
-/* If original page belongs to xen heap, then relinguish back
- * to xen heap. Or else, leave to domain itself to decide.
- */
-if (likely(IS_XEN_HEAP_FRAME(virt_to_page(pgaddr {
-free_domheap_page(virt_to_page(pgaddr));
-free_xenheap_page((void *)pgaddr);
-}
-else {
-put_page(virt_to_page(pgaddr));
-}
-}
-}
-
-static int
-vmx_gnttab_setup_table(unsigned long frame_pa, unsigned long nr_frames)
-{
-struct domain *d = current-domain;
-struct grant_entry *pgaddr;
-unsigned long o_grant_shared;
-
-if ((nr_frames != NR_GRANT_FRAMES) || (frame_pa (PAGE_SIZE - 1))) {
-return -EINVAL;
-}
-
-pgaddr = domain_mpa_to_imva(d, frame_pa);
-if (pgaddr == NULL) {
-return -EFAULT;
-}
-
-o_grant_shared = (unsigned long)d-grant_table-shared;
-d-grant_table-shared = pgaddr;
-
-/* Copy existing grant table into new page */
-if (o_grant_shared) {
-memcpy((void *)d-grant_table-shared,
- (void *)o_grant_shared, PAGE_SIZE * nr_frames);
-vmx_free_pages(o_grant_shared, nr_frames);
-}
-else {
-memset((void *)d-grant_table-shared, 0, PAGE_SIZE * nr_frames);
-}
-return 0;
-}
-
-static int
-vmx_setup_shared_info_page(unsigned long gpa)
-{
-VCPU *vcpu = current;
-struct domain *d = vcpu-domain;
-unsigned long o_info;
-shared_info_t *pgaddr;
-struct vcpu *v;
-
-if (gpa ~PAGE_MASK) {
-return -EINVAL;
-}
-
-pgaddr = domain_mpa_to_imva(d, gpa);
-if (pgaddr == NULL) {
-return -EFAULT;
-}
-
-o_info = (u64)d-shared_info;
-d-shared_info = pgaddr;
-
-/* Copy existing shared info into new page */
-if (o_info) {
-memcpy((void*)d-shared_info, (void*)o_info, PAGE_SIZE);
-for_each_vcpu(d, v) {
-v-vcpu_info = d-shared_info-vcpu_info[v-vcpu_id];
-}
-vmx_free_pages(o_info, 1);
-}
-else {
-memset((void *)d-shared_info, 0, PAGE_SIZE);
-}
-return 0;
-}
long
do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
@@ -166,25 +81,6 @@ do_hvm_op(unsigned long op, XEN_GUEST_HA
break;
}
-case HVMOP_setup_gnttab_table:
-case HVMOP_setup_shared_info_page:
-{
-struct xen_hvm_setup a;
-
-if (copy_from_guest(a, arg, 1))
-return -EFAULT;
-
-switch (op) {
-case HVMOP_setup_gnttab_table:
-printk(vmx_gnttab_setup_table: frame_pa=%#lx,
-nr_frame=%ld\n, a.arg1, a.arg2);
-return vmx_gnttab_setup_table(a.arg1, a.arg2);
-case HVMOP_setup_shared_info_page:
-printk(vmx_setup_shared_info_page: gpa=0x%lx\n, a.arg1);
-return vmx_setup_shared_info_page(a.arg1);
-}
-}
-
default:
DPRINTK(Bad HVM op %ld.\n, op);
rc = -ENOSYS;
diff -r 684fdcfb251a -r
Re: [Xen-ia64-devel] PV-on-HVM for IPF (take 3)
Hi Tristan,
Thank you for your comment.
You (Tristan.Gingold) said:
I have a question about this modification:
void vcpu_flush_vtlb_all(struct vcpu *v)
{
- /* First VCPU tlb. */
- vcpu_purge_tr_entry(PSCBX(v,dtlb));
- vcpu_purge_tr_entry(PSCBX(v,itlb));
-
- /* Then VHPT. */
- vhpt_flush ();
-
- /* Then mTLB. */
- local_flush_tlb_all ();
+ if (VMX_DOMAIN(v)) {
+ /* Purge vTLB for VT-i domain */
+ thash_purge_all(v);
+ }
+ else {
+ /* First VCPU tlb. */
+ vcpu_purge_tr_entry(PSCBX(v,dtlb));
+ vcpu_purge_tr_entry(PSCBX(v,itlb));
+
+ /* Then VHPT. */
+ vhpt_flush ();
+
+ /* Then mTLB. */
+ local_flush_tlb_all ();
+ }
I don't really confortable with this modification. I suppose you have to
made it because of guest_physmap_remove_page.
Yes, I modified it because of guest_physmap_remove_page.
You should add least add a comment because it is unusable to see
VMX_DOMAIN() within paravirtualization area.
OK. I'll append comment to descibe more detail reason.
Thanks,
- Tsunehisa Doi
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PV-on-HVM for IPF (take 3)
You should add least add a comment because it is unusable to see
VMX_DOMAIN() within paravirtualization area.
OK. I'll append comment to descibe more detail reason.
I'll post new expand-memory-op.patch2.
Thanks,
- Tsunehisa Doi
Expand memory_op for PV-on-HVM on IPF
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
Signed-off-by: Tomonari Horikoshi [EMAIL PROTECTED]
diff -r 684fdcfb251a xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.cMon Aug 28 16:26:37 2006 -0600
+++ b/xen/arch/ia64/xen/mm.cWed Aug 30 14:06:33 2006 +0900
@@ -173,6 +173,9 @@
#include asm/vcpu.h
#include asm/shadow.h
#include linux/efi.h
+#include xen/guest_access.h
+#include asm/page.h
+#include public/memory.h
static void domain_page_flush(struct domain* d, unsigned long mpaddr,
unsigned long old_mfn, unsigned long new_mfn);
@@ -1752,6 +1755,82 @@ int memory_is_conventional_ram(paddr_t p
return (efi_mem_type(p) == EFI_CONVENTIONAL_MEMORY);
}
+
+long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
+{
+switch (op) {
+case XENMEM_add_to_physmap:
+{
+struct xen_add_to_physmap xatp;
+unsigned long prev_mfn, mfn = 0, gpfn;
+struct domain *d;
+
+if (copy_from_guest(xatp, arg, 1))
+return -EFAULT;
+
+if (xatp.domid == DOMID_SELF) {
+d = current-domain;
+get_knownalive_domain(d);
+}
+else if (!IS_PRIV(current-domain))
+return -EPERM;
+else if ((d = find_domain_by_id(xatp.domid)) == NULL)
+return -ESRCH;
+
+/* This hypercall is used for VT-i domain only */
+if (!VMX_DOMAIN(d-vcpu[0])) {
+put_domain(d);
+return -ENOSYS;
+}
+
+switch (xatp.space) {
+case XENMAPSPACE_shared_info:
+if (xatp.idx == 0)
+mfn = virt_to_mfn(d-shared_info);
+break;
+case XENMAPSPACE_grant_table:
+if (xatp.idx NR_GRANT_FRAMES)
+mfn = virt_to_mfn(d-grant_table-shared) + xatp.idx;
+break;
+default:
+break;
+}
+
+LOCK_BIGLOCK(d);
+
+/* Remove previously mapped page if it was present. */
+prev_mfn = gmfn_to_mfn(d, xatp.gpfn);
+if (prev_mfn mfn_valid(prev_mfn)) {
+if (IS_XEN_HEAP_FRAME(mfn_to_page(prev_mfn)))
+/* Xen heap frames are simply unhooked from this phys slot. */
+guest_physmap_remove_page(d, xatp.gpfn, prev_mfn);
+else
+/* Normal domain memory is freed, to avoid leaking memory. */
+guest_remove_page(d, xatp.gpfn);
+}
+
+/* Unmap from old location, if any. */
+gpfn = get_gpfn_from_mfn(mfn);
+if (gpfn != INVALID_M2P_ENTRY)
+guest_physmap_remove_page(d, gpfn, mfn);
+
+/* Map at new location. */
+guest_physmap_add_page(d, xatp.gpfn, mfn);
+
+UNLOCK_BIGLOCK(d);
+
+put_domain(d);
+
+break;
+}
+
+default:
+return -ENOSYS;
+}
+
+return 0;
+}
+
/*
* Local variables:
* mode: C
diff -r 684fdcfb251a xen/arch/ia64/xen/vhpt.c
--- a/xen/arch/ia64/xen/vhpt.c Mon Aug 28 16:26:37 2006 -0600
+++ b/xen/arch/ia64/xen/vhpt.c Wed Aug 30 14:06:33 2006 +0900
@@ -14,6 +14,7 @@
#include asm/page.h
#include asm/vhpt.h
#include asm/vcpu.h
+#include asm/vmmu.h
/* Defined in tlb.c */
extern void ia64_global_tlb_purge(UINT64 start, UINT64 end, UINT64 nbits);
@@ -131,15 +132,25 @@ void vhpt_init(void)
void vcpu_flush_vtlb_all(struct vcpu *v)
{
- /* First VCPU tlb. */
- vcpu_purge_tr_entry(PSCBX(v,dtlb));
- vcpu_purge_tr_entry(PSCBX(v,itlb));
-
- /* Then VHPT. */
- vhpt_flush ();
-
- /* Then mTLB. */
- local_flush_tlb_all ();
+ if (VMX_DOMAIN(v)) {
+ /* This code may be call for remapping shared_info and
+ grant_table share page from guest_physmap_remove_page()
+ in arch_memory_op() XENMEM_add_to_physmap to realize
+ PV-on-HVM feature. */
+ /* Purge vTLB for VT-i domain */
+ thash_purge_all(v);
+ }
+ else {
+ /* First VCPU tlb. */
+ vcpu_purge_tr_entry(PSCBX(v,dtlb));
+ vcpu_purge_tr_entry(PSCBX(v,itlb));
+
+ /* Then VHPT. */
+ vhpt_flush ();
+
+ /* Then mTLB. */
+ local_flush_tlb_all ();
+ }
/* We could clear bit in d-domain_dirty_cpumask only if domain d in
not running on this processor. There is currently no easy way to
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PV-on-HVM driver for IPF
Alex Williamson wrote:
On Mon, 2006-08-28 at 08:35 +0900, [EMAIL PROTECTED] wrote:
In PV-on-HVM driver code, is_running_on_xen and HYPERVISOR_ioremap
have to be used as valid feature. Thus we modified like this.
Doesn't the below do what you need w/o breaking the CONFIG_XEN=n
build? It's important to keep both builds working. Thanks,
Thank you for suggestion.
We modified linux-ia64.patch. I'll post it.
And, We'll change PV-on-HVM implementation in xen side which uses
same method of x86 code.
Thanks,
- Tsunehisa Doi
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
Signed-off-by: Tomonari Horikoshi [EMAIL PROTECTED]
diff -r 40f6fdb68fa9 linux-2.6-xen-sparse/include/asm-ia64/hypercall.h
--- a/linux-2.6-xen-sparse/include/asm-ia64/hypercall.h Sun Aug 27 10:25:39
2006 -0600
+++ b/linux-2.6-xen-sparse/include/asm-ia64/hypercall.h Mon Aug 28 20:02:22
2006 +0900
@@ -315,7 +315,9 @@ static inline void exit_idle(void) {}
})
#include linux/err.h
+#ifdef CONFIG_XEN
#include asm/xen/privop.h
+#endif /* CONFIG_XEN */
static inline unsigned long
__HYPERVISOR_ioremap(unsigned long ioaddr, unsigned long size)
diff -r 40f6fdb68fa9 linux-2.6-xen-sparse/include/asm-ia64/hypervisor.h
--- a/linux-2.6-xen-sparse/include/asm-ia64/hypervisor.hSun Aug 27
10:25:39 2006 -0600
+++ b/linux-2.6-xen-sparse/include/asm-ia64/hypervisor.hMon Aug 28
20:02:22 2006 +0900
@@ -33,7 +33,7 @@
#ifndef __HYPERVISOR_H__
#define __HYPERVISOR_H__
-#ifndef CONFIG_XEN
+#if !defined(CONFIG_XEN) !defined(CONFIG_VMX_GUEST)
#define is_running_on_xen()(0)
#define HYPERVISOR_ioremap(offset, size) (offset)
#else
@@ -41,7 +41,7 @@ extern int running_on_xen;
#define is_running_on_xen()(running_on_xen)
#endif
-#ifdef CONFIG_XEN
+#if defined(CONFIG_XEN) || defined(CONFIG_VMX_GUEST)
#include linux/config.h
#include linux/types.h
#include linux/kernel.h
@@ -59,10 +59,9 @@ extern shared_info_t *HYPERVISOR_shared_
extern shared_info_t *HYPERVISOR_shared_info;
extern start_info_t *xen_start_info;
-#define is_initial_xendomain() (xen_start_info-flags SIF_INITDOMAIN)
-
void force_evtchn_callback(void);
+#ifndef CONFIG_VMX_GUEST
/* Turn jiffies into Xen system time. XXX Implement me. */
#define jiffies_to_st(j) 0
@@ -145,10 +144,14 @@ int privcmd_mmap(struct file * file, str
#define scrub_pages(_p,_n) ((void)0)
#endif
#definepte_mfn(_x) pte_pfn(_x)
-#define __pte_ma(_x) ((pte_t) {(_x)})
#define phys_to_machine_mapping_valid(_x) (1)
-#define pfn_pte_ma(_x,_y) __pte_ma(0)
-
+
+#endif /* !CONFIG_VMX_GUEST */
+
+#define __pte_ma(_x) ((pte_t) {(_x)})/* unmodified use */
+#define pfn_pte_ma(_x,_y) __pte_ma(0) /* unmodified use */
+
+#ifndef CONFIG_VMX_GUEST
int __xen_create_contiguous_region(unsigned long vstart, unsigned int order,
unsigned int address_bits);
static inline int
xen_create_contiguous_region(unsigned long vstart,
@@ -170,6 +173,8 @@ xen_destroy_contiguous_region(unsigned l
__xen_destroy_contiguous_region(vstart, order);
}
+#endif /* !CONFIG_VMX_GUEST */
+
// for netfront.c, netback.c
#define MULTI_UVMFLAGS_INDEX 0 //XXX any value
@@ -180,12 +185,29 @@ MULTI_update_va_mapping(
{
mcl-op = __HYPERVISOR_update_va_mapping;
mcl-result = 0;
+}
+
+static inline void
+MULTI_grant_table_op(multicall_entry_t *mcl, unsigned int cmd,
+ void *uop, unsigned int count)
+{
+ mcl-op = __HYPERVISOR_grant_table_op;
+ mcl-args[0] = cmd;
+ mcl-args[1] = (unsigned long)uop;
+ mcl-args[2] = count;
}
// for debug
asmlinkage int xprintk(const char *fmt, ...);
#define xprintd(fmt, ...) xprintk(%s:%d fmt, __func__, __LINE__, \
##__VA_ARGS__)
-#endif /* CONFIG_XEN */
+
+#endif /* CONFIG_XEN || CONFIG_VMX_GUEST */
+
+#ifdef CONFIG_XEN_PRIVILEGED_GUEST
+#define is_initial_xendomain() (xen_start_info-flags SIF_INITDOMAIN)
+#else
+#define is_initial_xendomain() 0
+#endif
#endif /* __HYPERVISOR_H__ */
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PV-on-HVM driver for IPF
Hi,
You (alex.williamson) said:
On Sat, 2006-08-26 at 14:45 +0900, $Be.d9(B wrote:
-/* Copy existing grant table shared into new page */
+/* Copy existing grant table new page */
if (o_grant_shared) {
memcpy((void *)d-grant_table-shared,
(void *)o_grant_shared, PAGE_SIZE * nr_frames);
The existing comment seems to make more sense here. Should it be
Copy existing grant table into new page?
Thank you. I'll modify it.
The patch below causes the kernel build to fail when CONFIG_XEN is
not set. Why remove the CONFIG_XEN statement? Thanks,
diff -r 153ba50864b7 -r 9647400b5041
linux-2.6-xen-sparse/include/asm-ia64/hypercall.h
--- a/linux-2.6-xen-sparse/include/asm-ia64/hypercall.h Sat Aug 26
13:33:16 2006 +0900
+++ b/linux-2.6-xen-sparse/include/asm-ia64/hypercall.h Sat Aug 26
13:37:41 2006 +0900
@@ -315,7 +315,9 @@ static inline void exit_idle(void) {}
})
#include linux/err.h
+#ifdef CONFIG_XEN
#include asm/xen/privop.h
+#endif /* CONFIG_XEN */
static inline unsigned long
__HYPERVISOR_ioremap(unsigned long ioaddr, unsigned long size)
diff -r 153ba50864b7 -r 9647400b5041
linux-2.6-xen-sparse/include/asm-ia64/hypervisor.h
--- a/linux-2.6-xen-sparse/include/asm-ia64/hypervisor.hSat
Aug 26 13:33:16 2006 +0900
+++ b/linux-2.6-xen-sparse/include/asm-ia64/hypervisor.hSat
Aug 26 13:37:41 2006 +0900
@@ -33,15 +33,9 @@
#ifndef __HYPERVISOR_H__
#define __HYPERVISOR_H__
-#ifndef CONFIG_XEN
-#define is_running_on_xen()(0)
-#define HYPERVISOR_ioremap(offset, size) (offset)
-#else
extern int running_on_xen;
#define is_running_on_xen()(running_on_xen)
-#endif
-#ifdef CONFIG_XEN
In PV-on-HVM driver code, is_running_on_xen and HYPERVISOR_ioremap
have to be used as valid feature. Thus we modified like this.
Thanks,
- Tsunehisa Doi
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PV-on-HVM driver for IPF
[EMAIL PROTECTED] wrote:
You (alex.williamson) said:
On Sat, 2006-08-26 at 14:45 +0900, 絎箙 wrote:
-/* Copy existing grant table shared into new page */
+/* Copy existing grant table new page */
if (o_grant_shared) {
memcpy((void *)d-grant_table-shared,
(void *)o_grant_shared, PAGE_SIZE * nr_frames);
The existing comment seems to make more sense here. Should it be
Copy existing grant table into new page?
Thank you. I'll modify it.
I'll post new fix-comment.patch2.
Thanks,
- Tsunehisa Doi
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
Signed-off-by: Tomonari Horikoshi [EMAIL PROTECTED]
diff -r 3e0685ecfe64 xen/arch/ia64/vmx/vmx_hypercall.c
--- a/xen/arch/ia64/vmx/vmx_hypercall.c Fri Aug 25 16:21:39 2006 -0600
+++ b/xen/arch/ia64/vmx/vmx_hypercall.c Mon Aug 28 09:08:38 2006 +0900
@@ -75,7 +75,7 @@ vmx_gnttab_setup_table(unsigned long fra
o_grant_shared = (unsigned long)d-grant_table-shared;
d-grant_table-shared = (struct grant_entry *)pgaddr;
-/* Copy existing grant table shared into new page */
+/* Copy existing grant table info new page */
if (o_grant_shared) {
memcpy((void *)d-grant_table-shared,
(void *)o_grant_shared, PAGE_SIZE * nr_frames);
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] Porting PV-on-HVM for ia64 platform
Hi all, Sorry, I have tried to repost it, but my mail tool reformated with format which I don't want. I (Doi.Tsunehisa) said: Tsunehisa Doi wrote: Hi all, My name is Tsunehisa Doi. We have been porting PV-on-HVM feature for ia64 platform. Sorry, This message is difficult to read. I'll resend same. Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] Porting PV-on-HVM for ia64 platform
I (Doi.Tsunehisa) said: You (Keir.Fraser) said: On 26/8/06 6:50 am, Tsunehisa Doi [EMAIL PROTECTED] wrote: - In x86 code, original shared_info page is used after pv-on-hvm setup with remapping feature in arch depend HYPERVISOR_memory_op. But, we can't implement same feature for IPF, thus we select to implement with this method. Why is that? It's a change to the P2M map -- it's not an x86-specific operation. We had tried to implement it with the same method as x86 code, but we couldn't success to implement it. If we will refere to implementation of grant table operation, we may be able to success to implement it, but it's not easy for us, I think. I'll try to describe the reasoon which I think about. In IPF, V2P address translation uses TR, TC and VHPT. VHPT is like page table in x86 platform, and TC is like TLB in it exept for direct handling posibility. But TR is specific for IPF. TR is controled directly with MM, its entry does not be deleted by hardware if MM does not control it. In additionaly, TR, TC and VHPT can use flexible page size for each entry. Thus normal linux kernel uses a TR entry for kernel virtual space. So, in HVM domain on IPF, it is difficult to change a part of P2M map of kernel virtual space without MM modification. Thanks, -- Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PV-on-HVM driver for IPF
Hi,
You (Tristan.Gingold) said:
I will post patches of PV-on-HVM for IPF.
We wrote the patch under this consideration:
* Expand hvm_op hypercall
+ Introduce HVMOP_setup_shared_info_page
- A page allocated on HVM-guest OS is swapped original
shared_info page with this hypercall.
- In x86 code, original shared_info page is used after pv-on-hvm
setup with remapping feature in arch depend
HYPERVISOR_memory_op. But, we can't implement same feature for IPF, thus
we select to implement with this method.
Can you explain why you can't reuse the HYPERVISOR_memory_op hcall ?
It isn't clear for me.
In x86 code (xen/arch/x86/mm.c), it uses only virtual space of page frame
allocated by GuestOS, and remaps the vitual space to original share_info
page frame. But, we can't find same method for IPF.
Can you suggest us about the remapping method ?
I simply wonder why did you create a new hypercall. You could have reuse the
same hypercall, using a slighly different semantic. But it doesn't really
matter.
I think that the functions which have diffect semantic should be called
with the different names.
+if (likely(IS_XEN_HEAP_FRAME(virt_to_page(pgaddr {
+free_domheap_page(virt_to_page(pgaddr));
+free_xenheap_page((void *)pgaddr);
+}
+else {
+put_page(virt_to_page(pgaddr));
+}
May create a function to be called by gnttab_setup_table and
setup_shared_info_page.
I think that these function are for only VT-i domain, thus I used
vmx_ prefix. What do you think about it ?
Sorry I was not clear enough.
This block appears in both function. I'd suggest to create a function to
avoid duplicating code.
Sorry, I had misunderstood your suggestion.
I agree. I'll correct it.
Thanks,
-- Tsunehisa Doi
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PV-on-HVM driver for IPF
I'll post new xen-hyper.patch3 whitch was modified.
Thanks,
-- Tsunehisa Doi
[EMAIL PROTECTED] wrote:
+if (likely(IS_XEN_HEAP_FRAME(virt_to_page(pgaddr {
+free_domheap_page(virt_to_page(pgaddr));
+free_xenheap_page((void *)pgaddr);
+}
+else {
+put_page(virt_to_page(pgaddr));
+}
May create a function to be called by gnttab_setup_table and
setup_shared_info_page.
I think that these function are for only VT-i domain, thus I used
vmx_ prefix. What do you think about it ?
Sorry I was not clear enough.
This block appears in both function. I'd suggest to create a function to
avoid duplicating code.
Sorry, I had misunderstood your suggestion.
I agree. I'll correct it.
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
Signed-off-by: Tomonari Horikoshi [EMAIL PROTECTED]
diff -r 3e54734e55f3 xen/arch/ia64/vmx/vmx_hypercall.c
--- a/xen/arch/ia64/vmx/vmx_hypercall.c Wed Aug 23 13:26:46 2006 -0600
+++ b/xen/arch/ia64/vmx/vmx_hypercall.c Fri Aug 25 17:25:17 2006 +0900
@@ -2,6 +2,7 @@
/*
* vmx_hyparcall.c: handling hypercall from domain
* Copyright (c) 2005, Intel Corporation.
+ * Copyright (c) 2006, Fujitsu Limited.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU General Public License,
@@ -17,6 +18,8 @@
* Place - Suite 330, Boston, MA 02111-1307 USA.
*
* Xuefei Xu (Anthony Xu) ([EMAIL PROTECTED])
+ * Tsunehisa Doi ([EMAIL PROTECTED])
+ * Tomonari Horikoshi ([EMAIL PROTECTED])
*/
#include xen/config.h
@@ -34,6 +37,89 @@
#include public/version.h
#include asm/dom_fw.h
#include xen/domain.h
+#include xen/compile.h
+#include xen/event.h
+
+static void
+vmx_free_pages(unsigned long pgaddr, int npg)
+{
+for (; npg 0; npg--, pgaddr += PAGE_SIZE) {
+/* If original page belongs to xen heap, then relinguish back
+ * to xen heap. Or else, leave to domain itself to decide.
+ */
+ if (likely(IS_XEN_HEAP_FRAME(virt_to_page(pgaddr {
+ free_domheap_page(virt_to_page(pgaddr));
+ free_xenheap_page((void *)pgaddr);
+ }
+ else {
+ put_page(virt_to_page(pgaddr));
+ }
+}
+}
+
+static int
+vmx_gnttab_setup_table(unsigned long frame_pa, unsigned long nr_frames)
+{
+struct domain *d = current-domain;
+unsigned long o_grant_shared, pgaddr;
+
+if ((nr_frames != NR_GRANT_FRAMES) || (frame_pa (PAGE_SIZE - 1))) {
+return -EINVAL;
+}
+
+pgaddr = domain_mpa_to_imva(d, frame_pa);
+if (pgaddr == NULL) {
+return -EFAULT;
+}
+
+o_grant_shared = (unsigned long)d-grant_table-shared;
+d-grant_table-shared = (struct grant_entry *)pgaddr;
+
+/* Copy existing grant table shared into new page */
+if (o_grant_shared) {
+memcpy((void *)d-grant_table-shared,
+(void *)o_grant_shared, PAGE_SIZE * nr_frames);
+ vmx_free_pages(o_grant_shared, nr_frames);
+}
+else {
+memset((void *)d-grant_table-shared, 0, PAGE_SIZE * nr_frames);
+}
+return 0;
+}
+
+static int
+vmx_setup_shared_info_page(unsigned long gpa)
+{
+VCPU *vcpu = current;
+struct domain *d = vcpu-domain;
+unsigned long o_info, pgaddr;
+struct vcpu *v;
+
+if (gpa (PAGE_SIZE - 1)) {
+return -EINVAL;
+}
+
+pgaddr = domain_mpa_to_imva(d, gpa);
+if (pgaddr == NULL) {
+return -EFAULT;
+}
+
+o_info = (u64)d-shared_info;
+d-shared_info= (shared_info_t *)pgaddr;
+
+/* Copy existing shared info into new page */
+if (o_info) {
+memcpy((void*)d-shared_info, (void*)o_info, PAGE_SIZE);
+for_each_vcpu(d, v) {
+v-vcpu_info = d-shared_info-vcpu_info[v-vcpu_id];
+}
+ vmx_free_pages(o_info, 1);
+}
+else {
+memset((void *)d-shared_info, 0, PAGE_SIZE);
+}
+return 0;
+}
long
do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
@@ -78,6 +164,25 @@ do_hvm_op(unsigned long op, XEN_GUEST_HA
break;
}
+case HVMOP_setup_gnttab_table:
+case HVMOP_setup_shared_info_page:
+{
+struct xen_hvm_setup a;
+
+if (copy_from_guest(a, arg, 1))
+return -EFAULT;
+
+switch (op) {
+case HVMOP_setup_gnttab_table:
+printk(vmx_gnttab_setup_table: frame_pa=%#lx,
+nr_frame=%ld\n, a.arg1, a.arg2);
+return vmx_gnttab_setup_table(a.arg1, a.arg2);
+case HVMOP_setup_shared_info_page:
+printk(vmx_setup_shared_info_page: gpa=0x%lx\n, a.arg1);
+return vmx_setup_shared_info_page(a.arg1);
+}
+}
+
default:
DPRINTK(Bad HVM op %ld.\n, op);
rc = -ENOSYS;
diff -r 3e54734e55f3 xen/include/public/arch-ia64.h
--- a/xen/include/public/arch-ia64.hWed Aug 23 13:26:46 2006 -0600
+++ b/xen/include/public/arch-ia64.hFri
Re: [Xen-ia64-devel] PV-on-HVM driver for IPF
Sorry, I didn't cleanup about indent.
I'll repost new xen-hyper.patch4.
Thanks,
-- Tsunehisa Doi
DOI Tsunehisa wrote:
I'll post new xen-hyper.patch3 whitch was modified.
Thanks,
-- Tsunehisa Doi
[EMAIL PROTECTED] wrote:
+if (likely(IS_XEN_HEAP_FRAME(virt_to_page(pgaddr {
+free_domheap_page(virt_to_page(pgaddr));
+free_xenheap_page((void *)pgaddr);
+}
+else {
+put_page(virt_to_page(pgaddr));
+}
May create a function to be called by gnttab_setup_table and
setup_shared_info_page.
I think that these function are for only VT-i domain, thus I used
vmx_ prefix. What do you think about it ?
Sorry I was not clear enough.
This block appears in both function. I'd suggest to create a function to
avoid duplicating code.
Sorry, I had misunderstood your suggestion.
I agree. I'll correct it.
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
Signed-off-by: Tomonari Horikoshi [EMAIL PROTECTED]
diff -r 3e54734e55f3 xen/arch/ia64/vmx/vmx_hypercall.c
--- a/xen/arch/ia64/vmx/vmx_hypercall.c Wed Aug 23 13:26:46 2006 -0600
+++ b/xen/arch/ia64/vmx/vmx_hypercall.c Fri Aug 25 17:25:17 2006 +0900
@@ -2,6 +2,7 @@
/*
* vmx_hyparcall.c: handling hypercall from domain
* Copyright (c) 2005, Intel Corporation.
+ * Copyright (c) 2006, Fujitsu Limited.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU General Public License,
@@ -17,6 +18,8 @@
* Place - Suite 330, Boston, MA 02111-1307 USA.
*
* Xuefei Xu (Anthony Xu) ([EMAIL PROTECTED])
+ * Tsunehisa Doi ([EMAIL PROTECTED])
+ * Tomonari Horikoshi ([EMAIL PROTECTED])
*/
#include xen/config.h
@@ -34,6 +37,89 @@
#include public/version.h
#include asm/dom_fw.h
#include xen/domain.h
+#include xen/compile.h
+#include xen/event.h
+
+static void
+vmx_free_pages(unsigned long pgaddr, int npg)
+{
+for (; npg 0; npg--, pgaddr += PAGE_SIZE) {
+/* If original page belongs to xen heap, then relinguish back
+ * to xen heap. Or else, leave to domain itself to decide.
+ */
+if (likely(IS_XEN_HEAP_FRAME(virt_to_page(pgaddr {
+free_domheap_page(virt_to_page(pgaddr));
+free_xenheap_page((void *)pgaddr);
+}
+else {
+put_page(virt_to_page(pgaddr));
+}
+}
+}
+
+static int
+vmx_gnttab_setup_table(unsigned long frame_pa, unsigned long nr_frames)
+{
+struct domain *d = current-domain;
+unsigned long o_grant_shared, pgaddr;
+
+if ((nr_frames != NR_GRANT_FRAMES) || (frame_pa (PAGE_SIZE - 1))) {
+return -EINVAL;
+}
+
+pgaddr = domain_mpa_to_imva(d, frame_pa);
+if (pgaddr == NULL) {
+return -EFAULT;
+}
+
+o_grant_shared = (unsigned long)d-grant_table-shared;
+d-grant_table-shared = (struct grant_entry *)pgaddr;
+
+/* Copy existing grant table shared into new page */
+if (o_grant_shared) {
+memcpy((void *)d-grant_table-shared,
+(void *)o_grant_shared, PAGE_SIZE * nr_frames);
+vmx_free_pages(o_grant_shared, nr_frames);
+}
+else {
+memset((void *)d-grant_table-shared, 0, PAGE_SIZE * nr_frames);
+}
+return 0;
+}
+
+static int
+vmx_setup_shared_info_page(unsigned long gpa)
+{
+VCPU *vcpu = current;
+struct domain *d = vcpu-domain;
+unsigned long o_info, pgaddr;
+struct vcpu *v;
+
+if (gpa (PAGE_SIZE - 1)) {
+return -EINVAL;
+}
+
+pgaddr = domain_mpa_to_imva(d, gpa);
+if (pgaddr == NULL) {
+return -EFAULT;
+}
+
+o_info = (u64)d-shared_info;
+d-shared_info= (shared_info_t *)pgaddr;
+
+/* Copy existing shared info into new page */
+if (o_info) {
+memcpy((void*)d-shared_info, (void*)o_info, PAGE_SIZE);
+for_each_vcpu(d, v) {
+v-vcpu_info = d-shared_info-vcpu_info[v-vcpu_id];
+}
+vmx_free_pages(o_info, 1);
+}
+else {
+memset((void *)d-shared_info, 0, PAGE_SIZE);
+}
+return 0;
+}
long
do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
@@ -78,6 +164,25 @@ do_hvm_op(unsigned long op, XEN_GUEST_HA
break;
}
+case HVMOP_setup_gnttab_table:
+case HVMOP_setup_shared_info_page:
+{
+struct xen_hvm_setup a;
+
+if (copy_from_guest(a, arg, 1))
+return -EFAULT;
+
+switch (op) {
+case HVMOP_setup_gnttab_table:
+printk(vmx_gnttab_setup_table: frame_pa=%#lx,
+nr_frame=%ld\n, a.arg1, a.arg2);
+return vmx_gnttab_setup_table(a.arg1, a.arg2);
+case HVMOP_setup_shared_info_page:
+printk(vmx_setup_shared_info_page: gpa=0x%lx\n, a.arg1
Re: [Xen-ia64-devel] PV-on-HVM driver for IPF
Hi Tristan,
Thank you for your comment.
You (Tristan.Gingold) said:
I will post patches of PV-on-HVM for IPF.
We wrote the patch under this consideration:
* Expand hvm_op hypercall
+ Introduce HVMOP_setup_shared_info_page
- A page allocated on HVM-guest OS is swapped original shared_info
page with this hypercall.
- In x86 code, original shared_info page is used after pv-on-hvm
setup with remapping feature in arch depend HYPERVISOR_memory_op.
But, we can't implement same feature for IPF, thus we select to
implement with this method.
Can you explain why you can't reuse the HYPERVISOR_memory_op hcall ?
It isn't clear for me.
In x86 code (xen/arch/x86/mm.c), it uses only virtual space of page frame
allocated by GuestOS, and remaps the vitual space to original share_info
page frame. But, we can't find same method for IPF.
Can you suggest us about the remapping method ?
About the patch:
+static int
+vmx_gnttab_setup_table(unsigned long frame_pa, unsigned long nr_frames)
+{
+struct domain *d = current-domain;
+int rc = 0, i;
+unsigned long o_grant_shared, pgaddr;
+
+if (nr_frames != NR_GRANT_FRAMES) {
+return -1;
You'd better to return -EINVAL.
I agree. I'll correct it.
+}
+o_grant_shared = (unsigned long)d-grant_table-shared;
+d-grant_table-shared = (struct grant_entry *)domain_mpa_to_imva(d,
frame_pa);
+
+/* Copy existing grant table shared into new page */
+if (o_grant_shared) {
+memcpy((void*)d-grant_table-shared,
+(void*)o_grant_shared, PAGE_SIZE * nr_frames);
You should check the result of domain_mpa_to_imva, as it could fail.
I agree. I'll try to correct it. It returns NULL if it fails, I think.
Is it correct ?
+if (likely(IS_XEN_HEAP_FRAME(virt_to_page(pgaddr {
+free_domheap_page(virt_to_page(pgaddr));
+free_xenheap_page((void *)pgaddr);
+}
+else {
+put_page(virt_to_page(pgaddr));
+}
May create a function to be called by gnttab_setup_table and
setup_shared_info_page.
I think that these function are for only VT-i domain, thus I used
vmx_ prefix. What do you think about it ?
Thanks,
-- Tsunehisa Doi
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PV-on-HVM driver for IPF
Hi,
I'll post a new xen-hyper.patch2, whitch is modified about parameter
checking.
[EMAIL PROTECTED] wrote:
Hi Tristan,
Thank you for your comment.
You (Tristan.Gingold) said:
I will post patches of PV-on-HVM for IPF.
We wrote the patch under this consideration:
* Expand hvm_op hypercall
+ Introduce HVMOP_setup_shared_info_page
- A page allocated on HVM-guest OS is swapped original shared_info
page with this hypercall.
- In x86 code, original shared_info page is used after pv-on-hvm
setup with remapping feature in arch depend HYPERVISOR_memory_op.
But, we can't implement same feature for IPF, thus we select to
implement with this method.
Can you explain why you can't reuse the HYPERVISOR_memory_op hcall ?
It isn't clear for me.
In x86 code (xen/arch/x86/mm.c), it uses only virtual space of page frame
allocated by GuestOS, and remaps the vitual space to original share_info
page frame. But, we can't find same method for IPF.
Can you suggest us about the remapping method ?
About the patch:
+static int
+vmx_gnttab_setup_table(unsigned long frame_pa, unsigned long nr_frames)
+{
+struct domain *d = current-domain;
+int rc = 0, i;
+unsigned long o_grant_shared, pgaddr;
+
+if (nr_frames != NR_GRANT_FRAMES) {
+return -1;
You'd better to return -EINVAL.
I agree. I'll correct it.
+}
+o_grant_shared = (unsigned long)d-grant_table-shared;
+d-grant_table-shared = (struct grant_entry *)domain_mpa_to_imva(d,
frame_pa);
+
+/* Copy existing grant table shared into new page */
+if (o_grant_shared) {
+memcpy((void*)d-grant_table-shared,
+(void*)o_grant_shared, PAGE_SIZE * nr_frames);
You should check the result of domain_mpa_to_imva, as it could fail.
I agree. I'll try to correct it. It returns NULL if it fails, I think.
Is it correct ?
+if (likely(IS_XEN_HEAP_FRAME(virt_to_page(pgaddr {
+free_domheap_page(virt_to_page(pgaddr));
+free_xenheap_page((void *)pgaddr);
+}
+else {
+put_page(virt_to_page(pgaddr));
+}
May create a function to be called by gnttab_setup_table and
setup_shared_info_page.
I think that these function are for only VT-i domain, thus I used
vmx_ prefix. What do you think about it ?
Thanks,
-- Tsunehisa Doi
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
Signed-off-by: Tomonari Horikoshi [EMAIL PROTECTED]
diff -r 3e54734e55f3 xen/arch/ia64/vmx/vmx_hypercall.c
--- a/xen/arch/ia64/vmx/vmx_hypercall.c Wed Aug 23 13:26:46 2006 -0600
+++ b/xen/arch/ia64/vmx/vmx_hypercall.c Fri Aug 25 11:08:18 2006 +0900
@@ -2,6 +2,7 @@
/*
* vmx_hyparcall.c: handling hypercall from domain
* Copyright (c) 2005, Intel Corporation.
+ * Copyright (c) 2006, Fujitsu Limited.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU General Public License,
@@ -17,6 +18,8 @@
* Place - Suite 330, Boston, MA 02111-1307 USA.
*
* Xuefei Xu (Anthony Xu) ([EMAIL PROTECTED])
+ * Tsunehisa Doi ([EMAIL PROTECTED])
+ * Tomonari Horikoshi ([EMAIL PROTECTED])
*/
#include xen/config.h
@@ -34,6 +37,94 @@
#include public/version.h
#include asm/dom_fw.h
#include xen/domain.h
+#include xen/compile.h
+#include xen/event.h
+
+static int
+vmx_gnttab_setup_table(unsigned long frame_pa, unsigned long nr_frames)
+{
+struct domain *d = current-domain;
+int rc = 0, i;
+unsigned long o_grant_shared, pgaddr;
+
+if ((nr_frames != NR_GRANT_FRAMES) || (frame_pa (PAGE_SIZE - 1))) {
+return -EINVAL;
+}
+
+pgaddr = domain_mpa_to_imva(d, frame_pa);
+if (pgaddr == NULL) {
+return -EFAULT;
+}
+
+o_grant_shared = (unsigned long)d-grant_table-shared;
+d-grant_table-shared = (struct grant_entry *)pgaddr;
+
+/* Copy existing grant table shared into new page */
+if (o_grant_shared) {
+memcpy((void*)d-grant_table-shared,
+(void*)o_grant_shared, PAGE_SIZE * nr_frames);
+/* If original page belongs to xen heap, then relinguish back
+ * to xen heap. Or else, leave to domain itself to decide.
+ */
+for (i = 0; i NR_GRANT_FRAMES; i++) {
+pgaddr = o_grant_shared + PAGE_SIZE * i;
+if (likely(IS_XEN_HEAP_FRAME(virt_to_page(pgaddr {
+free_domheap_page(virt_to_page(pgaddr));
+free_xenheap_page((void *)pgaddr);
+}
+else {
+put_page(virt_to_page(pgaddr));
+}
+}
+}
+else {
+memset(d-grant_table-shared, 0, PAGE_SIZE * nr_frames);
+}
+return rc;
+}
+
+static int
+vmx_setup_shared_info_page(unsigned long gpa)
+{
+VCPU *vcpu = current;
+struct domain *d = vcpu-domain;
+unsigned long o_info, pgaddr;
+struct
[Xen-ia64-devel] Catch up for PV_on_HVM (cont..)
Hi all,
I will post patches for catching up the remain features for PV-on-HVM.
* need to catchup for IPF
+ 02.ioemu_xen_evtchns.diff:applied (cs:10974-10976) *not yet*
- Flip the device model over to using the new Xen event channels
+ 04.hvm_inter.diff:applied (cs:11057)
- Add support for sending event channel interrupts to HVM guests.
+ 10.hvm_op_hypercall.diff: applied (cs:11079)
- Add stubs to Linux for the new hvm_op hypercall.
+ 12.add_maddr_h.diff: applied (cs:11081) *not yet*
- Split useful bits of page.h into new header maddr.h.
+ **hvm_op fixup**: applied (cs:11070)
- HVMOP_get_param return parameter value within the provided
parameter struct
I had posted several patches for these features, a few days ago.
* catch up `hvm_op fixup'
- This patch modifies HYPERVISOR_hvm_op().
* catch up `hvm_inter'
- This patch adds support for sending event channel interrupts
to VT-i guests.
* catch up `hvm_op_hypercall'
- This patch includes HYPERVISOR_hvm_op() stabs for linux.
This patch includes:
* catch up `split maddr.h'
- Split page.h into maddr.h
- This patch is like Alex's patch, but it includes preparation
for PV-on-HVM.
* catch up `new Xen event channles'
- DM over to using the new Xen event channel for IPF
- Modify xc_ia64_hvm_build for using the new Xen event channel
- We can't use wait_on_xen_event_channel() macro as x86 code.
Because IPF code is different with x86 code about MMIO
emulation. In x86 code, it waits for MMIO completion
at scheduler tail code. The purpose of the code is enabling
interupt handling during MMIO intercepts. But, in IPF code,
it's different.
- We will want to modify IPF code like x86 code in the future.
Thanks,
- Tsunehisa Doi
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 5c75dc35f1ba16216fad2b9df939d8c1c80ab9bd
# Parent d42e9a6f537883c707ee5f7dd2a2c980881934c8
Split page.h into maddr.h for IPF
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
Signed-off-by: Tomonari Horikoshi [EMAIL PROTECTED]
diff -r d42e9a6f5378 -r 5c75dc35f1ba
linux-2.6-xen-sparse/include/asm-ia64/page.h
--- a/linux-2.6-xen-sparse/include/asm-ia64/page.h Fri Aug 18 15:01:04
2006 -0600
+++ b/linux-2.6-xen-sparse/include/asm-ia64/page.h Tue Aug 22 14:10:21
2006 +0900
@@ -224,12 +224,11 @@ get_order (unsigned long size)
#ifndef __ASSEMBLY__
#ifdef CONFIG_XEN
-#define INVALID_P2M_ENTRY (~0UL)
+#include asm/maddr.h
#include linux/kernel.h
#include asm/hypervisor.h
#include xen/features.h // to compile netback, netfront
-typedef unsigned long maddr_t; // to compile netback, netfront
/*
* XXX hack!
@@ -268,69 +267,6 @@ extern struct address_space xen_ia64_for
})
#define HAVE_ARCH_FREE_PAGE
-/* XXX xen page size != page size */
-
-static inline unsigned long
-pfn_to_mfn_for_dma(unsigned long pfn)
-{
- unsigned long mfn;
- mfn = HYPERVISOR_phystomach(pfn);
- BUG_ON(mfn == 0); // XXX
- BUG_ON(mfn == INVALID_P2M_ENTRY); // XXX
- BUG_ON(mfn == INVALID_MFN);
- return mfn;
-}
-
-static inline unsigned long
-phys_to_machine_for_dma(unsigned long phys)
-{
- unsigned long machine =
- pfn_to_mfn_for_dma(phys PAGE_SHIFT) PAGE_SHIFT;
- machine |= (phys ~PAGE_MASK);
- return machine;
-}
-
-static inline unsigned long
-mfn_to_pfn_for_dma(unsigned long mfn)
-{
- unsigned long pfn;
- pfn = HYPERVISOR_machtophys(mfn);
- BUG_ON(pfn == 0);
- //BUG_ON(pfn == INVALID_M2P_ENTRY);
- return pfn;
-}
-
-static inline unsigned long
-machine_to_phys_for_dma(unsigned long machine)
-{
- unsigned long phys =
- mfn_to_pfn_for_dma(machine PAGE_SHIFT) PAGE_SHIFT;
- phys |= (machine ~PAGE_MASK);
- return phys;
-}
-
-#define set_phys_to_machine(pfn, mfn) do { } while (0)
-#define xen_machphys_update(mfn, pfn) do { } while (0)
-
-/* XXX to compile set_phys_to_machine(vaddr, FOREIGN_FRAME(m)) */
-#define FOREIGN_FRAME(m)(INVALID_P2M_ENTRY)
-
-#define mfn_to_pfn(mfn)(mfn)
-#define mfn_to_virt(mfn) (__va((mfn) PAGE_SHIFT))
-#define pfn_to_mfn(pfn)(pfn)
-#define virt_to_mfn(virt) (__pa(virt) PAGE_SHIFT)
-#define virt_to_machine(virt) __pa(virt) // for tpmfront.c
-
-static inline unsigned long
-mfn_to_local_pfn(unsigned long mfn)
-{
- extern unsigned long max_mapnr;
- unsigned long pfn = mfn_to_pfn_for_dma(mfn);
- if (!pfn_valid(pfn))
- return INVALID_P2M_ENTRY;
- return pfn;
-}
-
#endif /* CONFIG_XEN */
#endif /* __ASSEMBLY__ */
diff -r d42e9a6f5378 -r 5c75dc35f1ba
linux-2.6-xen-sparse/include/asm-ia64/maddr.h
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux-2.6-xen-sparse/include/asm-ia64/maddr.h Tue Aug 22
Re: [Xen-ia64-devel] Catch up for PV_on_HVM
Hi, You (alex.williamson) said: On Fri, 2006-08-18 at 21:45 +0900, DOI Tsunehisa wrote: We want to catch up this common feature. We don't complete to catch up, yet. But I'll post patches which we wrote already. This patch includes: * catch up `hvm_op fixup' - This patch modifies HYPERVISOR_hvm_op(). * catch up `hvm_inter' - This patch adds support for sending event channel interrupts to VT-i guests. * catch up `hvm_op_hypercall' - This patch includes HYPERVISOR_hvm_op() stabs for linux. We'll catch up other features, as soon as possible. Are these for the current xen-ia64-unstable.hg tree, or do we need to merge with xen-unstable.hg first to pull more of the changes you listed? For the current xen-ia64-unstable.hg tree. These patches are not effected curretly, because it is not used, except PV-on-HVM. Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] catch up new hypercall HYPERVISR_hvm_op for IPF
Hi all,
We are porting Steven Smith's para drivers for full-VM to IPF.
In the xen-unstable.hg:
* cs:10911-10912:
+ implement new hypercall called HYPERVISOR_hvm_op.
+ the hypercall has new feature about set/get params.
We want to catch up this common feature. Thus I'll post the
catch-up patch for IPF. This patch includes:
* append new hypercall HYPSERVISOR_hvm_op for IPF
- This patch only includes same feature of x86.
- We will plan to append the archtecture specific feature for IPF,
but not yet.
* append xc_set_hvm_param() to xc_ia64_hvm_build.c
- This patch includes same feature of x86, but is not used, yet.
* a part of xen-unstable.hg(cs:10911)
- This patch is added only for compiling on IPF.
- If xen-ia64-unstable.hg will be synchronized with
xen-unstable.hg(cs:10911), the patch is not needed.
Thanks,
- Tsunehisa Doi
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 47afb9c05e3e93cadcd50c4a06785dcb088e5bf3
# Parent c3e20511c74508c78b4b15e4c3f94f84ce1c3c40
append HYPERVISOR_hvm_op for IPF
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
Signed-off-by: Tomonari Horikoshi [EMAIL PROTECTED]
diff -r c3e20511c745 -r 47afb9c05e3e xen/arch/ia64/vmx/vmx_hypercall.c
--- a/xen/arch/ia64/vmx/vmx_hypercall.c Fri Aug 04 09:32:00 2006 -0600
+++ b/xen/arch/ia64/vmx/vmx_hypercall.c Mon Aug 07 21:01:37 2006 +0900
@@ -35,4 +35,53 @@
#include asm/dom_fw.h
#include xen/domain.h
-/* This file will include the hypercall code for VT-i domain, soon. */
+long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
+{
+long rc = 0;
+
+switch (op) {
+case HVMOP_set_param:
+case HVMOP_get_param:
+{
+ struct xen_hvm_param a;
+ struct domain *d;
+
+ if (copy_from_guest(a, arg, 1))
+ return -EFAULT;
+
+ if (a.index 0 || a.index HVM_NR_PARAMS) {
+ return -EINVAL;
+ }
+
+ if (a.domid == DOMID_SELF) {
+ get_knownalive_domain(current-domain);
+ d = current-domain;
+ }
+ else if (IS_PRIV(current-domain)) {
+ d = find_domain_by_id(a.domid);
+ if (!d) {
+ return -ESRCH;
+ }
+ }
+ else {
+ return -EPERM;
+ }
+
+ if (op == HVMOP_set_param) {
+ rc = 0;
+ d-arch.hvm_domain.params[a.index] = a.value;
+ }
+ else {
+ rc = d-arch.hvm_domain.params[a.index];
+ }
+
+ put_domain(d);
+ return rc;
+}
+
+default:
+ DPRINTK(Bad HVM op %ld.\n, op);
+ rc = -EINVAL;
+}
+return rc;
+}
diff -r c3e20511c745 -r 47afb9c05e3e xen/arch/ia64/xen/hypercall.c
--- a/xen/arch/ia64/xen/hypercall.c Fri Aug 04 09:32:00 2006 -0600
+++ b/xen/arch/ia64/xen/hypercall.c Mon Aug 07 21:01:37 2006 +0900
@@ -70,7 +70,7 @@ hypercall_t ia64_hypercall_table[] =
(hypercall_t)do_ni_hypercall, /* */
(hypercall_t)do_event_channel_op,
(hypercall_t)do_physdev_op,
- (hypercall_t)do_ni_hypercall, /* */
+ (hypercall_t)do_hvm_op, /* */
(hypercall_t)do_ni_hypercall, /* */ /* 35 */
(hypercall_t)do_ni_hypercall, /* */
(hypercall_t)do_ni_hypercall, /* */
diff -r c3e20511c745 -r 47afb9c05e3e xen/include/asm-ia64/vmx_platform.h
--- a/xen/include/asm-ia64/vmx_platform.h Fri Aug 04 09:32:00 2006 -0600
+++ b/xen/include/asm-ia64/vmx_platform.h Mon Aug 07 21:01:37 2006 +0900
@@ -20,6 +20,7 @@
#define __ASM_IA64_VMX_PLATFORM_H__
#include public/xen.h
+#include public/hvm/params.h
#include public/arch-ia64.h
#include asm/hvm/vioapic.h
struct mmio_list;
@@ -27,6 +28,7 @@ typedef struct virtual_platform_def {
unsigned long shared_page_va;
unsigned long pib_base;
unsigned char xtp;
+unsigned long params[HVM_NR_PARAMS];
struct mmio_list*mmio;
/* One IOSAPIC now... */
struct hvm_vioapic vioapic;
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID f9e44dceef9e4a6d809e2d4f7b81dea96bc1c5a5
# Parent 47afb9c05e3e93cadcd50c4a06785dcb088e5bf3
append xc_set_hvm_param for IPF
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
Signed-off-by: Tomonari Horikoshi [EMAIL PROTECTED]
diff -r c3e20511c745 tools/libxc/ia64/xc_ia64_hvm_build.c
--- a/tools/libxc/ia64/xc_ia64_hvm_build.c Fri Aug 04 09:32:00 2006 -0600
+++ b/tools/libxc/ia64/xc_ia64_hvm_build.c Mon Aug 07 22:15:47 2006 +0900
@@ -6,6 +6,7 @@
#include zlib.h
#include xen/arch-ia64.h
#include xen/hvm/ioreq.h
+#include xen/hvm/params.h
static int
xc_ia64_copy_to_domain_pages(int xc_handle, uint32_t domid, void* src_page,
@@ -38,6 +39,30 @@ error_out:
error_out:
free(page_array);
return -1;
+}
+
+
+static void
+xc_set_hvm_param(int handle, domid_t dom, int param, unsigned long value)
+{
+DECLARE_HYPERCALL;
+xen_hvm_param_t arg;
+int rc;
+
+
Re: [Xen-ia64-devel] catch up new hypercall HYPERVISR_hvm_op for IPF
Hi, Thank you for your comment. You (Tristan.Gingold) said: I'd prefer do_hvm_op to be in xen/ and not in vmx/. All the hypercalls are there. In x86 code, do_hvm_op is implemented in hvm/hvm.c, thus we have implemented in vmx/. And we will implement IPF specific feature to port paravirtualized driver for VT-i domain. It is a little bit strange that HVMOP_get_param returns the parameter by value and not in memory. I suppose you have copied x86 hypercalls here. index can't be 0 as it is unsigned. You are right. We have copied it from x86 code. For porting, we need that interface should be same with x86, I think. -- ÅÚÈî¤Ç¤·¤¿¡¥¡¥¡¥ ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] catch up new hypercall HYPERVISR_hvm_op for IPF
Hi,
[EMAIL PROTECTED] wrote:
Sorry!! I refered old version of x86 code. Currently, it modified.
I will correct, soon.
I modified it.
Thanks,
- Tsunehisa Doi
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 39feb5061f88cefe00548879459c01e547bc9eec
# Parent 571022d5afa2627e0662f5916edb947d362f
append HYPERVISOR_hvm_op for IPF
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
Signed-off-by: Tomonari Horikoshi [EMAIL PROTECTED]
diff -r 571022d5afa2 -r 39feb5061f88 xen/arch/ia64/vmx/vmx_hypercall.c
--- a/xen/arch/ia64/vmx/vmx_hypercall.c Mon Aug 07 14:11:58 2006 -0600
+++ b/xen/arch/ia64/vmx/vmx_hypercall.c Tue Aug 08 12:26:02 2006 +0900
@@ -35,4 +35,53 @@
#include asm/dom_fw.h
#include xen/domain.h
-/* This file will include the hypercall code for VT-i domain, soon. */
+long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
+{
+long rc = 0;
+
+switch (op) {
+case HVMOP_set_param:
+case HVMOP_get_param:
+{
+ struct xen_hvm_param a;
+ struct domain *d;
+
+ if (copy_from_guest(a, arg, 1))
+ return -EFAULT;
+
+ if (a.index HVM_NR_PARAMS) {
+ return -EINVAL;
+ }
+
+ if (a.domid == DOMID_SELF) {
+ get_knownalive_domain(current-domain);
+ d = current-domain;
+ }
+ else if (IS_PRIV(current-domain)) {
+ d = find_domain_by_id(a.domid);
+ if (!d) {
+ return -ESRCH;
+ }
+ }
+ else {
+ return -EPERM;
+ }
+
+ if (op == HVMOP_set_param) {
+ rc = 0;
+ d-arch.hvm_domain.params[a.index] = a.value;
+ }
+ else {
+ rc = d-arch.hvm_domain.params[a.index];
+ }
+
+ put_domain(d);
+ return rc;
+}
+
+default:
+ DPRINTK(Bad HVM op %ld.\n, op);
+ rc = -ENOSYS;
+}
+return rc;
+}
diff -r 571022d5afa2 -r 39feb5061f88 xen/arch/ia64/xen/hypercall.c
--- a/xen/arch/ia64/xen/hypercall.c Mon Aug 07 14:11:58 2006 -0600
+++ b/xen/arch/ia64/xen/hypercall.c Tue Aug 08 12:26:02 2006 +0900
@@ -70,7 +70,7 @@ hypercall_t ia64_hypercall_table[] =
(hypercall_t)do_ni_hypercall, /* */
(hypercall_t)do_event_channel_op,
(hypercall_t)do_physdev_op,
- (hypercall_t)do_ni_hypercall, /* */
+ (hypercall_t)do_hvm_op, /* */
(hypercall_t)do_ni_hypercall, /* */ /* 35 */
(hypercall_t)do_ni_hypercall, /* */
(hypercall_t)do_ni_hypercall, /* */
diff -r 571022d5afa2 -r 39feb5061f88 xen/include/asm-ia64/vmx_platform.h
--- a/xen/include/asm-ia64/vmx_platform.h Mon Aug 07 14:11:58 2006 -0600
+++ b/xen/include/asm-ia64/vmx_platform.h Tue Aug 08 12:26:02 2006 +0900
@@ -20,6 +20,7 @@
#define __ASM_IA64_VMX_PLATFORM_H__
#include public/xen.h
+#include public/hvm/params.h
#include public/arch-ia64.h
#include asm/hvm/vioapic.h
struct mmio_list;
@@ -27,6 +28,7 @@ typedef struct virtual_platform_def {
unsigned long shared_page_va;
unsigned long pib_base;
unsigned char xtp;
+unsigned long params[HVM_NR_PARAMS];
struct mmio_list*mmio;
/* One IOSAPIC now... */
struct hvm_vioapic vioapic;
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Enabling hypercalls from VT-i domain
Hi all,
My name is Tsunehisa Doi.
We are porting Steven Smith's para drivers for full-VM to IPF.
In the xen-unstable.hg (cs: 10883-10885), it's enabling the hypercall
from HVM domain. Thus, I will post the enabling patch for IPF. This
patch includes:
+ cleanup the hypercall handling code for VT-i domain
- delete the dead code in vmx_hypercall.c and vmx_ivt.S
- the code is not used now, I think.
* It's called with `break 0x1100' instruction. (current 0x1000)
* The hypercall table for VT-i domain doesn't match the
hypercall number.
* The register used for hypercall are different with current
version. (r16-r20 vs. r2,r4-r18)
+ enabling hypercalls from VT-i domain
- modify the checker to permit hypercalls from VT-i domain.
Thanks,
- Tsunehisa Doi
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID aafdb9899c4179b1221fc59a46600973ba630476
# Parent 4acc6d51f3893d2b0c33c021f459ac12482858d9
cleanup the hypercall handling code for VT-i domain
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
Signed-off-by: Tomonari Horikoshi [EMAIL PROTECTED]
Signed-off-by: Masaki Kanno [EMAIL PROTECTED]
diff -r 4acc6d51f389 -r aafdb9899c41 xen/arch/ia64/vmx/vmx_hypercall.c
--- a/xen/arch/ia64/vmx/vmx_hypercall.c Tue Aug 01 14:58:20 2006 -0600
+++ b/xen/arch/ia64/vmx/vmx_hypercall.c Wed Aug 02 17:48:27 2006 +0900
@@ -35,180 +35,4 @@
#include asm/dom_fw.h
#include xen/domain.h
-extern long do_sched_op_compat(int cmd, unsigned long arg);
-
-void hyper_not_support(void)
-{
-VCPU *vcpu=current;
-vcpu_set_gr(vcpu, 8, -1, 0);
-vmx_vcpu_increment_iip(vcpu);
-}
-
-void hyper_mmu_update(void)
-{
-VCPU *vcpu=current;
-u64 r32,r33,r34,r35,ret;
-vcpu_get_gr_nat(vcpu,16,r32);
-vcpu_get_gr_nat(vcpu,17,r33);
-vcpu_get_gr_nat(vcpu,18,r34);
-vcpu_get_gr_nat(vcpu,19,r35);
-ret=vmx_do_mmu_update((mmu_update_t*)r32,r33,(u64 *)r34,r35);
-vcpu_set_gr(vcpu, 8, ret, 0);
-vmx_vcpu_increment_iip(vcpu);
-}
-
-void hyper_dom_mem_op(void)
-{
-VCPU *vcpu=current;
-u64 r32,r33,r34,r35,r36;
-u64 ret;
-vcpu_get_gr_nat(vcpu,16,r32);
-vcpu_get_gr_nat(vcpu,17,r33);
-vcpu_get_gr_nat(vcpu,18,r34);
-vcpu_get_gr_nat(vcpu,19,r35);
-vcpu_get_gr_nat(vcpu,20,r36);
-//ret=do_dom_mem_op(r32,(u64 *)r33,r34,r35,r36);
-ret = 0;
-printf(do_dom_mem return value: %lx\n, ret);
-vcpu_set_gr(vcpu, 8, ret, 0);
-
-/* Hard to define a special return value to indicate hypercall restart.
- * So just add a new mark, which is SMP safe
- */
-if (vcpu-arch.hypercall_continuation == 1)
- vcpu-arch.hypercall_continuation = 0;
-else
- vmx_vcpu_increment_iip(vcpu);
-}
-
-
-void hyper_sched_op_compat(void)
-{
-VCPU *vcpu=current;
-u64 r32,r33,ret;
-vcpu_get_gr_nat(vcpu,16,r32);
-vcpu_get_gr_nat(vcpu,17,r33);
-ret=do_sched_op_compat(r32,r33);
-vcpu_set_gr(vcpu, 8, ret, 0);
-
-vmx_vcpu_increment_iip(vcpu);
-}
-
-void hyper_dom0_op(void)
-{
-VCPU *vcpu=current;
-u64 r32,ret;
-vcpu_get_gr_nat(vcpu,16,r32);
-ret=do_dom0_op(guest_handle_from_ptr(r32, dom0_op_t));
-vcpu_set_gr(vcpu, 8, ret, 0);
-
-vmx_vcpu_increment_iip(vcpu);
-}
-
-void hyper_event_channel_op_compat(void)
-{
-VCPU *vcpu=current;
-u64 r32,ret;
-vcpu_get_gr_nat(vcpu,16,r32);
-ret=do_event_channel_op_compat(guest_handle_from_ptr(r32, evtchn_op_t));
-vcpu_set_gr(vcpu, 8, ret, 0);
-vmx_vcpu_increment_iip(vcpu);
-}
-
-void hyper_xen_version(void)
-{
-VCPU *vcpu=current;
-u64 r32,r33,ret;
-vcpu_get_gr_nat(vcpu,16,r32);
-vcpu_get_gr_nat(vcpu,17,r33);
-ret=do_xen_version((int )r32,guest_handle_from_ptr(r33, void));
-vcpu_set_gr(vcpu, 8, ret, 0);
-vmx_vcpu_increment_iip(vcpu);
-}
-/*
-static int do_lock_page(VCPU *vcpu, u64 va, u64 lock)
-{
-ia64_rr rr;
-thash_cb_t *hcb;
-hcb = vmx_vcpu_get_vtlb(vcpu);
-rr = vmx_vcpu_rr(vcpu, va);
-return thash_lock_tc(hcb, va ,1Urr.ps, rr.rid, DSIDE_TLB, lock);
-}
- */
-/*
- * Lock guest page in vTLB, so that it's not relinquished by recycle
- * session when HV is servicing that hypercall.
- */
-
-/*
-void hyper_lock_page(void)
-{
-//TODO:
-VCPU *vcpu=current;
-u64 va,lock, ret;
-vcpu_get_gr_nat(vcpu,16,va);
-vcpu_get_gr_nat(vcpu,17,lock);
-ret=do_lock_page(vcpu, va, lock);
-vcpu_set_gr(vcpu, 8, ret, 0);
-
-vmx_vcpu_increment_iip(vcpu);
-}
- */
-
-static int do_set_shared_page(VCPU *vcpu, u64 gpa)
-{
-u64 o_info;
-struct domain *d = vcpu-domain;
-struct vcpu *v;
-struct page_info *page;
-if(vcpu-domain!=dom0)
-return -EPERM;
-o_info = (u64)vcpu-domain-shared_info;
- again:
-d-shared_info= (shared_info_t *)domain_mpa_to_imva(vcpu-domain, gpa);
-page = virt_to_page(d-shared_info);
-if (get_page(page, d) == 0)
-goto again;
-
-/* Copy existing shared info into new page */
-if (o_info) {
-
Re: [Xen-ia64-devel] Enabling hypercalls from VT-i domain
Hi Tristan,
Thank you for your comment.
You (Tristan.Gingold) said:
Le Mercredi 02 Aot 2006 12:34, DOI Tsunehisa a crit :
Hi all,
My name is Tsunehisa Doi.
We are porting Steven Smith's para drivers for full-VM to IPF.
In the xen-unstable.hg (cs: 10883-10885), it's enabling the hypercall
from HVM domain. Thus, I will post the enabling patch for IPF. This
patch includes:
+ cleanup the hypercall handling code for VT-i domain
- delete the dead code in vmx_hypercall.c and vmx_ivt.S
- the code is not used now, I think.
* It's called with `break 0x1100' instruction. (current 0x1000)
* The hypercall table for VT-i domain doesn't match the
hypercall number.
* The register used for hypercall are different with current
version. (r16-r20 vs. r2,r4-r18)
+ enabling hypercalls from VT-i domain
- modify the checker to permit hypercalls from VT-i domain.
Thanks,
- Tsunehisa Doi
Hi and welcome!
diff -r aafdb9899c41 -r e8de7b1474c0 xen/arch/ia64/xen/hypercall.c
--- a/xen/arch/ia64/xen/hypercall.c Wed Aug 02 17:48:27 2006 +0900
+++ b/xen/arch/ia64/xen/hypercall.c Wed Aug 02 17:52:43 2006 +0900
@@ -319,7 +319,7 @@ ia64_hypercall (struct pt_regs *regs)
/* Hypercalls are only allowed by kernel.
Kernel checks memory accesses. */
- if (privlvl != 2) {
+ if ((regs-cr_ipsr IA64_PSR_VM) ? (privlvl != 0) : (privlvl != 2)) {
/* FIXME: Return a better error value ?
Reflection ? Illegal operation ? */
regs-r8 = -1;
You'd better to use the VMX_DOMAIN macro here.
I agree. I should use the VMX_DOMAIN macro except for '(regs-..
IA64_PSR_VM)'.
I'll modify it.
I think you'd better not to call ia64_hypercall from VTi side if cpl != 0.
I worry about this point. The ia64_hypercall is called from ia64_handle_break
without cpl != 2 checking, thus it's checked a privilege level of the caller for
para-domain, I think. I believe that the both codes should be symmetrical.
What do you think about this point ?
Thanks,
-- Tsunehisa Doi
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Enabling hypercalls from VT-i domain
Hi all,
I modified the code using VMX_DOMAIN macro.
Thanks,
-- Tsunehisa Doi
[EMAIL PROTECTED] wrote:
Hi Tristan,
Thank you for your comment.
You (Tristan.Gingold) said:
Le Mercredi 02 Aot 2006 12:34, DOI Tsunehisa a crit :
Hi all,
My name is Tsunehisa Doi.
We are porting Steven Smith's para drivers for full-VM to IPF.
In the xen-unstable.hg (cs: 10883-10885), it's enabling the hypercall
from HVM domain. Thus, I will post the enabling patch for IPF. This
patch includes:
+ cleanup the hypercall handling code for VT-i domain
- delete the dead code in vmx_hypercall.c and vmx_ivt.S
- the code is not used now, I think.
* It's called with `break 0x1100' instruction. (current 0x1000)
* The hypercall table for VT-i domain doesn't match the
hypercall number.
* The register used for hypercall are different with current
version. (r16-r20 vs. r2,r4-r18)
+ enabling hypercalls from VT-i domain
- modify the checker to permit hypercalls from VT-i domain.
Thanks,
- Tsunehisa Doi
Hi and welcome!
diff -r aafdb9899c41 -r e8de7b1474c0 xen/arch/ia64/xen/hypercall.c
--- a/xen/arch/ia64/xen/hypercall.c Wed Aug 02 17:48:27 2006 +0900
+++ b/xen/arch/ia64/xen/hypercall.c Wed Aug 02 17:52:43 2006 +0900
@@ -319,7 +319,7 @@ ia64_hypercall (struct pt_regs *regs)
/* Hypercalls are only allowed by kernel.
Kernel checks memory accesses. */
- if (privlvl != 2) {
+ if ((regs-cr_ipsr IA64_PSR_VM) ? (privlvl != 0) : (privlvl != 2))
{
/* FIXME: Return a better error value ?
Reflection ? Illegal operation ? */
regs-r8 = -1;
You'd better to use the VMX_DOMAIN macro here.
I agree. I should use the VMX_DOMAIN macro except for '(regs-..
IA64_PSR_VM)'.
I'll modify it.
I think you'd better not to call ia64_hypercall from VTi side if cpl != 0.
I worry about this point. The ia64_hypercall is called from
ia64_handle_break
without cpl != 2 checking, thus it's checked a privilege level of the caller
for
para-domain, I think. I believe that the both codes should be symmetrical.
What do you think about this point ?
Thanks,
-- Tsunehisa Doi
Signed-off-by: Tsunehisa Doi [EMAIL PROTECTED]
Signed-off-by: Tomonari Horikoshi [EMAIL PROTECTED]
Signed-off-by: Masaki Kanno [EMAIL PROTECTED]
diff -r aafdb9899c41 -r 483311d15abc xen/arch/ia64/xen/hypercall.c
--- a/xen/arch/ia64/xen/hypercall.c Wed Aug 02 17:48:27 2006 +0900
+++ b/xen/arch/ia64/xen/hypercall.c Wed Aug 02 21:35:43 2006 +0900
@@ -319,7 +319,7 @@ ia64_hypercall (struct pt_regs *regs)
/* Hypercalls are only allowed by kernel.
Kernel checks memory accesses. */
- if (privlvl != 2) {
+ if (VMX_DOMAIN(v) ? (privlvl != 0) : (privlvl != 2)) {
/* FIXME: Return a better error value ?
Reflection ? Illegal operation ? */
regs-r8 = -1;
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
