[Xen-ia64-devel] IMPLEMENT generic getreg/setreg pv_cpu_ops
Use generic getreg/setreg pv_cpu_ops instead of
specific ones that may vary per hypervisor.
Signed-off-by: Yaozu (Eddie) Dong <[EMAIL PROTECTED]>
diff --git a/arch/ia64/kernel/paravirt.c b/arch/ia64/kernel/paravirt.c
index 8e9fb96..072a1de 100644
--- a/arch/ia64/kernel/paravirt.c
+++ b/arch/ia64/kernel/paravirt.c
@@ -83,27 +83,6 @@ struct pv_init_ops pv_init_ops;
return ia64_native_ ## name(arg); \
} \
-#define DEFINE_SET_KR(N) \
- static void \
- ia64_native_set_kr ## N ## _func(unsigned long val) \
- { \
- ia64_native_setreg(_IA64_REG_AR_KR ## N, val); \
- } \
-
-#define DEFINE_GETREG(name, reg) \
- static unsigned long\
- ia64_native_get_ ## name ## _func(void) \
- { \
- return ia64_native_getreg(_IA64_REG_ ## reg); \
- }
-
-#define DEFINE_SETREG(name, reg) \
- static void \
- ia64_native_set_ ## name ## _func(unsigned long val)\
- { \
- ia64_native_setreg(_IA64_REG_ ## reg, val); \
- }
-
DEFINE_VOID_FUNC1(fc);
DEFINE_VOID_FUNC1(intrin_local_irq_restore);
@@ -117,25 +96,6 @@ DEFINE_FUNC1(get_cpuid, int);
DEFINE_FUNC1(get_pmd, int);
DEFINE_FUNC1(get_rr, unsigned long);
-DEFINE_SET_KR(0)
-DEFINE_SET_KR(1)
-DEFINE_SET_KR(2)
-DEFINE_SET_KR(3)
-DEFINE_SET_KR(4)
-DEFINE_SET_KR(5)
-DEFINE_SET_KR(6)
-DEFINE_SET_KR(7)
-
-DEFINE_GETREG(eflag, AR_EFLAG)
-DEFINE_GETREG(psr, PSR)
-DEFINE_GETREG(ivr, CR_IVR)
-DEFINE_GETREG(tpr, CR_TPR)
-
-DEFINE_SETREG(eflag, AR_EFLAG)
-DEFINE_SETREG(tpr, CR_TPR)
-DEFINE_SETREG(eoi, CR_EOI)
-DEFINE_SETREG(itm, CR_ITM)
-
static void
ia64_native_ssm_i_func(void)
{
@@ -156,32 +116,165 @@ ia64_native_set_rr0_to_rr4_func(unsigned long
val0, unsigned long val1,
ia64_native_set_rr0_to_rr4(val0, val1, val2, val3, val4);
}
+#define CASE_REG(id) case id: res = ia64_native_getreg(id); break;
+#define CASE_AR(id)CASE_REG(id)
+#define CASE_CR(id)CASE_REG(id)
+
+unsigned long native_ia64_getreg (int regnum)
+{
+ unsigned long res = -1;
+ switch (regnum) {
+ CASE_REG(_IA64_REG_GP);
+ CASE_REG(_IA64_REG_IP);
+ CASE_REG(_IA64_REG_PSR);
+ CASE_REG(_IA64_REG_TP);
+ CASE_REG(_IA64_REG_SP);
+
+ CASE_AR(_IA64_REG_AR_KR0);
+ CASE_AR(_IA64_REG_AR_KR1);
+ CASE_AR(_IA64_REG_AR_KR2);
+ CASE_AR(_IA64_REG_AR_KR3);
+ CASE_AR(_IA64_REG_AR_KR4);
+ CASE_AR(_IA64_REG_AR_KR5);
+ CASE_AR(_IA64_REG_AR_KR6);
+ CASE_AR(_IA64_REG_AR_KR7);
+ CASE_AR(_IA64_REG_AR_RSC);
+ CASE_AR(_IA64_REG_AR_BSP);
+ CASE_AR(_IA64_REG_AR_BSPSTORE);
+ CASE_AR(_IA64_REG_AR_RNAT);
+ CASE_AR(_IA64_REG_AR_FCR);
+ CASE_AR(_IA64_REG_AR_EFLAG);
+ CASE_AR(_IA64_REG_AR_CSD);
+ CASE_AR(_IA64_REG_AR_SSD);
+ CASE_AR(_IA64_REG_AR_CFLAG);
+ CASE_AR(_IA64_REG_AR_FSR);
+ CASE_AR(_IA64_REG_AR_FIR);
+ CASE_AR(_IA64_REG_AR_FDR);
+ CASE_AR(_IA64_REG_AR_CCV);
+ CASE_AR(_IA64_REG_AR_UNAT);
+ CASE_AR(_IA64_REG_AR_FPSR);
+ CASE_AR(_IA64_REG_AR_ITC);
+ CASE_AR(_IA64_REG_AR_PFS);
+ CASE_AR(_IA64_REG_AR_LC);
+ CASE_AR(_IA64_REG_AR_EC);
+
+ CASE_CR(_IA64_REG_CR_DCR);
+ CASE_CR(_IA64_REG_CR_ITM);
+ CASE_CR(_IA64_REG_CR_IVA);
+ CASE_CR(_IA64_REG_CR_PTA);
+ CASE_CR(_IA64_REG_CR_IPSR);
+ CASE_CR(_IA64_REG_CR_ISR);
+ CASE_CR(_IA64_REG_CR_IIP);
+ CASE_CR(_IA64_REG_CR_IFA);
+ CASE_CR(_IA64_REG_CR_ITIR);
+ CASE_CR(_IA64_REG_CR_IIPA);
+ CASE_CR(_IA64_REG_CR_IFS);
+ CASE_CR(_IA64_REG_CR_IIM);
+ CASE_CR(_IA64_REG_CR_IHA);
+ CASE_CR(_IA64_REG_CR_LID);
+ CASE_CR(_IA64_REG_CR_IVR);
+ CASE_CR(_IA64_REG_CR_TPR);
+ CASE_CR(_IA64_REG_CR_EOI);
+ CASE_CR(_IA64_REG_CR_IRR0);
+ CASE_CR(_IA64_REG_CR_IRR1);
+ CASE_CR(_IA64_REG_CR_IRR2);
+ CASE_CR(_IA64_REG_CR_IRR3);
+ CASE_CR(_IA64_REG_CR_ITV);
+ CASE_CR(_IA64_REG_CR_PMV);
+ CASE_CR(_IA64_REG_CR_CMCV);
+ CASE_CR(_IA64_REG_CR_LRR0);
+ CASE_CR(_IA64_REG_CR_LRR1);
+
+ default:
+ printk("wrong_getreg %d\n", regnum);
+ break;
+ }
+ return res;
+}
+
+#define CASE_SET_REG(id) case id: ia64_native_setreg(id, val);
break;
+#define CASE_SET_AR(id)CASE_SET_REG(id)
+#define CASE_SET_CR(id)CASE_SET_REG(id)
+
+void native_ia64_
[Xen-ia64-devel] Re: pv_ops progress & ask for suggestion
On Tue, Apr 08, 2008 at 10:31:20AM +0800, Dong, Eddie wrote: > >>Now we have 2 choices: > >>Alt1: Dual compile entry.S like IVT.s (dual compile all ASM > >> files if it needs virtualization) > >>pros: Same policy with iVT, use same MACRO to > >> replacement. > >>cons: There are other ASM files such as > >> sn/kernel/pio_phys.S need to be dual compiled too. > >>And unlike IVT table, the memory occupied by > >> dual compiled code won't be able to be freed easily since the size is > >> not fixed. Also all future ASM code touch privilege instruction may > >> need to be dual compiled too. > > > > I suppose the more generalized problem is > > - The memory for unused pv code/data won't be executed/referenced > > so that it can be freed somehow. > > Is it worth while to do that? And how to do it? > > For IVT table (64K) & gate page (1 page), it can be done except > relocating > those IP relative symbols. Yes, IVT table and gate page is somewhat special so that they are worth while to handle specialy. > > This is not ia64 specific issues, and should be addressed > > in arch generic way. This hasn't been addressed even on x86. > > X86 doesn't use dual compile. I meant by "more generalized" that freeing not only dual compiled ones, but also all ones under xen directory (or lguest, vmi... on x86). -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: pv_ops progress & ask for suggestion
Isaku Yamahata wrote: > On Mon, Apr 07, 2008 at 05:47:38PM +0800, Dong, Eddie wrote: >> Tony & all: >> Recently we have completed the IVT.s pv_ops by using dual >> compile, and also many cleanups to simplify the changes to upstream >> code. All the C code touching privilege instruction is replaced with >> indirect function call (will be binary patched to use direct function >> call in future), and IVT table is dual compiled to minimize impact to >> native IVT table, but we get some dilemma in handling kernel/entry.S >> and also generic policy for other ASM files. >> >> In entry.S, there are around 17 privilege instructions, some of >> them must be paravirtualized including 2 cover instructions, and 1 >> "RFI" (this one is due to Xen hypervisor issue). There are other 15 >> privilege instructions (In Xen) such as CR access that could be >> paravirtualized for performance reason. > > Probably we can discusse well with the concrete patch. > So I'll post the patches. > (Creating the reviewable patch set may take a while though.) If it is 200 lines of patch, that is perfect. If it is a 2000+ lines of patch, I prefer a 200 lines of pseudo code. > > >> Now we have 2 choices: >> Alt1: Dual compile entry.S like IVT.s (dual compile all ASM >> files if it needs virtualization) >> pros: Same policy with iVT, use same MACRO to >> replacement. >> cons: There are other ASM files such as >> sn/kernel/pio_phys.S need to be dual compiled too. >> And unlike IVT table, the memory occupied by >> dual compiled code won't be able to be freed easily since the size is >> not fixed. Also all future ASM code touch privilege instruction may >> need to be dual compiled too. > > I suppose the more generalized problem is > - The memory for unused pv code/data won't be executed/referenced > so that it can be freed somehow. > Is it worth while to do that? And how to do it? For IVT table (64K) & gate page (1 page), it can be done except relocating those IP relative symbols. > Looking at current xen code size it might be worth while, > but not so big win. Agree in some level. Depend on how strictly we want the code to be perfect. > This is not ia64 specific issues, and should be addressed > in arch generic way. This hasn't been addressed even on x86. X86 doesn't use dual compile. Eddie ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] cpu ops
Isaku Yamahata wrote: > On Mon, Apr 07, 2008 at 05:25:54PM +0800, Dong, Eddie wrote: >> In current approach, we have cpu ops like >> eoi/set_tpr/get_tpr,/set_itm /set_kr0/set_kr2.../set_kr7 etc. >> I think there is another simple alternative is to simply export >> setreg/getreg for cpu ops. >> >> The benefit of this could be: >> 1: Simple in pv_ops I/F >> 2: hypervisor neutral. Today we only virtualize around 15 AR/CR >> read/write, But future it may extends since different Hypervisor >> may do in different way. > > Sounds reasonable. I have a patch ready for this based on my previous removed "paravirt_xxx"/"ia64_native_xxx" version, I can rebase. > Although it would result in big switch, presumably we can eliminate Yes, many switch case. May hurt performance before patching. > runtime switch cost by specifically handling setreg/getreg which > might complicate binay patch slightly. Yes, but eventually the performance will come back after patching. Eddie. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: pv_ops progress & ask for suggestion
On Mon, Apr 07, 2008 at 05:47:38PM +0800, Dong, Eddie wrote:
> Tony & all:
> Recently we have completed the IVT.s pv_ops by using dual
> compile, and also many cleanups to simplify the changes to upstream
> code. All the C code touching privilege instruction is replaced with
> indirect function call (will be binary patched to use direct function
> call in future), and IVT table is dual compiled to minimize impact to
> native IVT table, but we get some dilemma in handling kernel/entry.S and
> also generic policy for other ASM files.
>
> In entry.S, there are around 17 privilege instructions, some of
> them must be paravirtualized including 2 cover instructions, and 1 "RFI"
> (this one is due to Xen hypervisor issue). There are other 15 privilege
> instructions (In Xen) such as CR access that could be paravirtualized
> for performance reason.
Probably we can discusse well with the concrete patch.
So I'll post the patches.
(Creating the reviewable patch set may take a while though.)
> Now we have 2 choices:
> Alt1: Dual compile entry.S like IVT.s (dual compile all ASM
> files if it needs virtualization)
> pros: Same policy with iVT, use same MACRO to
> replacement.
> cons: There are other ASM files such as
> sn/kernel/pio_phys.S need to be dual compiled too.
> And unlike IVT table, the memory occupied by
> dual compiled code won't be able to be freed easily since the size is
> not fixed. Also all future ASM code touch privilege instruction may need
> to be dual compiled too.
I suppose the more generalized problem is
- The memory for unused pv code/data won't be executed/referenced
so that it can be freed somehow.
Is it worth while to do that? And how to do it?
Looking at current xen code size it might be worth while,
but not so big win.
This is not ia64 specific issues, and should be addressed
in arch generic way. This hasn't been addressed even on x86.
Presumably it can be implemented by introducing sepcial sections like
pv.{native, xen, ...}.{text, data, ...} with linker trick.
> Alt2: Use indirect call like C code for non IVT nor gate page
> code (dual compile only for IVT & gate page which has fixed size and
> performance killer)
> Pros: flexible for future ASM code (just use same MACRO,
> no dual compile requirement).
> Cons: 2 sets of solution for ASM code, and also slightly
> performance lose due to indirect function call (future patching will
> convert it to direct function call, or in place code.)
>
>
> Any suggestions?
>
> Thanks, eddie
--
yamahata
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] cpu ops
On Mon, Apr 07, 2008 at 05:25:54PM +0800, Dong, Eddie wrote: > In current approach, we have cpu ops like eoi/set_tpr/get_tpr,/set_itm > /set_kr0/set_kr2.../set_kr7 etc. > I think there is another simple alternative is to simply export > setreg/getreg > for cpu ops. > > The benefit of this could be: > 1: Simple in pv_ops I/F > 2: hypervisor neutral. Today we only virtualize around 15 AR/CR > read/write, > But future it may extends since different Hypervisor may do in > different way. Sounds reasonable. Although it would result in big switch, presumably we can eliminate runtime switch cost by specifically handling setreg/getreg which might complicate binay patch slightly. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] pv_ops: imntrinsic pv_ops
On Mon, Apr 07, 2008 at 05:06:36PM +0800, Dong, Eddie wrote: > It looks like you still prefer to use intermediate symbol > paravirt_/ia64_native_xxx to wrap ia64_xxx. In some sense, when > I saw many similar and bulk code in the patch, I feel "dirty". I prefer > we don't touch > those gcc_intrinsic.h MACROs. > > If you don't like the way I wrap it, i.e. MACRO level ifdef /else. > you may just simply provide a new head file > for CONFIG_PARAVIRT which simply use pv_ops.name for all those same > MACROs. > > such as in intrinsic.h: > > #ifdef CONFIG_PARAVIRT_GUEST > #include > #else > gcc_intrinsic.h or intel_intrinsic.h. Isn't renaming xxx into ia64_native_xxx (or native_xxx on x86) the usual way to paravirtualize/replace the function? At least at other places, things are done so. Do you have any reason why you don't want to touch gcc_intrinsic.h/intel_intrinsic.h. If so, can we share that? Anyway if your patch is better/simpler than the current code, I'll take your patch. (At least #undef/#define CONFIG_PARAVIRT trick is ugly.) -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] pv_ops progress & ask for suggestion
Tony & all: Recently we have completed the IVT.s pv_ops by using dual compile, and also many cleanups to simplify the changes to upstream code. All the C code touching privilege instruction is replaced with indirect function call (will be binary patched to use direct function call in future), and IVT table is dual compiled to minimize impact to native IVT table, but we get some dilemma in handling kernel/entry.S and also generic policy for other ASM files. In entry.S, there are around 17 privilege instructions, some of them must be paravirtualized including 2 cover instructions, and 1 "RFI" (this one is due to Xen hypervisor issue). There are other 15 privilege instructions (In Xen) such as CR access that could be paravirtualized for performance reason. Now we have 2 choices: Alt1: Dual compile entry.S like IVT.s (dual compile all ASM files if it needs virtualization) pros: Same policy with iVT, use same MACRO to replacement. cons: There are other ASM files such as sn/kernel/pio_phys.S need to be dual compiled too. And unlike IVT table, the memory occupied by dual compiled code won't be able to be freed easily since the size is not fixed. Also all future ASM code touch privilege instruction may need to be dual compiled too. Alt2: Use indirect call like C code for non IVT nor gate page code (dual compile only for IVT & gate page which has fixed size and performance killer) Pros: flexible for future ASM code (just use same MACRO, no dual compile requirement). Cons: 2 sets of solution for ASM code, and also slightly performance lose due to indirect function call (future patching will convert it to direct function call, or in place code.) Any suggestions? Thanks, eddie ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] cpu ops
In current approach, we have cpu ops like eoi/set_tpr/get_tpr,/set_itm /set_kr0/set_kr2.../set_kr7 etc. I think there is another simple alternative is to simply export setreg/getreg for cpu ops. The benefit of this could be: 1: Simple in pv_ops I/F 2: hypervisor neutral. Today we only virtualize around 15 AR/CR read/write, But future it may extends since different Hypervisor may do in different way. Do u like to see this one happen? thanks, eddie ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] pv_ops: imntrinsic pv_ops
Isaku Yamahata wrote: > Hi Eddie. > > I commited some clean ups based on your patch. > Could you please review it? > It looks like you still prefer to use intermediate symbol paravirt_/ia64_native_xxx to wrap ia64_xxx. In some sense, when I saw many similar and bulk code in the patch, I feel "dirty". I prefer we don't touch those gcc_intrinsic.h MACROs. If you don't like the way I wrap it, i.e. MACRO level ifdef /else. you may just simply provide a new head file for CONFIG_PARAVIRT which simply use pv_ops.name for all those same MACROs. such as in intrinsic.h: #ifdef CONFIG_PARAVIRT_GUEST #include #else gcc_intrinsic.h or intel_intrinsic.h. Eddie ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel][PATCH]PAL virtualization service related patch
Thanks for your comments.
This is the revised one.
Thanks
- Anthony
-Original Message-
From: Alex Williamson [mailto:[EMAIL PROTECTED]
Sent: 2008年4月2日 0:00
To: Xu, Anthony
Cc: xen-ia64-devel
Subject: Re: [Xen-ia64-devel][PATCH]PAL virtualization service related patch
Hi Anthony,
Could you add prototypes to the appropriate header files and include
them so we can avoid this extern kludgy-ness? I think a descriptive
comment for this function would also be worthwhile. Thanks,
Alex
On Sat, 2008-03-29 at 16:17 +0800, Xu, Anthony wrote:
> --- a/xen/arch/ia64/vmx/vmx_init.c Fri Mar 14 15:07:45 2008 -0600
> +++ b/xen/arch/ia64/vmx/vmx_init.c Sat Mar 29 15:32:55 2008 +0800
> @@ -63,6 +63,33 @@ u64 __vsa_base = 0; /* Run-time service
> u64 __vsa_base = 0;/* Run-time service base of VMX */
>
> /* Check whether vt feature is enabled or not. */
> +
> +void vmx_vps_patch(void)
> +{
> + extern void ia64_patch_imm64 (u64 , u64 );
> + extern char vmx_vps_sync_read;
> + extern char vmx_vps_sync_write;
> + extern char vmx_vps_resume_normal;
> + extern char vmx_vps_resume_handler;
> + u64 addr;
--
Alex Williamson HP Open Source & Linux Org.
vps_service2.patch
Description: vps_service2.patch
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] linux: set memory attribute in inlineasm
Hi,
>On Sat, Apr 05, 2008 at 04:33:12PM +0200, [EMAIL PROTECTED] wrote:
>> Selon Isaku Yamahata <[EMAIL PROTECTED]>:
>>
>> > diff -r bb2f8ba47833 include/asm-ia64/xen/privop.h
>> > --- a/include/asm-ia64/xen/privop.hTue Mar 25 12:37:54 2008 -0600
>> > +++ b/include/asm-ia64/xen/privop.hSat Apr 05 07:27:30 2008 +0900
>> > @@ -67,7 +67,7 @@
>> > #endif
>> >
>> > #ifndef __ASSEMBLY__
>> > -#define XEN_HYPER_SSM_I asm("break %0" : : "i"
(HYPERPRIVOP_SSM_I))
>> > +#define XEN_HYPER_SSM_I asm("break %0" : : "i"
(HYPERPRIVOP_SSM_I):
>> > "memory")
>> > #define XEN_HYPER_GET_IVR asm("break %0" : : "i"
(HYPERPRIVOP_GET_IVR))
>> >
>> > //
>> >
>> > Shouldn't those be asm volatile, but asm?
>>
>> IIRC, according to the gcc doc asm without outputs are volatile.
>
>Ah, right. From gcc info.
>> Assembler Instructions with C Expression Operands
>> An `asm' instruction without any output operands will be treated
>> identically to a volatile `asm' instruction.
Thank you for your comments.
I also think it's right.
And I found XEN_HYPER_GET_IVR is wrong because it doesn't have return value.
But it is not used, so I just remove it.
I updated my patch.
Signed-off-by: Akio Takebe <[EMAIL PROTECTED]>
Best Regards,
Akio Takebe
inline_asm_barrier.3.patch
Description: Binary data
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
