Re: [Xen-ia64-devel] RE: PATCH: merge iva
Le Mercredi 14 Juin 2006 18:48, Magenheimer, Dan (HP Labs Fort Collins) a écrit : [...] I wasn't fighting the specific patch as much as providing history. The possibility of vcr.iva being used maliciously is very small but vBlades evolved from a security-focused project so validating all privileged registers to eliminate security holes was an early vBlades objective. Thank you for the historical view. To contrive an example, if an attacker could somehow change vcr.iva, he might be able to cause arbitrary user code to be executed at PL2. I still don't understand this example: privregs are only accessible at PL2. So the attacker has to be in PL2. This seems to be moot. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH 0/7][SMP] SMP support
Le Jeudi 15 Juin 2006 04:58, Isaku Yamahata a écrit : SMP support of VP model. This patch series resolves races in VP model. [PATCH 1/7][SMP] add volatile to mpt_table [PATCH 2/7][SMP] add volatile to p2m table pte entry [PATCH 3/7][SMP] add INVALID_MFN check to dom0vp_zap_physmap() [PATCH 4/7][SMP] fix races caused by p2m entry update [PATCH 5/7][SMP] add get_page() to prevent from freeing page [PATCH 6/7][SMP] remove unnecessary vtlb_lock [PATCH 7/7][SMP] add comments on smp I think it is a good idea to add the comments. I hope we will update them. Thank you for your work. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: fix garbage in irq_ia64.c kernel message
Hi,
this simply fixes some garbage.
Tested by booting dom0.
Tristan.
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 01bc4785e5c7656a7cbf4eb00d9f6f4a640bb52d
# Parent 6838c14692df784c96f8fc28416e1c33b0dca74a
Fix garbage in kernel messages.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 6838c14692df -r 01bc4785e5c7 linux-2.6-xen-sparse/arch/ia64/kernel/irq_ia64.c
--- a/linux-2.6-xen-sparse/arch/ia64/kernel/irq_ia64.c Thu Jun 15 08:54:15 2006 +0200
+++ b/linux-2.6-xen-sparse/arch/ia64/kernel/irq_ia64.c Thu Jun 15 10:36:10 2006 +0200
@@ -284,7 +284,6 @@ static void
static void
xen_register_percpu_irq (unsigned int irq, struct irqaction *action, int save)
{
- char name[15];
unsigned int cpu = smp_processor_id();
int ret = 0;
@@ -295,21 +294,23 @@ xen_register_percpu_irq (unsigned int ir
ret = bind_virq_to_irqhandler(VIRQ_ITC, cpu,
action-handler, action-flags,
timer_name[cpu], action-dev_id);
- printk(KERN_INFO register VIRQ_ITC (%s) to xen irq (%d)\n, name, ret);
+ printk(KERN_INFO register VIRQ_ITC (%s) to xen irq (%d)\n, timer_name[cpu], ret);
break;
case IA64_IPI_RESCHEDULE:
sprintf(resched_name[cpu], %s%d, action-name, cpu);
ret = bind_ipi_to_irqhandler(RESCHEDULE_VECTOR, cpu,
action-handler, action-flags,
resched_name[cpu], action-dev_id);
- printk(KERN_INFO register RESCHEDULE_VECTOR (%s) to xen irq (%d)\n, name, ret);
+ printk(KERN_INFO register RESCHEDULE_VECTOR (%s) to xen irq (%d)\n, resched_name[cpu], ret);
break;
case IA64_IPI_VECTOR:
sprintf(ipi_name[cpu], %s%d, action-name, cpu);
ret = bind_ipi_to_irqhandler(IPI_VECTOR, cpu,
action-handler, action-flags,
ipi_name[cpu], action-dev_id);
- printk(KERN_INFO register IPI_VECTOR (%s) to xen irq (%d)\n, name, ret);
+ printk(KERN_INFO register IPI_VECTOR (%s) to xen irq (%d)\n, ipi_name[cpu], ret);
+ break;
+ case IA64_SPURIOUS_INT_VECTOR:
break;
default:
printk(KERN_WARNING Percpu irq %d is unsupported by xen!\n, irq);
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] work around for skbuff_ctor() on non-privileged domain
work around for skbuff_ctor() on non-privileged domain
populate physmap/increase reservation hypercall fail with
extent order 0 on non-privileged domain.
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID e9ad96356afba6e2a7c30fcff7efef008345723a
# Parent 49b93835c261a6e74c7c51c16be9269511732d43
work around for skbuff_ctor() on non-privileged domain
populate physmap/increase reservation hypercall fail with
extent order 0 on non-privileged domain.
PATCHNAME: work_around_for_skbuff_ctor
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r 49b93835c261 -r e9ad96356afb
linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c
--- a/linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c Thu Jun 15 18:47:31
2006 +0900
+++ b/linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c Thu Jun 15 19:35:49
2006 +0900
@@ -76,6 +76,15 @@ ia64_xenmem_reservation_op(unsigned long
}
break;
}
+ if (tmp_ret == 0) {
+ //XXX dirty work around for skbuff_ctor()
+ //of a non-privileged domain,
+ if ((op == XENMEM_increase_reservation ||
+op == XENMEM_populate_physmap)
+ !(xen_start_info-flags SIF_PRIVILEGED)
+ reservation.extent_order 0)
+ return ret;
+ }
frame_list += tmp_ret;
nr_extents -= tmp_ret;
ret += tmp_ret;
@@ -165,7 +174,12 @@ HYPERVISOR_populate_physmap(unsigned lon
};
set_xen_guest_handle(reservation.extent_start, gpfn);
ret = HYPERVISOR_memory_op(XENMEM_populate_physmap, reservation);
- BUG_ON(ret != 1);
+ // it may fail on non-privileged domain with extent_order 0.
+ BUG_ON(ret != 1
+ !(ret == 0 !(xen_start_info-flags SIF_PRIVILEGED)
+extent_order 0));
+ if (ret != 1)
+ return -EINVAL;//XXX
return 0;
}
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [patch] [4/4] Support INIT handler of xen
Hi, Alex Thank you for your comments. OK. I'll send the small new patch. I'll go in arch/ia64/xen. Best Regards, Akio Takebe On Thu, 2006-06-15 at 06:36 +0900, Akio Takebe wrote: Hi, Alex I forgot README.origin update, I'm sorry. The first I made a small patch with cutpaste without ifdef. But I remade a big patch with ifdef, because I think we may leverage the original mac code. I don't know this leverage, because another fujitsu member will make other mca code. I think my ifdef is ugly, so I want to remake non-ifdef patch. But I refer linux code, can I make xen-mca code wiht cutpaste without ifdef in arch/ia64/linux-xen? Hi Akio, The ifdefs are kind of ugly, and I wasn't sure how many lines of code were actually left enabled in those files. How many lines of code was the original cutpaste version? If only a few hundred lines, maybe it does make sense to separate it out. I think it should probably go in arch/ia64/xen though, not linux-xen. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: PATCH, was Re: [Xen-ia64-devel] Re: PATCH: enable Xen compilation with debug=y
Le Jeudi 15 Juin 2006 16:53, Alex Williamson a écrit :
On Thu, 2006-06-15 at 10:07 +0200, Tristan Gingold wrote:
Le Jeudi 15 Juin 2006 00:24, Alex Williamson a écrit :
On Wed, 2006-06-14 at 11:48 +0200, Tristan Gingold wrote:
Hi,
this patch fixes a few issue, so that make debug=y works (in Xen).
I think it is expected by Fedora.
Tested by booting dom0 (debug=y).
Tested by compiling without debug=y.
Hi Tristan,
This doesn't build for me, there are still things including
asm/hardirq.h. Did you need me to make a hardirq.h in linux-null?
Sorry, I forget an hg add.
Here is the updated patch.
Hi Tristan,
I'm still a little confused about the hardirq.h stuff. Why drop
include/asm-ia64/linux/asm/hardirq.h only to split it out into
include/asm-ia64/linux-xen/linux/hardirq.h and a new
include/asm-ia64/hardirq.h?
Xen expects an asm/hardirq.h. The later must have some definitions of
linux/hardirq.h
Linux headers expect a linux/hardirq.h
You might prefer the attached patch: it does not modify
linux-xen/linux/hardirq.h
(tested by compiling with and without debug=y)
BTW, this latest patch doesn't remove
include/asm-ia64/linux/asm/hardirq.h, but I assume that's still
intended. Thanks,
Yes! (sorry)
Tristan.# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 6f964c7b34d4ae61bdbd817cfcd4101cb838c0df
# Parent d33add81096b057f98fa740ab88d6c17426f8d68
Xen can now be compiled with debug=y
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r d33add81096b -r 6f964c7b34d4 xen/arch/ia64/vmx/vlsapic.c
--- a/xen/arch/ia64/vmx/vlsapic.c Wed Jun 14 16:05:45 2006 -0600
+++ b/xen/arch/ia64/vmx/vlsapic.c Thu Jun 15 16:01:57 2006 +0200
@@ -388,7 +388,7 @@ void vlsapic_reset(VCPU *vcpu)
vcpu-arch.arch_vmx.vlapic.vcpu = vcpu;
hvm_vioapic_add_lapic(vcpu-arch.arch_vmx.vlapic, vcpu);
#endif
-DPRINTK(VLSAPIC inservice base=%lp\n, VLSAPIC_INSVC(vcpu,0) );
+DPRINTK(VLSAPIC inservice base=%p\n, VLSAPIC_INSVC(vcpu,0) );
}
/*
diff -r d33add81096b -r 6f964c7b34d4 xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.c Wed Jun 14 16:05:45 2006 -0600
+++ b/xen/arch/ia64/xen/domain.c Thu Jun 15 16:01:57 2006 +0200
@@ -202,7 +202,7 @@ void startup_cpu_idle_loop(void)
void startup_cpu_idle_loop(void)
{
/* Just some sanity to ensure that the scheduler is set up okay. */
- ASSERT(current-domain == IDLE_DOMAIN_ID);
+ ASSERT(current-domain-domain_id == IDLE_DOMAIN_ID);
raise_softirq(SCHEDULE_SOFTIRQ);
continue_cpu_idle_loop();
diff -r d33add81096b -r 6f964c7b34d4 xen/arch/ia64/xen/xenmisc.c
--- a/xen/arch/ia64/xen/xenmisc.c Wed Jun 14 16:05:45 2006 -0600
+++ b/xen/arch/ia64/xen/xenmisc.c Thu Jun 15 16:01:57 2006 +0200
@@ -167,6 +167,10 @@ void arch_dump_domain_info(struct domain
{
}
+void audit_domains_key(unsigned char key)
+{
+}
+
void panic_domain(struct pt_regs *regs, const char *fmt, ...)
{
va_list args;
diff -r d33add81096b -r 6f964c7b34d4 xen/include/asm-ia64/linux/asm/README.origin
--- a/xen/include/asm-ia64/linux/asm/README.origin Wed Jun 14 16:05:45 2006 -0600
+++ b/xen/include/asm-ia64/linux/asm/README.origin Thu Jun 15 16:01:57 2006 +0200
@@ -18,7 +18,6 @@ dma.h - linux/include/asm-ia64/dma.h
dma.h - linux/include/asm-ia64/dma.h
fpswa.h - linux/include/asm-ia64/fpswa.h
fpu.h - linux/include/asm-ia64/fpu.h
-hardirq.h - linux/include/asm-ia64/hardirq.h
hdreg.h - linux/include/asm-ia64/hdreg.h
hw_irq.h - linux/include/asm-ia64/hw_irq.h
intrinsics.h - linux/include/asm-ia64/intrinsics.h
diff -r d33add81096b -r 6f964c7b34d4 xen/include/asm-ia64/vmx_vpd.h
--- a/xen/include/asm-ia64/vmx_vpd.h Wed Jun 14 16:05:45 2006 -0600
+++ b/xen/include/asm-ia64/vmx_vpd.h Thu Jun 15 16:01:57 2006 +0200
@@ -102,7 +102,7 @@ struct arch_vmx_struct {
#define vmx_schedule_tail(next) \
(next)-thread.arch_vmx.arch_vmx_schedule_tail((next))
-#define VMX_DOMAIN(d) d-arch.arch_vmx.flags
+#define VMX_DOMAIN(v) v-arch.arch_vmx.flags
#define ARCH_VMX_IO_WAIT3 /* Waiting for I/O completion */
#define ARCH_VMX_INTR_ASSIST4 /* Need DM's assist to issue intr */
@@ -111,29 +111,9 @@ struct arch_vmx_struct {
#define VMX_DEBUG 1
#if VMX_DEBUG
-#define DBG_LEVEL_0 (1 0)
-#define DBG_LEVEL_1 (1 1)
-#define DBG_LEVEL_2 (1 2)
-#define DBG_LEVEL_3 (1 3)
-#define DBG_LEVEL_IO(1 4)
-#define DBG_LEVEL_VMMU (1 5)
-#define DBG_LEVEL_IOAPIC (1 6)
extern unsigned int opt_vmx_debug_level;
-#define VMX_DBG_LOG(level, _f, _a...) \
-if ((level) opt_vmx_debug_level) \
-printk([VMX] _f \n, ## _a )
-#else
-#define VMX_DBG_LOG(level, _f, _a...)
#endif
-
-#define __vmx_bug(regs)\
-do {\
-printk(__vmx_bug at %s:%d\n, __FILE__, __LINE__); \
-show_registers(regs); \
-
Re: [Xen-ia64-devel] [Patch] cleanup warning in xen/arch/ia64/linux-xen/time.c
Hi, Tristan
I use gcc-3.4.4.
I also check gcc-4.1.1, and I also get warning.
This warning is happened in only the case of gcc-4.1.1.
I'll also reseach the warning.
Best Regards,
Akio Takebe
Le Samedi 10 Juin 2006 07:50, Akio Takebe a 馗rit :
Hi,
I remove a wrong cleanup in xen/arch/ia64/linux-xen/time.c
itc_ratio.num and itc_ratio.den are defined u64
in xen/include/asm-ia64/linux-xen/asm/pal.h.
These are the below.
typedef struct pal_freq_ratio {
u64 den : 32, num : 32; /* numerator denominator */
} itc_ratio, proc_ratio;
Which version of gcc are you using ?
gcc 4.1.1 now reports a warning.
I'll check the C standard.
Tristan.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH 1/7][SMP] add volatile to mpt_table
On Thu, 2006-06-15 at 11:58 +0900, Isaku Yamahata wrote:
1 / 7
_# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID ad418fdb1981be2108d84bafbd294a9db9899396
# Parent d33add81096b057f98fa740ab88d6c17426f8d68
mpt_table is accessed concurrently by cpus, so it needs volatile
qualifier
PATCHNAME: volatile_mpt_table
diff -r d33add81096b -r ad418fdb1981 xen/arch/ia64/xen/xenmem.c
--- a/xen/arch/ia64/xen/xenmem.cWed Jun 14 16:05:45 2006
-0600
+++ b/xen/arch/ia64/xen/xenmem.cThu Jun 15 11:33:14 2006
+0900
@@ -35,7 +35,7 @@ unsigned long max_page;
/*
* Set up the page tables.
*/
-unsigned long *mpt_table;
+volatile unsigned long *mpt_table;
void
paging_init (void)
@@ -140,7 +140,7 @@ create_mpttable_page_table (u64 start, u
create_mpttable_page_table (u64 start, u64 end, void *arg)
{
unsigned long address, start_page, end_page;
- unsigned long *map_start, *map_end;
+ volatile unsigned long *map_start, *map_end;
pgd_t *pgd;
pud_t *pud;
pmd_t *pmd;
[snip...]
I don't understand why map_start and map_end need to be
volatile here. They only seem to be copying volatile
values for later use so there is no need for them to be
volatile; did I miss something?
Thanks for the clarification.
--
Ciao,
al
--
Al Stone Alter Ego:
Open Source and Linux RD Debian Developer
Hewlett-Packard Company http://www.debian.org
E-mail: [EMAIL PROTECTED][EMAIL PROTECTED]
--
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH 2/7][SMP] add volatile to p2m table pte entry
On Thu, 2006-06-15 at 11:58 +0900, Isaku Yamahata wrote:
2 / 7
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 03b29286001dea87284cc401492a799e7e654a0f
# Parent ad418fdb1981be2108d84bafbd294a9db9899396
add volatile pte entry of the p2m table.
Since p2m table are shared by cpu. volatile is needed.
fix the races in pte access of __assign_domain_page() and
destroy_grant_host_mapping()
PATCHNAME: volatile_pte_t
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r ad418fdb1981 -r 03b29286001d xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.c Thu Jun 15 11:33:14 2006 +0900
+++ b/xen/arch/ia64/xen/mm.c Thu Jun 15 11:33:20 2006 +0900
@@ -338,10 +338,42 @@ unsigned long translate_domain_mpaddr(un
}
//XXX !xxx_present() should be used instread of !xxx_none()?
+// __assign_new_domain_page(), assign_new_domain_page() and
+// assign_new_domain0_page() are used only when domain creation.
+// their accesses aren't racy so that returned pte_t doesn't need
+// volatile qualifier
+static pte_t*
+__lookup_alloc_domain_pte(struct domain* d, unsigned long mpaddr)
+{
+struct mm_struct *mm = d-arch.mm;
+pgd_t *pgd;
+pud_t *pud;
+pmd_t *pmd;
+
+BUG_ON(mm-pgd == NULL);
+pgd = pgd_offset(mm, mpaddr);
+if (pgd_none(*pgd)) {
+pgd_populate(mm, pgd, pud_alloc_one(mm,mpaddr));
+}
+
+pud = pud_offset(pgd, mpaddr);
+if (pud_none(*pud)) {
+pud_populate(mm, pud, pmd_alloc_one(mm,mpaddr));
+}
+
+pmd = pmd_offset(pud, mpaddr);
+if (pmd_none(*pmd)) {
+pmd_populate_kernel(mm, pmd, pte_alloc_one_kernel(mm, mpaddr));
+}
+
+return pte_offset_map(pmd, mpaddr);
+}
+
Very nice rewrite.
+//XXX !xxx_present() should be used instread of !xxx_none()?
// pud, pmd, pte page is zero cleared when they are allocated.
// Their area must be visible before population so that
// cmpxchg must have release semantics.
-static pte_t*
+static volatile pte_t*
lookup_alloc_domain_pte(struct domain* d, unsigned long mpaddr)
{
struct mm_struct *mm = d-arch.mm;
@@ -384,11 +416,11 @@ lookup_alloc_domain_pte(struct domain* d
}
}
-return pte_offset_map(pmd, mpaddr);
+return (volatile pte_t*)pte_offset_map(pmd, mpaddr);
}
//XXX xxx_none() should be used instread of !xxx_present()?
-static pte_t*
+static volatile pte_t*
lookup_noalloc_domain_pte(struct domain* d, unsigned long mpaddr)
{
struct mm_struct *mm = d-arch.mm;
@@ -409,11 +441,11 @@ lookup_noalloc_domain_pte(struct domain*
if (unlikely(!pmd_present(*pmd)))
return NULL;
-return pte_offset_map(pmd, mpaddr);
+return (volatile pte_t*)pte_offset_map(pmd, mpaddr);
}
#ifdef CONFIG_XEN_IA64_DOM0_VP
-static pte_t*
+static volatile pte_t*
lookup_noalloc_domain_pte_none(struct domain* d, unsigned long mpaddr)
{
struct mm_struct *mm = d-arch.mm;
@@ -434,13 +466,13 @@ lookup_noalloc_domain_pte_none(struct do
if (unlikely(pmd_none(*pmd)))
return NULL;
-return pte_offset_map(pmd, mpaddr);
+return (volatile pte_t*)pte_offset_map(pmd, mpaddr);
}
In all of the functions above, it appears that the return value of
a function (pte_offset_map()) is being returned as a volatile result
from each of the functions. Is that really needed? I'm not sure
it helps in this case, but I could be wrong.
unsigned long
lookup_domain_mpa(struct domain *d, unsigned long mpaddr)
{
-pte_t *pte;
+volatile pte_t *pte;
pte = lookup_noalloc_domain_pte(d, mpaddr);
if (pte == NULL)
pte seems to be used only locally, so I think the volatile
makes no difference here.
@@ -470,7 +502,7 @@ __lookup_domain_mpa(struct domain *d, un
unsigned long lookup_domain_mpa(struct domain *d, unsigned long mpaddr)
{
-pte_t *pte;
+volatile pte_t *pte;
#ifdef CONFIG_DOMAIN0_CONTIGUOUS
if (d == dom0) {
@@ -486,9 +518,10 @@ unsigned long lookup_domain_mpa(struct d
#endif
pte = lookup_noalloc_domain_pte(d, mpaddr);
if (pte != NULL) {
-if (pte_present(*pte)) {
+pte_t tmp_pte = *pte;// pte is volatile. copy the value.
+if (pte_present(tmp_pte)) {
//printk(lookup_domain_page: found mapping for %lx,
pte=%lx\n,mpaddr,pte_val(*pte));
-return pte_val(*pte);
+return pte_val(tmp_pte);
} else if (VMX_DOMAIN(d-vcpu[0]))
return GPFN_INV_MASK;
}
Simililarly here: pte seems to be used only locally, so I think the
volatile makes no difference here. There are several other functions
where 'pte_t *pte;' becomes 'volatile pte_t *pte;' that may not be
needed at all.
[snip...]
@@ -975,10 +1021,12 @@ destroy_grant_host_mapping(unsigned long
unsigned long mfn, unsigned int flags)
{
Re: [Xen-ia64-devel] [PATCH 2/7][SMP] add volatile to p2m table pte entry
On Thu, Jun 15, 2006 at 01:14:06PM -0600, Al Stone wrote:
In all of the functions above, it appears that the return value of
a function (pte_offset_map()) is being returned as a volatile result
from each of the functions. Is that really needed? I'm not sure
it helps in this case, but I could be wrong.
It seems that you are confusing
volatile pte_t* (a pointer to volatile pte_t) with
pte_t* volatile (a volatile pointer to pte_t).
@@ -986,21 +1034,42 @@ destroy_grant_host_mapping(unsigned long
}
pte = lookup_noalloc_domain_pte(d, gpaddr);
-if (pte == NULL || !pte_present(*pte) || pte_pfn(*pte) != mfn)
+if (pte == NULL) {
+DPRINTK(%s: gpaddr 0x%lx mfn 0x%lx\n, __func__, gpaddr, mfn);
return GNTST_general_error;
-
-// update pte
-old_pte = ptep_get_and_clear(d-arch.mm, gpaddr, pte);
-if (pte_present(old_pte)) {
-old_mfn = pte_pfn(old_pte);
-} else {
+}
+
+ again:
+cur_arflags = pte_val(*pte) ~_PAGE_PPN_MASK;
+cur_pte = pfn_pte(mfn, __pgprot(cur_arflags));
+if (!pte_present(cur_pte)) {
+DPRINTK(%s: gpaddr 0x%lx mfn 0x%lx cur_pte 0x%lx\n,
+__func__, gpaddr, mfn, pte_val(cur_pte));
return GNTST_general_error;
}
-domain_page_flush(d, gpaddr, old_mfn, INVALID_MFN);
-
-old_page = mfn_to_page(old_mfn);
-BUG_ON(page_get_owner(old_page) == d);//try_to_clear_PGC_allocate(d,
page) is not needed.
-put_page(old_page);
+new_pte = __pte(0);
+
+old_pte = ptep_cmpxchg_rel(d-arch.mm, gpaddr, pte, cur_pte,
new_pte);
+if (unlikely(!pte_present(old_pte))) {
+DPRINTK(%s: gpaddr 0x%lx mfn 0x%lx cur_pte 0x%lx old_pte
0x%lx\n,
+__func__, gpaddr, mfn, pte_val(cur_pte),
pte_val(old_pte));
+return GNTST_general_error;
+}
+if (unlikely(pte_val(cur_pte) != pte_val(old_pte))) {
+if (pte_pfn(old_pte) == mfn) {
+goto again;
Maybe I'm just being paranoid, but is there *any* chance this goto loop
will not terminate?
Yes there is.
If there are more than two vcpus and enough physical cpus, and
other vcpus keep chainging the entry, the goto loop won't terminate.
I think it is very unlikey in practice.
Thanks.
--
yamahata
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
