From: Alex Williamson
Sent: 2006年4月4日 7:13
I had to pull arch/ia64/kernel/sal.c into our build tree with the
sparse update to 2.6.16-rc3 because the check_sal_cache_flush() test
broke when running on Xen. This patch enables the missing Xen
functionality and removes sal.c. Two changes are
From: Tristan Gingold
Sent: 2006年3月31日 23:28
To: xen-ia64-devel@lists.xensource.com; Magenheimer, Dan (HP Labs
Fort Collins); Alex Williamson
Subject: [Xen-ia64-devel] PATCH: cache flush
Hi,
this implements sal_cache_flush using fc/fc.i
Tested by compilation + boot+halt of dom0+domU with SMP-g.
On 4 Apr 2006, at 03:17, Tian, Kevin wrote:
Then consider your question about a large box with many processors.
How about the real environment? Is it the case to provide a 16-way SMP
box, or a 16-way NUMA box? I prefer to the latter. If it's a NUMA box,
dom0 sees physical ACPI table and can
From: Keir Fraser [mailto:[EMAIL PROTECTED]
Sent: 2006年4月4日 15:26
On 4 Apr 2006, at 03:17, Tian, Kevin wrote:
Then consider your question about a large box with many processors.
How about the real environment? Is it the case to provide a 16-way
SMP
box, or a 16-way NUMA box? I prefer to the
From: Tristan Gingold [mailto:[EMAIL PROTECTED]
Sent: 2006年4月4日 15:47
One small question. Why do you check upon '4' in sal emulation?
+/* The best we can do is to flush with fc all the domain.
*/
+domain_cache_flush (current-domain, in1 == 4 ? 1 : 0);
+
Le Lundi 03 Avril 2006 20:01, Alex Williamson a écrit :
On Mon, 2006-04-03 at 14:38 +0100, Tristan Gingold wrote:
Hi,
after the comments, here is my updated patch for ptc.ga
Please comment it.
With this patch, the page_flags are always written atomically. Ptc only
clear it. This
From: Tristan Gingold
Sent: 2006年4月3日 21:38
The other conflict is use. This is within ia64_page_fault, between
vcpu_translate and vcpu_itc_no_srlz. This part of code is protected by
a
flag + counter: At entry the flag is set and the counter increment, at exit
the flag is reset. Ptc.ga waits if
Le Mardi 04 Avril 2006 10:15, Tian, Kevin a écrit :
[...]
diff -r ddc279c91502 xen/arch/ia64/xen/vcpu.c
--- a/xen/arch/ia64/xen/vcpu.c Fri Mar 31 21:04:16 2006
+++ b/xen/arch/ia64/xen/vcpu.c Mon Apr 3 11:20:57 2006
+do {
+/* Wait
From: Tristan Gingold [mailto:[EMAIL PROTECTED]
Sent: 2006年4月4日 16:39
Le Mardi 04 Avril 2006 10:15, Tian, Kevin a écrit :
[...]
diff -r ddc279c91502 xen/arch/ia64/xen/vcpu.c
--- a/xen/arch/ia64/xen/vcpu.c Fri Mar 31 21:04:16 2006
+++ b/xen/arch/ia64/xen/vcpu.c Mon Apr 3 11:20:57 2006
Le Mardi 04 Avril 2006 10:49, Tian, Kevin a écrit :
From: Tristan Gingold [mailto:[EMAIL PROTECTED]
Sent: 2006年4月4日 16:39
Le Mardi 04 Avril 2006 10:15, Tian, Kevin a écrit :
[...]
diff -r ddc279c91502 xen/arch/ia64/xen/vcpu.c
--- a/xen/arch/ia64/xen/vcpu.cFri Mar 31 21:04:16 2006
Le Mardi 04 Avril 2006 10:18, Tristan Gingold a écrit :
Le Lundi 03 Avril 2006 20:01, Alex Williamson a écrit :
On Mon, 2006-04-03 at 14:38 +0100, Tristan Gingold wrote:
Hi,
after the comments, here is my updated patch for ptc.ga
Please comment it.
With this patch, the
Le Mardi 04 Avril 2006 11:15, Tian, Kevin a écrit :
From: Tristan Gingold [mailto:[EMAIL PROTECTED]
Sent: 2006年4月4日 17:00
As Isaku pointed out, vcpu_translate is run with psr.i = 1. (I think this
is true).
Therefore an IPI doesn't avoid the race.
That's not the necessary case. If current
fix gnttab_shared_gmfn().
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 994038c91f81c7d905717506a152171731351acc
# Parent 03033f8f5c058dd99010ec3ad900d9540e39afb2
fix gnttab_shared_gmfn()
PATCHNAME: fix_gnttab_shared_gmfn
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
fix paging_init(). The previoush has a bug. This patch fixes it.
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 83b6c79544891bb370bf23f05e75a5f6c5bb43e7
# Parent 05dade608696b61d624bea82c20364dfdc6d6174
fix paginig_init() to initialize mpt_table properly.
PATCHNAME:
Hi,
I am not currently tracking the gcc segfault; I am just watching it.
During a Linux compilation, I also got as segfault.
No conclusion :-(
Tristan.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
On Tue, 2006-04-04 at 09:18 +0100, Tristan Gingold wrote:
Le Lundi 03 Avril 2006 20:01, Alex Williamson a écrit :
count = PSCBX(vcpu, tlb_inuse);
while (count 1)
Is it a style point ?
Note that your sequence it different from my sequence.
Yeah, maybe it's not applicable in
Hi Tristan,
Sorry for late response.
Let's first make sure our understanding of ptc.ga is correct.
Assume there are two LPs on one box, we call them LP1 and LP2,
And rr7=0x107 on LP1, rr7=0x207 on LP2,
And below code segment is executed at LP1
movlR2=0xe000;
mov
Le Mardi 04 Avril 2006 15:56, Xu, Anthony a écrit :
Hi Tristan,
Sorry for late response.
Let's first make sure our understanding of ptc.ga is correct.
Assume there are two LPs on one box, we call them LP1 and LP2,
And rr7=0x107 on LP1, rr7=0x207 on LP2,
And below code segment is executed at
From: Tristan Gingold
dtlb and itlb are cleared unconditionnaly.
However you are right, the VHPT entry is not the good one. I think this is a
good reason not to do it with the IPI, but to clear directly the entry.
Yes, resetting the rid impacts the performance, that makes IPI method worse.
I
From: Tristan Gingold [mailto:[EMAIL PROTECTED]
Sent: 2006?4?4? 23:03
Yes, resetting the rid impacts the performance, that makes IPI method
worse. I have an idea about handling ptc.ga. But I am not sure whether it
is feasible.
The control flow is as below
1. vcpu1 emulates ptc.ga
2. vcpu1
On Tue, 2006-04-04 at 09:11 +0100, Tristan Gingold wrote:
diff -r 40d96f4e9fcb -r 65b3a99122e5 xen/arch/ia64/xen/xensetup.c
--- a/xen/arch/ia64/xen/xensetup.c Mon Apr 3 20:39:27 2006
+++ b/xen/arch/ia64/xen/xensetup.c Tue Apr 4 03:57:29 2006
@@ -24,6 +24,12 @@
#include asm/vmx.h
Le Mardi 04 Avril 2006 17:12, Xu, Anthony a écrit :
From: Tristan Gingold [mailto:[EMAIL PROTECTED]
Sent: 2006?4?4? 23:03
Yes, resetting the rid impacts the performance, that makes IPI method
worse. I have an idea about handling ptc.ga. But I am not sure whether
it is feasible.
The
From: Tristan Gingold
Sent: 2006?4?4? 23:25
To: Xu, Anthony; xen-ia64-devel@lists.xensource.com
Subject: Re: [Xen-ia64-devel] RFC: ptc.ga implementation for SMP-g
Le Mardi 04 Avril 2006 17:12, Xu, Anthony a écrit :
From: Tristan Gingold [mailto:[EMAIL PROTECTED]
Sent: 2006?4?4? 23:03
Yes,
On Mon, 2006-04-03 at 17:13 -0600, Alex Williamson wrote:
I had to pull arch/ia64/kernel/sal.c into our build tree with the
sparse update to 2.6.16-rc3 because the check_sal_cache_flush() test
broke when running on Xen. This patch enables the missing Xen
functionality and removes sal.c.
On Tue, 2006-04-04 at 09:16 +0800, Tian, Kevin wrote:
Hi, Alex,
Thanks for comments, and here comes updated one. Please apply.
Applied. Thanks,
Alex
--
Alex Williamson HP Linux Open Source Lab
___
I understand and sympathize with the need for dom0 to
sometimes get and use information from each processor
that is only available if dom0 is running on each processor.
However, AFAIK, SMP guests are always gang-scheduled, correct?
(If not, aren't there some very knotty research issues related
to
The control flow is as below
1. vcpu1 emulates ptc.ga
2. vcpu1 executes vhpt_flush_address to purge current LP VHPT,
and executes ptc.l to purge machine TLB on current LPs.
3. vcpu1 creates a structure which describe this
ptc.ga, including
virtual address, address range and
I understand and sympathize with the need for dom0 to
sometimes get and use information from each processor that is
only available if dom0 is running on each processor.
However, AFAIK, SMP guests are always gang-scheduled, correct?
No, there's no need to strictly gang schedule, and the
Yes this problem has been with us for several months and
anybody who exercises Xen/ia64 heavily will probably see it
occur. It is definitely not specific to gcc... it may even
be occuring in ltp, but since it is not repeatable (the
failure appears almost randomly), it is hard to link a
single ltp
From: Xu,Anthony
Sent: 2006年4月4日 22:47
The control flow is as below
1. vcpu1 emulates ptc.ga
2. vcpu1 executes vhpt_flush_address to purge current LP VHPT,
and executes ptc.l to purge machine TLB on current LPs.
3. vcpu1 creates a structure which describe this ptc.ga, including virtual
From: Xu,Anthony
Sent: 2006年4月4日 23:36
And as you said IPI may cause trouble when considering migration.
If above method is feasible, I prefer this one.
How to be sure the time window is not too long ?
vcpu1 must waits for vcpu2.
Sorry for not clear, IMO vcpu1 doesn't need to wait vcpu2.
Vcpu1
From: Magenheimer, Dan
Sent: 2006?4?5? 3:46
I think ptc.ga needs to execute as a transaction, that is,
it is not complete until all other processors' translations
have been purged. If not, consider (in the above):
4.5. vcpu2 doesn't trap to the hypervisor for a very long time
and
From: Xu,Anthony
Sent: 2006年4月5日 9:50
Let's first analyze how linux uses ptc.ga.
In linux, a process is only running on a LP at one time, is this
correct?
Linux allows two processes to share same address space. In that case,
it's possible that two LPs refer to same page table simultaneously.
From: Tian, Kevin
Sent: 2006年4月5日 10:05
Linux allows two processes to share same address space. In that case,
it's possible that two LPs refer to same page table simultaneously. So this
assertion doesn't hold true. :-)
Yes, region 5 is shared by all processes.
For further thinking, IPI seems to
From: Magenheimer,
Dan (HP Labs Fort Collins)
Yes this problem has been with us for several months and
anybody who exercises Xen/ia64 heavily will probably see it
occur. It is definitely not specific to gcc... it may even
be occuring in ltp, but since it is not repeatable (the
failure appears
From: Tian, Kevin
4. How long does ptc.ga emulation need to wait?
By above IPI style, the best case is that all target vcpus are
not in
running state and thus all emulation work can be done within IPI handler
The worst case is that target vcpu is in running state. In that
case,
36 matches
Mail list logo
