Re: [Xen-ia64-devel]Question about priv_ptc_e
Le Vendredi 10 Mars 2006 07:06, Xu, Anthony a écrit :
Dan,
Why is ptc_e emulated as fc when gr is larger than 63?
IA64FAULT priv_ptc_e(VCPU *vcpu, INST64 inst)
{
UINT src = inst.M28.r3;
// NOTE: ptc_e with source gr 63 is emulated as a fc r(y-64)
if (src 63) return(vcpu_fc(vcpu,vcpu_get_gr(vcpu,src - 64)));
return vcpu_ptc_e(vcpu,vcpu_get_gr(vcpu,src));
}
This is the way fc is privatized.
You need to privatize fc because its semantic is different in CPL0 and CPL !=
0. You couldn't use a break (at least during the privatize area), so Dan
used a priv op with special registers.
Maybe this area is over and this could be now cleaned.
Tristan.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Weekly benchmark results [3/2nd week]
Hi YongKang, No, I doesn't try LTP on dom0 yet. I will execute it now. I will inform the result later. Thanks, Fujita -Original Message- From: You, Yongkang [mailto:[EMAIL PROTECTED] Sent: Friday, March 10, 2006 5:06 PM To: yo.fujita; xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] Weekly benchmark results [3/2nd week] Hi Fujita, Did you try to run LTP and get the results in xen0 environment? Best Regards, Yongkang (Kangkang) 永康 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of yo.fujita Sent: 2006年3月10日 14:32 To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] Weekly benchmark results [3/2nd week] Hi, all I will inform this week's benchmark result. The tool used now is as follows. - unixbench4.1.0 - bonnie++-1.03 - ltp-full-20051205 - iozone3_191 - lmbench-3.0-a5 TEST ENVIRONMENT Machine : Tiger4 KERN : 2.6.16-rc5-xenU changeset: 9157:a693ccb4d581 Dom0 OS : RHEL4 U2 (no SMP) DomU OS : RHEL4 U2 (no SMP) No. of DomU's: 1 SUMMARY: - DomU came to do boot successfully! issues: - TEST RESULT unixbench4.1.0: PASS bonnie++-1.03 : PASS ltp-full-20051205 : 51/816 FAIL (Please see the attached files) iozone3_191 : PASS lmbench-3.0-a5: PASS Thanks and best regards, Fujita and Fujitsu members ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Weekly benchmark results [3/2nd week]
-Original Message- From: yo.fujita [mailto:[EMAIL PROTECTED] Sent: 2006年3月10日 16:36 To: You, Yongkang; xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] Weekly benchmark results [3/2nd week] Hi YongKang, No, I doesn't try LTP on dom0 yet. I will execute it now. I will inform the result later. Okay. Thanks a lot. Just for your information, I have run a full LTP in Xen0 in January. The result is okay (not like so many failed cases in XenU). Except some cases, who also failed in Native Linux and would relate to network (xenU didn't connect network, right?), I only catch float point cases failed and crashme case hang Xen0. Do you do a base LTP checking on Native Linux, who also ran RHEL4u2 on Tiger4? It can be a base LTP result to compare with Xen results. :) Thanks, Fujita Best Regards, Yongkang (Kangkang) 永康 ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel]Question about priv_ptc_e
Le Vendredi 10 Mars 2006 09:27, Xu, Anthony a écrit : From: Tristan Gingold [mailto:[EMAIL PROTECTED] Sent: 2006年3月10日 16:13 This is the way fc is privatized. You need to privatize fc because its semantic is different in CPL0 and CPL != 0. You couldn't use a break (at least during the privatize area), so Dan used a priv op with special registers. Maybe this area is over and this could be now cleaned. Understand, so the question changes to, Doesn't fc use register whose index is larger than 63? It may, but it don't. I suppose privatize checks this. According to Dan work, the answer is no. Note we only speak about fc in kernel. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] RE: in_tpa is not SMP-safe
Le Jeudi 09 Mars 2006 19:14, Magenheimer, Dan (HP Labs Fort Collins) a écrit : I was hoping Kevin would respond to this as my memory on it is dim. There was a rare but significant problem that this code was fixing and we went through several attempts to fix it. I don't think we ever understood exactly why this code was necessary because we (both Kevin and I) thought a different code sequence should work, but it didn't. So, yes, make the change to make it SMP-safe (I prefer the parameter), but be careful about changing the in_tpa semantics without running a very thorough test suite. Ok. Also, vcpu_translate look in itr_regions even for data_access. There is a comment about that: // FIXME?: check itr's for data accesses too, else bad things happen? I suppose this is required to read instructions from Xen. Are there any other uses ? Is it too dangerous to try to fix that ? It is certainly dangerous to change any of this code. I spent several days playing with it (to improve performance) last October and was often surprised when a change broke everything. I definitely tried to fix the specific code you are referring to but never got it to work, ran out of time, and gave up. If you do try any changes, make sure it is tested VERY thoroughly as sometimes the problems I saw only showed up infrequently (e.g. compiling Linux failed 10 in 20 times instead of just 1 in 20 times). I don't want to make change now. I'd just like to understand this function and the kludges. I only regret the lacks of comments (no offense here). Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH]: remove active_mm
Le Jeudi 09 Mars 2006 17:29, Magenheimer, Dan (HP Labs Fort Collins) a écrit :
Empty attachment?
Sorry.
I try again.
Tested by boot+shutdown of dom0+domU.
Tristan.
-Original Message-
From: Tristan Gingold [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 09, 2006 9:31 AM
To: xen-ia64-devel@lists.xensource.com; Magenheimer, Dan (HP
Labs Fort Collins); Williamson, Alex (Linux Kernel Dev)
Subject: [PATCH]: remove active_mm
Hi,
this field was never written and tested only at a few place.
Maybe this can fix bugs, I don't know.
Tested by booting and shutdowning dom0.
Tristan.
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 5d20c84681d0469a4ce96527370b5e12d9a66033
# Parent e39ccf78a8bed93d1b3f14543e40508f3ed453f5
Remove unused and unwritten active_mm field of vcpu and domain.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r e39ccf78a8be -r 5d20c84681d0 xen/arch/ia64/asm-offsets.c
--- a/xen/arch/ia64/asm-offsets.c Thu Mar 9 12:19:54 2006
+++ b/xen/arch/ia64/asm-offsets.c Thu Mar 9 12:38:14 2006
@@ -84,7 +84,6 @@
//DEFINE(IA64_TASK_SIGHAND_OFFSET,offsetof (struct task_struct, sighand));
//DEFINE(IA64_TASK_SIGNAL_OFFSET,offsetof (struct task_struct, signal));
//DEFINE(IA64_TASK_TGID_OFFSET, offsetof (struct task_struct, tgid));
- DEFINE(IA64_PGD, offsetof(struct domain, arch.mm));
DEFINE(IA64_TASK_THREAD_KSP_OFFSET, offsetof (struct vcpu, arch._thread.ksp));
DEFINE(IA64_TASK_THREAD_ON_USTACK_OFFSET, offsetof (struct vcpu, arch._thread.on_ustack));
diff -r e39ccf78a8be -r 5d20c84681d0 xen/arch/ia64/linux-xen/setup.c
--- a/xen/arch/ia64/linux-xen/setup.c Thu Mar 9 12:19:54 2006
+++ b/xen/arch/ia64/linux-xen/setup.c Thu Mar 9 12:38:14 2006
@@ -842,7 +842,9 @@
| IA64_DCR_DA | IA64_DCR_DD | IA64_DCR_LC));
#endif
atomic_inc(init_mm.mm_count);
+#ifndef XEN
current-active_mm = init_mm;
+#endif
#ifdef XEN
if (current-domain-arch.mm)
#else
diff -r e39ccf78a8be -r 5d20c84681d0 xen/arch/ia64/linux-xen/smp.c
--- a/xen/arch/ia64/linux-xen/smp.c Thu Mar 9 12:19:54 2006
+++ b/xen/arch/ia64/linux-xen/smp.c Thu Mar 9 12:38:14 2006
@@ -296,7 +296,12 @@
{
preempt_disable();
/* this happens for the common case of a single-threaded fork(): */
+#ifdef XEN
+ if (likely(mm == current-domain-arch.mm
+ atomic_read(mm-mm_users) == 1))
+#else
if (likely(mm == current-active_mm atomic_read(mm-mm_users) == 1))
+#endif
{
local_finish_flush_tlb_mm(mm);
preempt_enable();
diff -r e39ccf78a8be -r 5d20c84681d0 xen/include/asm-ia64/domain.h
--- a/xen/include/asm-ia64/domain.h Thu Mar 9 12:19:54 2006
+++ b/xen/include/asm-ia64/domain.h Thu Mar 9 12:38:14 2006
@@ -14,7 +14,6 @@
extern void domain_relinquish_resources(struct domain *);
struct arch_domain {
-struct mm_struct *active_mm;
struct mm_struct *mm;
unsigned long metaphysical_rr0;
unsigned long metaphysical_rr4;
@@ -68,7 +67,6 @@
int breakimm; // from arch_domain (so is pinned)
int starting_rid; /* first RID assigned to domain */
int ending_rid; /* one beyond highest RID assigned to domain */
-struct mm_struct *active_mm;
struct thread_struct _thread; // this must be last
thash_cb_t *vtlb;
@@ -81,7 +79,6 @@
struct arch_vmx_struct arch_vmx; /* Virtual Machine Extensions */
};
-#define active_mm arch.active_mm
//#define thread arch._thread
// FOLLOWING FROM linux-2.6.7/include/sched.h
diff -r e39ccf78a8be -r 5d20c84681d0 xen/include/asm-ia64/linux-xen/asm/tlbflush.h
--- a/xen/include/asm-ia64/linux-xen/asm/tlbflush.h Thu Mar 9 12:19:54 2006
+++ b/xen/include/asm-ia64/linux-xen/asm/tlbflush.h Thu Mar 9 12:38:14 2006
@@ -80,7 +80,11 @@
#ifdef CONFIG_SMP
flush_tlb_range(vma, (addr PAGE_MASK), (addr PAGE_MASK) + PAGE_SIZE);
#else
+#ifdef XEN
+ if (vma-vm_mm == current-domain-arch.mm)
+#else
if (vma-vm_mm == current-active_mm)
+#endif
ia64_ptcl(addr, (PAGE_SHIFT 2));
#ifndef XEN
// FIXME SMP?
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] vIOSAPIC and IRQs delivery
Le Jeudi 09 Mars 2006 19:01, Tian, Kevin a écrit : [...] I'm not against this specific case of interrupt domains, and also not against experiment on that if helps. However I disagrees your last sentence. Adding immature code into unstable base only makes things messed, worse, and more error-prone. Together with people's on-going effort to make xen/ia64 more stable, new patches should be more careful to address existing issues that people are concern. I don't want to polemize about this. But it seems to me you didn't like my vIOSAPIC patch because it doesn't handle driver domain and shared IRQs. These two points cannot be tested now. [End point for me]. (Recent clean-up patches on the list are highly appreciated, including yours :-) Thanks. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] vIOSAPIC and IRQs delivery
Le Jeudi 09 Mars 2006 20:16, Tian, Kevin a écrit : From: Magenheimer, Dan (HP Labs Fort Collins) [...] When an external interrupt arrives (e.g. Xen is executing starting at IVT+3000), the vast majority of interrupts should be able to be reflected or recorded using a fast path. This is much harder to do with event channels than by setting a bit in a hyperregister. (Sure you could rewrite all the event channel code in assembly, but then what is the point of sharing the C code?) For this point, I think two paths (by event channel and by interrupt) are similar. Once receiving a device interrupt, xen hypervisor goes to save cpu state, read ivr, and then jumps to C handler. Then C handler (ia64_handle_irq) checks whether that interrupt is owned by guest. If yes: - Set pending bit in vIRR, and then resume to interrupt handler of guest (current behavior), or - Set pending bit in evtchn_pending (yes, only one extra array lookup), and then resume to callback of guest In this case, callback is mostly like the interrupt handler of xenlinux, with difference that one for event and another for interrupt. So I didn't see more difficulty for event channel on this case. Dan is just saying interrupt injection was easier to optimize in asm. You want to use event channel for convergence. But if you are ready to optimize it in asm, this is divergence. 2) Eddie commented that all the event channel code is already used in Xenlinux/ia64. Not true. There is a separate file (evtchn_ia64.c) that is used instead. OK, maybe I should say that's result instead of current status. Once we turn to event channel mechanism like x86, the common evtchn.c will be reusable by ia64 no change. Previously I already sent out a patch to make a small cleanup for evtchn.c Correct for me. 3) I don't think we should be trying to support machines and configurations that Linux is not even yet able to support adequately. We have plenty of work to do to get Xen/ia64 usable. And sharing IRQs between driver domains may be necessary eventually, but it doesn't seem a huge restriction in the short term to not allow different driver domains to share the same IRQ. I tempt to agree that we may do this complete mechanism step by step. For example, we may request Tristan to slim his patch first to only contain consensus logic like moving IOSAPIC from dom0 to Xen. However he has to hold lines for driver domains like RTE sharing, since that part is still in discussion. Also he needs to address previous comments on the list about the coding styles. Ok, I am ready to rework my patch to handle driver domains and IRQ sharing using almost the same code as in x86. Do you agree with this first step. Then if the new patch is clean enough, it may go in first with discussion on rest stuff on-going. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] vIOSAPIC and IRQs delivery
Le Jeudi 09 Mars 2006 23:55, Dong, Eddie a écrit : Let me put small comments before US guys call it a day. Tian, Kevin wrote: From: Magenheimer, Dan (HP Labs Fort Collins) Sent: 2006年3月10日 2:45 1) Interrupts may happen at a rate of tens of thousands per second. Just like all high frequency CPU operations are coded with fast paths (hyperprivops and hyperreflection), I think interrupt reflection (some call it injection) needs to be implemented with a fast path. Unlike the CPU ops, there is currently no fast path for external interrupt reflection, though many of the CPU ops that a guest performs (e.g. ivr, eoi, tpr) DO have fast paths. Yes, interrupt should be implemented with high performance. Yes, this is the benefit of event channel based solution. With more frequent the IRQ happens, event channel has more obvious performance gain. As TPR/IVR is done in Xen already in event channel based solution, then no/less ring crossing after the guest services IRQ. I don't think ring crossing costs much. This is not x86. Maybe I am wrong about this. Reflecting a IRQ to guest on event channel based solution is just setting a bit in shared memory and they are batched (the guest will not immediately get scheduled), similar with vIRR setting. Meanwhile, the guest will batch extract these information from the shared memory and call do_IRQ one by one. The mechanism is almost same with linux/IA64 IRQ handling (read IVR and batch handle it). You said performance was secondary. If we talk about performance, Xen/ia64 almost has fast reflexion. I think you need to do this with event channel to reach interrupt injection with fast reflexion performance. As a consequence, you will have to write some amount of event channel code in asm. And you will diverge from x86. If event channel code change, the maintainance will be high. The same cannot happen with interrupt injection, because it is done like hardware which doesn't change and because it is Xen/ia64 private, so we control it. But maintainance of event channel was a primary pros for you. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] RE: Event channel vs current scheme speed [was vIOSAPIC and IRQs delivery]
Le Vendredi 10 Mars 2006 10:21, Dong, Eddie a écrit : Tristan Gingold wrote: Event channel is 1 hypercall *iif* callback is used. If current event-channel (through IRQ) is used, this is not true. And I am angry with callback. It looked like you agree this suggestion (at least not against) at Xensummit. What changes your mind? As previously said, I agree with vIOSAPIC (for sure, I made a patch). I don't remember we talked a lot about evtchn+callback and I don't remember we reached an agreement on this. Before Xen Summit, I was not well aware of evtchn internals. BTW, callback support is on the way now. Kevin has sent out some patch already. By the end of Q1, we should see this. Ask Dan. I don't know why he didn't use event channel to deliver IRQs. By seeing the amount of optimization for IRQs, I deduced he didn't want to deviler IRQs with event-channel. Maybe I am wrong. At the very beginning, taking a shortcut is defintely OK, because the community at that time is very small. Now we have double digits active people in the community so we can do more :-) BTW, last year our design are based on that dom0 own all machine resource, so that shortcut is correct and reasonable. If I had been implementing this code, I would have taken shortcut too. This doesn't stand. Why optimizing a shurtcut ? For fun ? Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Weekly benchmark results [3/2nd week]
Hi. I'm Watanabe, co-worker of Fujita. He's going out now for his unavoidable reason, so I'll send the report instead today. TEST RESULT 5/816 FAIL (Please see the attached files) Thanks. Watanabe Takehiko Hi YongKang, No, I doesn't try LTP on dom0 yet. I will execute it now. I will inform the result later. Thanks, Fujita -Original Message- From: You, Yongkang [mailto:[EMAIL PROTECTED] Sent: Friday, March 10, 2006 5:06 PM To: yo.fujita; xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] Weekly benchmark results [3/2nd week] Hi Fujita, Did you try to run LTP and get the results in xen0 environment? Best Regards, Yongkang (Kangkang) 永康 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of yo.fujita Sent: 2006年3月10日 14:32 To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] Weekly benchmark results [3/2nd week] Hi, all I will inform this week's benchmark result. The tool used now is as follows. - unixbench4.1.0 - bonnie++-1.03 - ltp-full-20051205 - iozone3_191 - lmbench-3.0-a5 TEST ENVIRONMENT Machine : Tiger4 KERN : 2.6.16-rc5-xenU changeset: 9157:a693ccb4d581 Dom0 OS : RHEL4 U2 (no SMP) DomU OS : RHEL4 U2 (no SMP) No. of DomU's: 1 SUMMARY: - DomU came to do boot successfully! issues: - TEST RESULT unixbench4.1.0: PASS bonnie++-1.03 : PASS ltp-full-20051205 : 51/816 FAIL (Please see the attached files) iozone3_191 : PASS lmbench-3.0-a5: PASS Thanks and best regards, Fujita and Fujitsu members ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ltp-dom0-20060310.log Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Event channel vs current scheme speed [wasvIOSAPIC and IRQs delivery]
I agree the current model has implicit priorities. But I am a little bit skeptical how the priority argument. As far as I understand, in Xen or in Linux first asked is first priority. Yes, here we see 3 concerns about priority: 1: When multiple IRQs arrive at same time, higher priority one get earlier serviced in native. In xen event channel, higher priority IRQ can have higher priority event channel. So they are basically same. 2: A lower IRQ arrives first, then followed by an high priority IRQ. In this case, the situation is relative complicate. If the duration is big enough, yes the first asked is serviced. If the duration is small, then later one may preempt the first one. In virtual machine environment, the time is virtualized. So no matter which one is service first has no correctness issue (you can think the virtual duration maybe big maybe large). 3: A higher IRQ arrives first, then followed by an lower priority IRQ. In this case, higher IRQ must be serviced earlier than lower one. Xen event channel search the highest priority IRQ and do service. At service time, the callbreak is masked but the event can still be set. So a lower IRQ can't interrupt higher one. Semantics are guaranteed. All in all, above long context is just one factor that I view to choose the proper mechanism. :-) If you are that worried about priorities, we way find solution in the current scheme. I'd just like to understand why priorities are that important. These are all corner cases that we must consider as product, but at early development we can take shortcut like using pseudo IRQ for event channel here to let the whole project go ahead. And this is what we talked at xensummit, people (Dan, Ian, Keir, Jun) all have no object for potential issue concerns (for example mask/unmask support and priority issue) and agree to take next. PPC guy also uses pseudo physical IRQ for event channel as I remembered. Their community is much smaller than us now and their development is also lagger than IA64. This is why we need to clean up now as callback based event channel approach has already been in production stage. Making a new mechanism has high risk. BTW, even with this strong event channel mechanism in Xen, we sometime saw bugs in xen-devl such as a deadlock in a VMX SMP system like Xin rootcaused before new year. But anyway it is very few now. Eddie ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Event channel vs current scheme speed [wasvIOSAPIC and IRQs delivery]
Le Vendredi 10 Mars 2006 16:01, Dong, Eddie a écrit : I agree the current model has implicit priorities. But I am a little bit skeptical how the priority argument. As far as I understand, in Xen or in Linux first asked is first priority. Sorry, I was not clear enough. I agree event channel can mostly respect priority. Except clock and IPI, I think Linux doesn't use priority. I can't force a card to have an higher priority than another card. Is it right ? [...] These are all corner cases that we must consider as product, but at early development we can take shortcut like using pseudo IRQ for event channel here to let the whole project go ahead. And this is what we talked at xensummit, people (Dan, Ian, Keir, Jun) all have no object for potential issue concerns (for example mask/unmask support and priority issue) and agree to take next. PPC guy also uses pseudo physical IRQ for event channel as I remembered. Their community is much smaller than us now and their development is also lagger than IA64. This is why we need to clean up now as callback based event channel approach has already been in production stage. Making a new mechanism has high risk. You know we don't agree on these points. Writing them again won't make me change. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] [RESEND] domU destroy page ref counter
On Fri, 2006-03-10 at 10:37 +0900, Masaki Kanno wrote: Hi, We resend these patches. We made these patches to the latest changeset:9161, and reflected comments. We tested the creation and the destruction of domU repeatedly 100 times. As a result, there was not the memory which was not freed in xen/ia64. Please apply these patches to the xen-ia64-unstable tree. Applied. -- Alex Williamson HP Linux Open Source Lab ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] [RESEND]XEN: Merge guest TR emulation
On Fri, 2006-03-10 at 12:24 +0800, Xu, Anthony wrote: From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年3月10日 7:10 This seems to introduce a bunch of VCPU redefined warnings. Also, please check the formatting consistency around vcpu_get/set_rr(). There seems to be a mix of spaces and tabs within the same function there. I'd prefer that we at least keep consistent indentation within a function for readability. Thanks, Not configure vim correctly. Applied. -- Alex Williamson HP Linux Open Source Lab ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Event channel vs current scheme speed [wasvIOSAPIC and IRQs delivery]
Le Vendredi 10 Mars 2006 16:46, Dong, Eddie a écrit : [...] Actually clock and IPI is also handled in this mechanism, they are equal with other IRQs except the vector #. So you can assign a card with higher IRQ # such as for ethernet card, or assign lower one for something like mouse. Yes, it is possible. But how is it done ? If mouse is regsitered before ethernet, its IRQ priority will be higher! Tristan. ___ 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]: adding physdev_op to hypercall.h
On 10 Mar 2006, at 16:23, Tristan Gingold wrote: Hi, very small patch to prepare comming soon patches on ia64. Firstly, it belongs on the ia64-devel list and in the ia64-devel tree. Secondly, there's little point checking in the trivial patch alone -- may as well bundle it into the patch that actually defines and implements do_physdev_op(). -- Keir ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Weekly benchmark results [3/2nd week]
EM～ From the log, there are only 4 failed cases. Two are known float issue. The other 2 names are related to socket, it may related no network in XenU. Best Regards, Yongkang (Kangkang) 永康 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of nakato Sent: 2006年3月10日 19:51 To: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] Weekly benchmark results [3/2nd week] Hi. I'm Watanabe, co-worker of Fujita. He's going out now for his unavoidable reason, so I'll send the report instead today. TEST RESULT 5/816 FAIL (Please see the attached files) Thanks. Watanabe Takehiko Hi YongKang, No, I doesn't try LTP on dom0 yet. I will execute it now. I will inform the result later. Thanks, Fujita -Original Message- From: You, Yongkang [mailto:[EMAIL PROTECTED] Sent: Friday, March 10, 2006 5:06 PM To: yo.fujita; xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] Weekly benchmark results [3/2nd week] Hi Fujita, Did you try to run LTP and get the results in xen0 environment? Best Regards, Yongkang (Kangkang) 永康 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of yo.fujita Sent: 2006年3月10日 14:32 To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] Weekly benchmark results [3/2nd week] Hi, all I will inform this week's benchmark result. The tool used now is as follows. - unixbench4.1.0 - bonnie++-1.03 - ltp-full-20051205 - iozone3_191 - lmbench-3.0-a5 TEST ENVIRONMENT Machine : Tiger4 KERN : 2.6.16-rc5-xenU changeset: 9157:a693ccb4d581 Dom0 OS : RHEL4 U2 (no SMP) DomU OS : RHEL4 U2 (no SMP) No. of DomU's: 1 SUMMARY: - DomU came to do boot successfully! issues: - TEST RESULT unixbench4.1.0: PASS bonnie++-1.03 : PASS ltp-full-20051205 : 51/816 FAIL (Please see the attached files) iozone3_191 : PASS lmbench-3.0-a5: PASS Thanks and best regards, Fujita and Fujitsu members ___ 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] [PATCH] [RFC] [TAKE2] P2M/VP (incomplete) patches
On Fri, 2006-03-10 at 15:46 +0900, Isaku Yamahata wrote: The following 3 patches are trivial compilation fixes. They should go to xen-ia64-unstable.hg. Please apply. 9175:c060a6ce3174_ia64_gdbstub_compilation_fix.patch 9176:c167c758053f_hypercall_h_compilation_fix.patch 9177:7081370b340b_fix_ia64_setup_guest_printout.patch Applied. -- Alex Williamson HP Linux Open Source Lab ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH]: remove active_mm
On Fri, 2006-03-10 at 11:18 +0100, Tristan Gingold wrote: Le Jeudi 09 Mars 2006 17:29, Magenheimer, Dan (HP Labs Fort Collins) a écrit : Empty attachment? Sorry. I try again. Tested by boot+shutdown of dom0+domU. Applied. -- Alex Williamson HP Linux Open Source Lab ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel]Question about priv_ptc_e
From: Tristan Gingold [mailto:[EMAIL PROTECTED] Sent: Friday, March 10, 2006 2:41 AM To: Xu, Anthony; Magenheimer, Dan (HP Labs Fort Collins) Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel]Question about priv_ptc_e Le Vendredi 10 Mars 2006 09:27, Xu, Anthony a écrit : From: Tristan Gingold [mailto:[EMAIL PROTECTED] Sent: 2006年3月10日 16:13 This is the way fc is privatized. You need to privatize fc because its semantic is different in CPL0 and CPL != 0. You couldn't use a break (at least during the privatize area), so Dan used a priv op with special registers. Maybe this area is over and this could be now cleaned. Understand, so the question changes to, Doesn't fc use register whose index is larger than 63? It may, but it don't. I suppose privatize checks this. According to Dan work, the answer is no. Note we only speak about fc in kernel. Sorry for the delayed response... It would be OK to clean this up. It may actually be causing a bug! But I would like to preserve the code rather than remove it as it is possible that it may be used again. It would be OK though to tie it to a global variable / command line option that defaults off. For example: // NOTE: ptc_e with source gr 63 is emulated as a fc r(y-64) - if (src 63) return(vcpu_fc(vcpu,vcpu_get_gr(vcpu,src - 64))); + if (privified src 63) + return(vcpu_fc(vcpu,vcpu_get_gr(vcpu,src - 64))); return vcpu_ptc_e(vcpu,vcpu_get_gr(vcpu,src)); There are several of these that need to be changed, so let's change all of them the same way at the same time. Now for the complete historical explanation: Early in the implementation of Xen/ia64, before there was a paravirtualized Xenlinux/ia64, I implemented a program to go through the load image of a Linux binary and convert all privilege-sensitive instructions into instructions that would trap. Using this binary conversion, it was possible to run an otherwise unmodified Linux on top of Xen, albeit very slowly. This made it possible to do a lot of Xen/ia64 development and debugging without needing a paravirtualized domain0. I called this tool privify -- which is not an English word. The -ify suffix means to form into or make similar to (and according to my dictionary is derived from Old French -fier!). So privify means to make into privileged instructions. Because of the complex encodings of Itanium bundles, and because I didn't want the privify tool to deal with difficult cross-bundle rewriting, I needed to carefully choose how to transform each privilege-sensitive instruction into a privileged instruction. This meant I couldn't always just use a break instruction. Furthermore, since Xen was going to emulate the transformed instructions differently than the actual privileged instruction, I needed to choose privileged instructions that were never (or at least very rarely) used. I noted that nearly all instructions that use general registers are capable of accessing all 128 GR's, but it is rare for gr64-127 to be accessed. And it is VERY rare for those registers to get accessed by a privileged instructions. So the privify program transforms privilege-sensitive instruction into other highly similar privileged instructions. In the example you noted: fc rx is converted to ptc r(x+64) Other examples include: thash rx=ry - tak rx=r(y+64) ttag rx=ry - tpa rx=r(y+64) The complete list is in xen/arch/ia64/tools/privify/privify.h. (Note that the conversion of kernel register (ar.kr) reads pre-dates the decision to allow the kernel registers to be owned by the guest rather than by Xen itself.) Purists will note that this conversion is risky as it is POSSIBLE that Xen will confuse privified instructions with real privileged instructions. For example, if a guest really wanted to execute a ptc r65 instruction, Xen would emulate a fc r1 instruction. Fortunately, except for self-modifying code, these conflicts can be detected statically and privify warns when it encounters one of these. In all of Linux/ia64, there was one case where this was a problem: One of the mca routines had a huge routine that utilized the higher registers and used some privileged instructions. If this routine got executed, privified Linux/ia64 crashed, but there was an easy workaround: specify nomca on the domain0 command line. (Some of you may still have nomca in your elilo.conf files; this explains why!). Privification is not perfect but it was useful and is still interesting. By converting privilege-sensitive instructions so that they trap and leaving all privileged instructions to be emulated by Xen, the number of privileged traps is similar to the number of traps required for an unmodified guest executing under VT-i. With this it is possible to approximate the performance of a fully-virtualized guest. (Haavard Bjerke's thesis last summer provides benchmarks.)
[Xen-ia64-devel] RE: PG_arch_1 conflict
See previous discussion at: http://lists.xensource.com/archives/html/xen-devel/2005-12/msg00238.html The issue is that PG_arch_1 is reserved for arch-specific usage, the paravirtualization changes for Xenlinux utilize it (to mark foreign pages) because it was otherwise unused in Linux/x86. But Xen is no longer an arch. Grep'ing for PageForeign in -sparse will show most (all?) of the actual uses of it. Nearly all are in x86-specific code. But one is in netback_init(). Dan -Original Message- From: Hollis Blanchard [mailto:[EMAIL PROTECTED] Sent: Friday, March 10, 2006 1:38 PM To: Magenheimer, Dan (HP Labs Fort Collins) Cc: xen-ia64-devel@lists.xensource.com; Keir Fraser; [EMAIL PROTECTED] Subject: Re: PG_arch_1 conflict Magenheimer, Dan (HP Labs Fort Collins) wrote: We're not quite to the point of bringing up networking yet but in digging through the mailing list archive, I was reminded of a problem that we will soon run into: Xenlinux/x86 utilizes the PG_arch_1 bit to represent a foreign page. Linux/ia64 (and I think Linux/ppc) use the PG_arch_1 bit for arch-dep purposes. It this conflict is not resolved before Xenlinux/ia64 supports networking, there will likely be some very interesting bugs... What is the actual issue here? Where is the code dealing with PG_arch_1? -- Hollis Blanchard IBM Linux Technology Center ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: Linux PG_arch_1 conflict
http://lists.xensource.com/archives/html/xen-devel/2005-12/msg00238.html The issue is that PG_arch_1 is reserved for arch-specific usage, the paravirtualization changes for Xenlinux utilize it (to mark foreign pages) because it was otherwise unused in Linux/x86. But Xen is no longer an arch. Grep'ing for PageForeign in -sparse will show most (all?) of the actual uses of it. Nearly all are in x86-specific code. But one is in netback_init(). That thread seems to already have a solution. Has anybody run it past Linux MM people? (Adding xen-devel to CC for greater exposure.) If by solution you mean that Keir could change Xenlinux to add a new PG_foreign bit and change Xenlinux/x86 (and netback) to use that bit rather than PG_arch_1, I agree. Comments, Keir (or others)? Dan ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] [RESEND] domU destroy page ref counter
Hi Anthony, Thanks for your comments. Xu, Anthony wrote: This patch is really good, community has been waiting domain destroy patch for a long time. Is it appropriate time to flush vhpt and machine tlb when destroying domain? I have below concerns, In fact, I have concerns same as you. 1. This may counteract the benefit of rid partition. In my mind these flushes are done only when rid reuse happens when allocating rid for a new domain. As for this patch, page faults occurs in living domains to flush all VHPT and all TBL. That is I think that performance of living domains becomes bad temporarily. However, I thought that a serious problem did not occur so that entries was inserted in VHPT and TLB again. Because xen/ia64 was not able to destroy a domain for a long time, I made this patch to be able to destroy a domain as possible simply. I think that I have to remake an allocation logic of RID to take the benefit of RID partition. I think that this remaking is assignment given me. Best regards, Kan 2. When migration is enabled, VMM may need to flush vhpt and TC in all processors. Thanks, -Anthony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Masaki Kanno Sent: 2006定3埖10晩 9:38 To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] [PATCH] [RESEND] domU destroy page ref counter Hi, We resend these patches. We made these patches to the latest changeset:9161, and reflected comments. We tested the creation and the destruction of domU repeatedly 100 times. As a result, there was not the memory which was not freed in xen/ia64. Please apply these patches to the xen-ia64-unstable tree. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Signed-off-by: Masaki Kanno [EMAIL PROTECTED] Best regards, Kan, and Fujitsu team ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
