Renaming kvm_arch in view of upcoming architecture ports

PATCH In review Christian Ehrhardt 2 participants 2 messages Aug 15, 2007 1 message not in the archive KVM

Share & tools

Christian Ehrhardt

author

2007-08-15 11:49 UTC #0 lore raw

PATCH 1/1 Renaming kvm_arch in view of upcoming architecture ports

Hi,
in view of the upcoming architecture ports, this is a little cleanup patch that renames the current "_arch" to "_x86" e.g. kvm_arch_ops -> kvm_x86_ops

I discussed with some people about names like kvm_x86_arch_ops or kvm_subarch_ops, ... but at the end we thought that "arch" has a special meaning in linux and so it should be freed for the real architecture ports of kvm that show up slowly on the horizon (look at Tucson). I want to invite everyone to comment about what may be a more appropriate name in order to find out what naming scheme the community wants.

I attached the patch to keep the usual form, but actually it is just what comes out executing the following:
perl -p -i -e "s/_arch/_x86/g" drivers/kvm/*

Signature · 10 lines

Grüsse / regards, Christian Ehrhardt

IBM Linux Technology Center, Open Virtualization
+49 7031/16-3385
[email protected]
[email protected]

IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Johann Weihen Geschäftsführung: Herbert Kircher Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

drivers/kvm/kvm.h +4 -4

index 70231f3..a3dcc96 100644
@@ -415,7 +415,7 @@ struct descriptor_table {
 	unsigned long base;
 } __attribute__((packed));
 
-struct kvm_arch_ops {
+struct kvm_x86_ops {
 	int (*cpu_has_kvm_support)(void);          /* __init */
 	int (*disabled_by_bios)(void);             /* __init */
 	void (*hardware_enable)(void *dummy);      /* __init */

@@ -472,7 +472,7 @@ struct kvm_arch_ops {
 				unsigned char *hypercall_addr);
 };
 
-extern struct kvm_arch_ops *kvm_arch_ops;
+extern struct kvm_x86_ops *kvm_x86_ops;
 
 /* The guest did something we don't support. */
 #define pr_unimpl(vcpu, fmt, ...)					\

@@ -488,9 +488,9 @@ extern struct kvm_arch_ops *kvm_arch_ops;
 int kvm_vcpu_init(struct kvm_vcpu *vcpu, struct kvm *kvm, unsigned id);
 void kvm_vcpu_uninit(struct kvm_vcpu *vcpu);
 
