Re: [PATCH] Rename KVM_UPSTREAM to OBSOLETE_KVM_IMPL
On 09/13/2010 09:03 PM, Jan Kiszka wrote: Am 13.09.2010 20:56, Anthony Liguori wrote: On 09/13/2010 01:52 PM, Jan Kiszka wrote: Am 13.09.2010 19:54, Avi Kivity wrote: The symbol KVM_UPSTREAM is used to mark sections of code that are part of the upstream kvm implemetation that is not used in qemu-kvm. However the name becomes ambiguous if qemu-kvm is merged upstream. I doubt this is describing all cases correctly as well. Some changes should rather happen the other way around (e.g. you surely don't want to obsolete x86 kvm_arch_put/get_registers in favor of kvm_arch_load/save_regs, do you?). There's really no perfect name to describe what we're actually doing here. It's probably not a detail worth worrying that much about. I don't mind the name as long as it doesn't reflect the strategy (but why this change at all then?). It would be silly to have a define KVM_UPSTREAM in upstream. Jan (who would prefer to have the time for doing the cleanups) Hopefully, with a single source base doing the cleanups would be easier, so a more efficient use of the time we have. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Rename KVM_UPSTREAM to OBSOLETE_KVM_IMPL
Am 14.09.2010 11:29, Avi Kivity wrote: On 09/13/2010 09:03 PM, Jan Kiszka wrote: Am 13.09.2010 20:56, Anthony Liguori wrote: On 09/13/2010 01:52 PM, Jan Kiszka wrote: Am 13.09.2010 19:54, Avi Kivity wrote: The symbol KVM_UPSTREAM is used to mark sections of code that are part of the upstream kvm implemetation that is not used in qemu-kvm. However the name becomes ambiguous if qemu-kvm is merged upstream. I doubt this is describing all cases correctly as well. Some changes should rather happen the other way around (e.g. you surely don't want to obsolete x86 kvm_arch_put/get_registers in favor of kvm_arch_load/save_regs, do you?). There's really no perfect name to describe what we're actually doing here. It's probably not a detail worth worrying that much about. I don't mind the name as long as it doesn't reflect the strategy (but why this change at all then?). It would be silly to have a define KVM_UPSTREAM in upstream. So the new plan is to dump qemu-kvm into upstream practically unmodified? Jan (who would prefer to have the time for doing the cleanups) Hopefully, with a single source base doing the cleanups would be easier, so a more efficient use of the time we have. I wouldn't expect much technical impact of this step. The effort of comparing both code bases, merging the best of them together, and testing the result will remain the same. Exposing the code via upstream may attract new contributions, but then I'm a bit worried that people could start work on removing the wrong part (as it is marked obsolete). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Rename KVM_UPSTREAM to OBSOLETE_KVM_IMPL
On 09/14/2010 12:42 PM, Jan Kiszka wrote: Am 14.09.2010 11:29, Avi Kivity wrote: On 09/13/2010 09:03 PM, Jan Kiszka wrote: Am 13.09.2010 20:56, Anthony Liguori wrote: On 09/13/2010 01:52 PM, Jan Kiszka wrote: Am 13.09.2010 19:54, Avi Kivity wrote: The symbol KVM_UPSTREAM is used to mark sections of code that are part of the upstream kvm implemetation that is not used in qemu-kvm. However the name becomes ambiguous if qemu-kvm is merged upstream. I doubt this is describing all cases correctly as well. Some changes should rather happen the other way around (e.g. you surely don't want to obsolete x86 kvm_arch_put/get_registers in favor of kvm_arch_load/save_regs, do you?). There's really no perfect name to describe what we're actually doing here. It's probably not a detail worth worrying that much about. I don't mind the name as long as it doesn't reflect the strategy (but why this change at all then?). It would be silly to have a define KVM_UPSTREAM in upstream. So the new plan is to dump qemu-kvm into upstream practically unmodified? Yes. While the upstream implementation is cleaner, it lacks features and testing. So we'll work at cleaning the qemu-kvm implementation instead of improving the upstream one. Jan (who would prefer to have the time for doing the cleanups) Hopefully, with a single source base doing the cleanups would be easier, so a more efficient use of the time we have. I wouldn't expect much technical impact of this step. The effort of comparing both code bases, merging the best of them together, and testing the result will remain the same. Exposing the code via upstream may attract new contributions, but then I'm a bit worried that people could start work on removing the wrong part (as it is marked obsolete). It still lives forever in git. In any case, taking two code bases and merging them is much harder than picking one, however ugly, and beautifying it one bit at a time (also much easier to review). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Rename KVM_UPSTREAM to OBSOLETE_KVM_IMPL
Am 13.09.2010 19:54, Avi Kivity wrote:
The symbol KVM_UPSTREAM is used to mark sections of code that are part of
the upstream kvm implemetation that is not used in qemu-kvm. However the
name becomes ambiguous if qemu-kvm is merged upstream.
I doubt this is describing all cases correctly as well. Some changes
should rather happen the other way around (e.g. you surely don't want to
obsolete x86 kvm_arch_put/get_registers in favor of
kvm_arch_load/save_regs, do you?).
Jan
Rename the symbol to avoid confusion.
Signed-off-by: Avi Kivity a...@redhat.com
---
cpus.c|2 +-
kvm-all.c | 16
kvm.h |6 +++---
target-i386/kvm.c | 10 +-
vl.c |4 ++--
5 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/cpus.c b/cpus.c
index c545a62..99c04d1 100644
--- a/cpus.c
+++ b/cpus.c
@@ -299,7 +299,7 @@ void qemu_notify_event(void)
}
}
-#if defined(KVM_UPSTREAM) || !defined(CONFIG_KVM)
+#if defined(OBSOLETE_KVM_IMPL) || !defined(CONFIG_KVM)
void qemu_mutex_lock_iothread(void) {}
void qemu_mutex_unlock_iothread(void) {}
#endif
diff --git a/kvm-all.c b/kvm-all.c
index 4ff75c4..d4b0861 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -41,7 +41,7 @@
do { } while (0)
#endif
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
typedef struct KVMSlot
{
@@ -156,7 +156,7 @@ static int kvm_set_user_memory_region(KVMState *s,
KVMSlot *slot)
return kvm_vm_ioctl(s, KVM_SET_USER_MEMORY_REGION, mem);
}
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
static void kvm_reset_vcpu(void *opaque)
{
CPUState *env = opaque;
@@ -176,7 +176,7 @@ int kvm_pit_in_kernel(void)
}
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
int kvm_init_vcpu(CPUState *env)
{
KVMState *s = kvm_state;
@@ -594,7 +594,7 @@ void kvm_cpu_register_phys_memory_client(void)
cpu_register_phys_memory_client(kvm_cpu_phys_memory_client);
}
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
int kvm_init(int smp_cpus)
{
@@ -816,7 +816,7 @@ void kvm_flush_coalesced_mmio_buffer(void)
#endif
}
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
static void do_kvm_cpu_synchronize_state(void *_env)
{
@@ -1038,7 +1038,7 @@ int kvm_has_debugregs(void)
return kvm_state-debugregs;
}
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
int kvm_has_xsave(void)
{
return kvm_state-xsave;
@@ -1069,10 +1069,10 @@ void kvm_setup_guest_memory(void *start, size_t size)
}
#ifdef KVM_CAP_SET_GUEST_DEBUG
-#ifndef KVM_UPSTREAM
+#ifndef OBSOLETE_KVM_IMPL
#define run_on_cpu on_vcpu
static void on_vcpu(CPUState *env, void (*func)(void *data), void *data);
-#endif /* !KVM_UPSTREAM */
+#endif /* !OBSOLETE_KVM_IMPL */
struct kvm_sw_breakpoint *kvm_find_sw_breakpoint(CPUState *env,
target_ulong pc)
diff --git a/kvm.h b/kvm.h
index d321fce..56236ae 100644
--- a/kvm.h
+++ b/kvm.h
@@ -31,13 +31,13 @@ extern int kvm_allowed;
#define kvm_enabled() (0)
#endif
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
struct kvm_run;
/* external API */
int kvm_init(int smp_cpus);
-#endif /* KVM_UPSTREAM */
+#endif /* OBSOLETE_KVM_IMPL */
int kvm_has_sync_mmu(void);
int kvm_has_vcpu_events(void);
@@ -96,7 +96,7 @@ int kvm_arch_handle_exit(CPUState *env, struct kvm_run
*run);
int kvm_arch_pre_run(CPUState *env, struct kvm_run *run);
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
int kvm_arch_process_irqchip_events(CPUState *env);
#endif
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index b00e80d..f4fc063 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -188,7 +188,7 @@ int kvm_arch_init_vcpu(CPUState *env)
return r;
}
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
env-mp_state = KVM_MP_STATE_RUNNABLE;
@@ -304,7 +304,7 @@ void kvm_arch_reset_vcpu(CPUState *env)
env-mp_state = KVM_MP_STATE_RUNNABLE;
}
}
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
static int kvm_has_msr_star(CPUState *env)
{
@@ -644,7 +644,7 @@ static void kvm_msr_entry_set(struct kvm_msr_entry *entry,
entry-data = value;
}
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
static int kvm_put_msrs(CPUState *env, int level)
{
struct {
@@ -1104,7 +1104,7 @@ static int kvm_get_debugregs(CPUState *env)
return 0;
}
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
int kvm_arch_put_registers(CPUState *env, int level)
{
int ret;
@@ -1242,7 +1242,7 @@ int kvm_arch_post_run(CPUState *env, struct kvm_run
*run)
return 0;
}
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
int kvm_arch_process_irqchip_events(CPUState *env)
{
diff --git a/vl.c b/vl.c
index 22a3616..378a176 100644
--- a/vl.c
+++ b/vl.c
@@ -2466,7 +2466,7 @@ int main(int argc, char **argv, char **envp)
Re: [PATCH] Rename KVM_UPSTREAM to OBSOLETE_KVM_IMPL
On 09/13/2010 01:52 PM, Jan Kiszka wrote:
Am 13.09.2010 19:54, Avi Kivity wrote:
The symbol KVM_UPSTREAM is used to mark sections of code that are part of
the upstream kvm implemetation that is not used in qemu-kvm. However the
name becomes ambiguous if qemu-kvm is merged upstream.
I doubt this is describing all cases correctly as well. Some changes
should rather happen the other way around (e.g. you surely don't want to
obsolete x86 kvm_arch_put/get_registers in favor of
kvm_arch_load/save_regs, do you?).
There's really no perfect name to describe what we're actually doing
here. It's probably not a detail worth worrying that much about.
Regards,
Anthony Liguori
Jan
Rename the symbol to avoid confusion.
Signed-off-by: Avi Kivitya...@redhat.com
---
cpus.c|2 +-
kvm-all.c | 16
kvm.h |6 +++---
target-i386/kvm.c | 10 +-
vl.c |4 ++--
5 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/cpus.c b/cpus.c
index c545a62..99c04d1 100644
--- a/cpus.c
+++ b/cpus.c
@@ -299,7 +299,7 @@ void qemu_notify_event(void)
}
}
-#if defined(KVM_UPSTREAM) || !defined(CONFIG_KVM)
+#if defined(OBSOLETE_KVM_IMPL) || !defined(CONFIG_KVM)
void qemu_mutex_lock_iothread(void) {}
void qemu_mutex_unlock_iothread(void) {}
#endif
diff --git a/kvm-all.c b/kvm-all.c
index 4ff75c4..d4b0861 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -41,7 +41,7 @@
do { } while (0)
#endif
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
typedef struct KVMSlot
{
@@ -156,7 +156,7 @@ static int kvm_set_user_memory_region(KVMState *s, KVMSlot
*slot)
return kvm_vm_ioctl(s, KVM_SET_USER_MEMORY_REGION,mem);
}
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
static void kvm_reset_vcpu(void *opaque)
{
CPUState *env = opaque;
@@ -176,7 +176,7 @@ int kvm_pit_in_kernel(void)
}
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
int kvm_init_vcpu(CPUState *env)
{
KVMState *s = kvm_state;
@@ -594,7 +594,7 @@ void kvm_cpu_register_phys_memory_client(void)
cpu_register_phys_memory_client(kvm_cpu_phys_memory_client);
}
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
int kvm_init(int smp_cpus)
{
@@ -816,7 +816,7 @@ void kvm_flush_coalesced_mmio_buffer(void)
#endif
}
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
static void do_kvm_cpu_synchronize_state(void *_env)
{
@@ -1038,7 +1038,7 @@ int kvm_has_debugregs(void)
return kvm_state-debugregs;
}
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
int kvm_has_xsave(void)
{
return kvm_state-xsave;
@@ -1069,10 +1069,10 @@ void kvm_setup_guest_memory(void *start, size_t size)
}
#ifdef KVM_CAP_SET_GUEST_DEBUG
-#ifndef KVM_UPSTREAM
+#ifndef OBSOLETE_KVM_IMPL
#define run_on_cpu on_vcpu
static void on_vcpu(CPUState *env, void (*func)(void *data), void *data);
-#endif /* !KVM_UPSTREAM */
+#endif /* !OBSOLETE_KVM_IMPL */
struct kvm_sw_breakpoint *kvm_find_sw_breakpoint(CPUState *env,
target_ulong pc)
diff --git a/kvm.h b/kvm.h
index d321fce..56236ae 100644
--- a/kvm.h
+++ b/kvm.h
@@ -31,13 +31,13 @@ extern int kvm_allowed;
#define kvm_enabled() (0)
#endif
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
struct kvm_run;
/* external API */
int kvm_init(int smp_cpus);
-#endif /* KVM_UPSTREAM */
+#endif /* OBSOLETE_KVM_IMPL */
int kvm_has_sync_mmu(void);
int kvm_has_vcpu_events(void);
@@ -96,7 +96,7 @@ int kvm_arch_handle_exit(CPUState *env, struct kvm_run *run);
int kvm_arch_pre_run(CPUState *env, struct kvm_run *run);
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
int kvm_arch_process_irqchip_events(CPUState *env);
#endif
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index b00e80d..f4fc063 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -188,7 +188,7 @@ int kvm_arch_init_vcpu(CPUState *env)
return r;
}
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
env-mp_state = KVM_MP_STATE_RUNNABLE;
@@ -304,7 +304,7 @@ void kvm_arch_reset_vcpu(CPUState *env)
env-mp_state = KVM_MP_STATE_RUNNABLE;
}
}
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
static int kvm_has_msr_star(CPUState *env)
{
@@ -644,7 +644,7 @@ static void kvm_msr_entry_set(struct kvm_msr_entry *entry,
entry-data = value;
}
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
static int kvm_put_msrs(CPUState *env, int level)
{
struct {
@@ -1104,7 +1104,7 @@ static int kvm_get_debugregs(CPUState *env)
return 0;
}
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
int kvm_arch_put_registers(CPUState *env, int level)
{
int ret;
@@ -1242,7 +1242,7 @@ int kvm_arch_post_run(CPUState *env, struct kvm_run *run)
return 0;
}
-#ifdef KVM_UPSTREAM
+#ifdef OBSOLETE_KVM_IMPL
int kvm_arch_process_irqchip_events(CPUState *env)
{
diff --git a/vl.c b/vl.c
index 22a3616..378a176 100644
---
Re: [PATCH] Rename KVM_UPSTREAM to OBSOLETE_KVM_IMPL
Am 13.09.2010 20:56, Anthony Liguori wrote: On 09/13/2010 01:52 PM, Jan Kiszka wrote: Am 13.09.2010 19:54, Avi Kivity wrote: The symbol KVM_UPSTREAM is used to mark sections of code that are part of the upstream kvm implemetation that is not used in qemu-kvm. However the name becomes ambiguous if qemu-kvm is merged upstream. I doubt this is describing all cases correctly as well. Some changes should rather happen the other way around (e.g. you surely don't want to obsolete x86 kvm_arch_put/get_registers in favor of kvm_arch_load/save_regs, do you?). There's really no perfect name to describe what we're actually doing here. It's probably not a detail worth worrying that much about. I don't mind the name as long as it doesn't reflect the strategy (but why this change at all then?). Jan (who would prefer to have the time for doing the cleanups) signature.asc Description: OpenPGP digital signature