-int kvm_init_arch(struct kvm_arch_ops *ops, unsigned int vcpu_size,
+int kvm_init_x86(struct kvm_x86_ops *ops, unsigned int vcpu_size,
 		  struct module *module);
-void kvm_exit_arch(void);
+void kvm_exit_x86(void);
 
 int kvm_mmu_module_init(void);
 void kvm_mmu_module_exit(void);

drivers/kvm/kvm_main.c +78 ~~-78~~

522 lines not on this page · raw message

drivers/kvm/mmu.c +3 -3

index bfe16d5..ce072f8 100644
@@ -965,7 +965,7 @@ static int nonpaging_init_context(struct kvm_vcpu *vcpu)
 static void kvm_mmu_flush_tlb(struct kvm_vcpu *vcpu)
 {
 	++vcpu->stat.tlb_flush;
-	kvm_arch_ops->tlb_flush(vcpu);
+	kvm_x86_ops->tlb_flush(vcpu);
 }
 
 static void paging_new_cr3(struct kvm_vcpu *vcpu)

@@ -978,7 +978,7 @@ static void inject_page_fault(struct kvm_vcpu *vcpu,
 			      u64 addr,
 			      u32 err_code)
 {
-	kvm_arch_ops->inject_page_fault(vcpu, addr, err_code);
+	kvm_x86_ops->inject_page_fault(vcpu, addr, err_code);
 }
 
 static void paging_free(struct kvm_vcpu *vcpu)

@@ -1072,7 +1072,7 @@ int kvm_mmu_load(struct kvm_vcpu *vcpu)
 	if (r)
 		goto out;
 	mmu_alloc_roots(vcpu);
-	kvm_arch_ops->set_cr3(vcpu, vcpu->mmu.root_hpa);
+	kvm_x86_ops->set_cr3(vcpu, vcpu->mmu.root_hpa);
 	kvm_mmu_flush_tlb(vcpu);
 out:
 	mutex_unlock(&vcpu->kvm->lock);

drivers/kvm/paging_tmpl.h +1 -1

index 660243b..6b094b4 100644
@@ -274,7 +274,7 @@ static void FNAME(set_pte_common)(struct kvm_vcpu *vcpu,
 			access_bits &= ~PT_WRITABLE_MASK;
 			if (is_writeble_pte(spte)) {
 				spte &= ~PT_WRITABLE_MASK;
-				kvm_arch_ops->tlb_flush(vcpu);
+				kvm_x86_ops->tlb_flush(vcpu);
 			}
 			if (write_fault)
 				*ptwrite = 1;

drivers/kvm/svm.c +3 -3

index e3c6d89..f96e02e 100644
@@ -1672,7 +1672,7 @@ static void svm_check_processor_compat(void *rtn)
 	*(int *)rtn = 0;
 }
 
-static struct kvm_arch_ops svm_arch_ops = {
+static struct kvm_x86_ops svm_x86_ops = {
 	.cpu_has_kvm_support = has_svm,
 	.disabled_by_bios = is_disabled,
 	.hardware_setup = svm_hardware_setup,

@@ -1724,13 +1724,13 @@ static struct kvm_arch_ops svm_arch_ops = {
 
 static int __init svm_init(void)
 {
-	return kvm_init_arch(&svm_arch_ops, sizeof(struct vcpu_svm),
+	return kvm_init_x86(&svm_x86_ops, sizeof(struct vcpu_svm),
 			      THIS_MODULE);
 }
 
 static void __exit svm_exit(void)
 {
-	kvm_exit_arch();
+	kvm_exit_x86();
 }
 
 module_init(svm_init)

drivers/kvm/vmx.c +3 -3

index 906d4fa..b60276f 100644
@@ -2375,7 +2375,7 @@ static void __init vmx_check_processor_compat(void *rtn)
 	}
 }
 
-static struct kvm_arch_ops vmx_arch_ops = {
+static struct kvm_x86_ops vmx_x86_ops = {
 	.cpu_has_kvm_support = cpu_has_kvm_support,
 	.disabled_by_bios = vmx_disabled_by_bios,
 	.hardware_setup = hardware_setup,

@@ -2452,7 +2452,7 @@ static int __init vmx_init(void)
 	memset(iova, 0xff, PAGE_SIZE);
 	kunmap(vmx_io_bitmap_b);
 
-	r = kvm_init_arch(&vmx_arch_ops, sizeof(struct vcpu_vmx), THIS_MODULE);
+	r = kvm_init_x86(&vmx_x86_ops, sizeof(struct vcpu_vmx), THIS_MODULE);
 	if (r)
 		goto out1;

@@ -2470,7 +2470,7 @@ static void __exit vmx_exit(void)
 	__free_page(vmx_io_bitmap_b);
 	__free_page(vmx_io_bitmap_a);
 
-	kvm_exit_arch();
+	kvm_exit_x86();
 }
 
 module_init(vmx_init)

drivers/kvm/x86_emulate.c +2 -2

index b4f439c..38300f1 100644
@@ -1399,7 +1399,7 @@ twobyte_special_insn:
 			| ((u64)_regs[VCPU_REGS_RDX] << 32);
 		rc = kvm_set_msr(ctxt->vcpu, _regs[VCPU_REGS_RCX], msr_data);
 		if (rc) {
-			kvm_arch_ops->inject_gp(ctxt->vcpu, 0);
+			kvm_x86_ops->inject_gp(ctxt->vcpu, 0);
 			_eip = ctxt->vcpu->rip;
 		}
 		rc = X86EMUL_CONTINUE;

@@ -1408,7 +1408,7 @@ twobyte_special_insn:
 		/* rdmsr */
 		rc = kvm_get_msr(ctxt->vcpu, _regs[VCPU_REGS_RCX], &msr_data);
 		if (rc) {
-			kvm_arch_ops->inject_gp(ctxt->vcpu, 0);
+			kvm_x86_ops->inject_gp(ctxt->vcpu, 0);
 			_eip = ctxt->vcpu->rip;
 		} else {
 			_regs[VCPU_REGS_RAX] = (u32)msr_data;

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/

_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel

A message that is not in the archive (sent off-list or not yet received): 46C2E84C.3030101-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org

Avi Kivity

2007-08-15 12:01 UTC #2 lore raw

Quoted 14 lines · Christian Ehrhardt

Hi,
in view of the upcoming architecture ports, this is a little cleanup patch that renames the current "_arch" to "_x86"
e.g. kvm_arch_ops -> kvm_x86_ops
I discussed with some people about names like kvm_x86_arch_ops or kvm_subarch_ops, ... but at the end we thought that "arch" has a special meaning in linux and so it should be freed for the real architecture ports of kvm that show up slowly on the horizon (look at Tucson).
I want to invite everyone to comment about what may be a more appropriate name in order to find out what naming scheme the community wants.

Quoted 4 lines

I attached the patch to keep the usual form, but actually it is just what comes out executing the following:
perl -p -i -e "s/_arch/_x86/g" drivers/kvm/*

Seems a sensible name. I thought of subarch at first, but x86 is more explicit.

I'll apply this after the lapic merge.

Signature · 8 lines

error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/