Donation
Dave And Nancy HoneyWell Donation Of £1,500,000.00GBP Contact us for your charity donation. Email: daveandhoneyw...@live.com -- 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
[PATCH 2/2] kvm tools: arm: add support for ARM Cortex-A7
The Cortex-A7 is very similar to the Cortex-A15 and as such there is very
little extra infrastructure required for KVM tool to be able to create
A7-guests.
This patch adds the basic support and allows booting of A7 guests on A7
hosts. It depends on Cortex-A7 support patches posted recently to the kvmarm
list.
Signed-off-by: Jonathan Austin
---
tools/kvm/arm/aarch32/arm-cpu.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/tools/kvm/arm/aarch32/arm-cpu.c b/tools/kvm/arm/aarch32/arm-cpu.c
index 8817d2a..71b98fe 100644
--- a/tools/kvm/arm/aarch32/arm-cpu.c
+++ b/tools/kvm/arm/aarch32/arm-cpu.c
@@ -28,8 +28,15 @@ static struct kvm_arm_target target_cortex_a15 = {
.init = arm_cpu__vcpu_init,
};
+static struct kvm_arm_target target_cortex_a7 = {
+ .id = KVM_ARM_TARGET_CORTEX_A7,
+ .compatible = "arm,cortex-a7",
+ .init = arm_cpu__vcpu_init,
+};
+
static int arm_cpu__core_init(struct kvm *kvm)
{
- return kvm_cpu__register_kvm_arm_target(&target_cortex_a15);
+ return (kvm_cpu__register_kvm_arm_target(&target_cortex_a15) ||
+ kvm_cpu__register_kvm_arm_target(&target_cortex_a7));
}
core_init(arm_cpu__core_init);
--
1.7.9.5
--
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
[PATCH 0/2] kvm tools: arm: support Cortex-A7 CPUs
These two patches allow KVM-tool to exploit the Cortex-A7 support for KVM
recently posted to the kvmarm mailing list.
The first patch is a standalone cleanup to extract previously duplicated timer
setup code, and allows us to add A7 support in a small subsequent patch.
Note: the removal of the timer code makes git refuse to see the following:
tools/kvm/arm/aarch32/{cortex_a15.c --> arm-cpu.c}
tools/kvm/arm/aarch64/{cortex_a57.c --> arm-cpu.c}
(even when passed -M40 git's decisions about what's new/renamed are confusing)
The second patch should not be merged before the Cortex-A7 support patches
posted recently to the kvmarm list hit the kernel, as kvm-tool for ARM will not
build if KVM_ARM_TARGET_CORTEX_A7 (added with that series) is not defined.
Jonathan Austin (2):
kvm tools: arm: extract common timer support code for ARM cpus
kvm tools: arm: add support for ARM Cortex-A7
tools/kvm/Makefile |6 +--
tools/kvm/arm/aarch32/arm-cpu.c | 42
tools/kvm/arm/aarch32/cortex-a15.c | 61 ---
tools/kvm/arm/aarch64/arm-cpu.c | 50 +++
tools/kvm/arm/aarch64/cortex-a57.c | 80 --
tools/kvm/arm/include/arm-common/timer.h |6 +++
tools/kvm/arm/timer.c| 38 ++
7 files changed, 139 insertions(+), 144 deletions(-)
create mode 100644 tools/kvm/arm/aarch32/arm-cpu.c
delete mode 100644 tools/kvm/arm/aarch32/cortex-a15.c
create mode 100644 tools/kvm/arm/aarch64/arm-cpu.c
delete mode 100644 tools/kvm/arm/aarch64/cortex-a57.c
create mode 100644 tools/kvm/arm/include/arm-common/timer.h
create mode 100644 tools/kvm/arm/timer.c
--
1.7.9.5
--
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
[PATCH 1/2] kvm tools: arm: extract common timer support code for ARM cpus
The ARM V7 and V8 CPUs use the nearly identical support code for generating
timer DT nodes as they both use ARM's architected timers. This code is currently
duplicated for AArch32 and AArch64.
This cleanup patch generalises timer DT node generation to follow the same
pattern as for the GIC. The ability of a DT node to contain multiple compatible
strings is exploited to allow an identical DT node to be used on V7 and V8
platforms.
Signed-off-by: Jonathan Austin
Acked-by: Will Deacon
---
tools/kvm/Makefile |6 +--
tools/kvm/arm/aarch32/arm-cpu.c | 35 +
tools/kvm/arm/aarch32/cortex-a15.c | 61 ---
tools/kvm/arm/aarch64/arm-cpu.c | 50 +++
tools/kvm/arm/aarch64/cortex-a57.c | 80 --
tools/kvm/arm/include/arm-common/timer.h |6 +++
tools/kvm/arm/timer.c| 38 ++
7 files changed, 132 insertions(+), 144 deletions(-)
create mode 100644 tools/kvm/arm/aarch32/arm-cpu.c
delete mode 100644 tools/kvm/arm/aarch32/cortex-a15.c
create mode 100644 tools/kvm/arm/aarch64/arm-cpu.c
delete mode 100644 tools/kvm/arm/aarch64/cortex-a57.c
create mode 100644 tools/kvm/arm/include/arm-common/timer.h
create mode 100644 tools/kvm/arm/timer.c
diff --git a/tools/kvm/Makefile b/tools/kvm/Makefile
index b614aab..27fb2fb 100644
--- a/tools/kvm/Makefile
+++ b/tools/kvm/Makefile
@@ -157,12 +157,12 @@ endif
# ARM
OBJS_ARM_COMMON:= arm/fdt.o arm/gic.o arm/ioport.o arm/irq.o \
- arm/kvm.o arm/kvm-cpu.o
+ arm/kvm.o arm/kvm-cpu.o arm/timer.o
HDRS_ARM_COMMON:= arm/include
ifeq ($(ARCH), arm)
DEFINES += -DCONFIG_ARM
OBJS+= $(OBJS_ARM_COMMON)
- OBJS+= arm/aarch32/cortex-a15.o
+ OBJS+= arm/aarch32/arm-cpu.o
OBJS+= arm/aarch32/kvm-cpu.o
ARCH_INCLUDE:= $(HDRS_ARM_COMMON)
ARCH_INCLUDE+= -Iarm/aarch32/include
@@ -175,7 +175,7 @@ endif
ifeq ($(ARCH), arm64)
DEFINES += -DCONFIG_ARM64
OBJS+= $(OBJS_ARM_COMMON)
- OBJS+= arm/aarch64/cortex-a57.o
+ OBJS+= arm/aarch64/arm-cpu.o
OBJS+= arm/aarch64/kvm-cpu.o
ARCH_INCLUDE:= $(HDRS_ARM_COMMON)
ARCH_INCLUDE+= -Iarm/aarch64/include
diff --git a/tools/kvm/arm/aarch32/arm-cpu.c b/tools/kvm/arm/aarch32/arm-cpu.c
new file mode 100644
index 000..8817d2a
--- /dev/null
+++ b/tools/kvm/arm/aarch32/arm-cpu.c
@@ -0,0 +1,35 @@
+#include "kvm/kvm.h"
+#include "kvm/kvm-cpu.h"
+#include "kvm/util.h"
+
+#include "arm-common/gic.h"
+#include "arm-common/timer.h"
+
+#include
+#include
+
+static void generate_fdt_nodes(void *fdt, struct kvm *kvm, u32 gic_phandle)
+{
+ int timer_interrupts[4] = {13, 14, 11, 10};
+
+ gic__generate_fdt_nodes(fdt, gic_phandle);
+ timer__generate_fdt_nodes(fdt, kvm, timer_interrupts);
+}
+
+static int arm_cpu__vcpu_init(struct kvm_cpu *vcpu)
+{
+ vcpu->generate_fdt_nodes = generate_fdt_nodes;
+ return 0;
+}
+
+static struct kvm_arm_target target_cortex_a15 = {
+ .id = KVM_ARM_TARGET_CORTEX_A15,
+ .compatible = "arm,cortex-a15",
+ .init = arm_cpu__vcpu_init,
+};
+
+static int arm_cpu__core_init(struct kvm *kvm)
+{
+ return kvm_cpu__register_kvm_arm_target(&target_cortex_a15);
+}
+core_init(arm_cpu__core_init);
diff --git a/tools/kvm/arm/aarch32/cortex-a15.c
b/tools/kvm/arm/aarch32/cortex-a15.c
deleted file mode 100644
index ca65af7..000
--- a/tools/kvm/arm/aarch32/cortex-a15.c
+++ /dev/null
@@ -1,61 +0,0 @@
-#include "kvm/fdt.h"
-#include "kvm/kvm.h"
-#include "kvm/kvm-cpu.h"
-#include "kvm/util.h"
-
-#include "arm-common/gic.h"
-
-#include
-#include
-
-static void generate_timer_nodes(void *fdt, struct kvm *kvm)
-{
- u32 cpu_mask = (((1 << kvm->nrcpus) - 1) << GIC_FDT_IRQ_PPI_CPU_SHIFT) \
- & GIC_FDT_IRQ_PPI_CPU_MASK;
- u32 irq_prop[] = {
- cpu_to_fdt32(GIC_FDT_IRQ_TYPE_PPI),
- cpu_to_fdt32(13),
- cpu_to_fdt32(cpu_mask | GIC_FDT_IRQ_FLAGS_EDGE_LO_HI),
-
- cpu_to_fdt32(GIC_FDT_IRQ_TYPE_PPI),
- cpu_to_fdt32(14),
- cpu_to_fdt32(cpu_mask | GIC_FDT_IRQ_FLAGS_EDGE_LO_HI),
-
- cpu_to_fdt32(GIC_FDT_IRQ_TYPE_PPI),
- cpu_to_fdt32(11),
- cpu_to_fdt32(cpu_mask | GIC_FDT_IRQ_FLAGS_EDGE_LO_HI),
-
- cpu_to_fdt32(GIC_FDT_IRQ_TYPE_PPI),
- cpu_to_fdt32(10),
- cpu_to_fdt32(cpu_mask | GIC_FDT_IRQ_FLAGS_EDGE_LO_HI),
- };
-
- _FDT(fdt_begin_node(fdt, "timer"));
- _FDT(fdt_property_string(fdt, "compatible", "arm,armv7-timer"));
- _FDT(fdt_property(fdt, "interrupts", irq_prop, sizeof(irq_prop)));
- _FDT(fdt_en
Re: [RFC PATCH 09/11] kvm: simplify processor compat check
Il 27/09/2013 15:13, Aneesh Kumar K.V ha scritto:
> Alexander Graf writes:
>
>> On 27.09.2013, at 12:03, Aneesh Kumar K.V wrote:
>>
>>> From: "Aneesh Kumar K.V"
>>
>> Missing patch description.
>>
>>> Signed-off-by: Aneesh Kumar K.V
>>
>> I fail to see how this really simplifies things, but at the end of the
>> day it's Gleb's and Paolo's call.
>
> will do. It avoid calling
>
> for_each_online_cpu(cpu) {
> smp_call_function_single()
>
> on multiple architecture.
I agree with Alex.
The current code is not specially awesome; having
kvm_arch_check_processor_compat take an int* disguised as a void* is a
bit ugly indeed.
However, the API makes sense and tells you that it is being passed as a
callback (to smp_call_function_single in this case).
You are making the API more complicated to use on the arch layer
(because arch maintainers now have to think "do I need to check this on
all online CPUs?") and making the "leaf" POWER code less legible because
it still has the weird void()(void *) calling convention.
If anything, you could change kvm_arch_check_processor_compat to return
an int and accept no argument, and introduce a wrapper that kvm_init
passes to smp_call_function_single.
Paolo
> We also want to make the smp call function a callback of opaque. Hence
> this should be made arch specific.
>
> int kvm_arch_check_processor_compat(void *opaque)
> {
> int r,cpu;
> struct kvmppc_ops *kvm_ops = (struct kvmppc_ops *)opaque;
> for_each_online_cpu(cpu) {
> smp_call_function_single(cpu,
>kvm_ops->check_processor_compat,
>&r, 1);
> if (r < 0)
> break;
> }
> return r;
> }
>
> against
>
> - for_each_online_cpu(cpu) {
> - smp_call_function_single(cpu,
> - kvm_arch_check_processor_compat,
> - &r, 1);
> - if (r < 0)
> - goto out_free_1;
> - }
> +
> + r = kvm_arch_check_processor_compat(opaque);
> + if (r < 0)
> + goto out_free_1;
>
>
>
>>
>> Which brings me to the next issue: You forgot to CC kvm@vger on your
>> patch set. Gleb and Paolo don't read kvm-ppc@vger. And they shouldn't
>> have to. Every kvm patch that you want review on or that should get
>> applied needs to be sent to kvm@vger. If you want to tag it as PPC
>> specific patch, do so by CC'ing kvm-ppc@vger.
>
> Will do in the next update
>
> -aneesh
>
--
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 1/6] kvm: Add KVM_GET_EMULATED_CPUID
On Thu, Sep 26, 2013 at 10:32:06PM +0200, Borislav Petkov wrote: > On Thu, Sep 26, 2013 at 04:20:59PM -0300, Eduardo Habkost wrote: > > Please point me to the code that does this, because I don't see it on > > patch 6/6. > > @@ -1850,7 +1850,14 @@ static void filter_features_for_kvm(X86CPU *cpu) > wi->cpuid_ecx, > wi->cpuid_reg); > uint32_t requested_features = env->features[w]; > + > +uint32_t emul_features = kvm_arch_get_emulated_cpuid(s, > wi->cpuid_eax, > + > wi->cpuid_ecx, > + > wi->cpuid_reg); > + > env->features[w] &= host_feat; > +env->features[w] |= (requested_features & emul_features); > > Basically we give the requested_features a second chance here. > > If we don't request an emulated feature, it won't get enabled. The problem here is that "requested_features" doesn't include just the explicit "+flag" flags, but any flag included in the CPU model definition. See the "-cpu n270" example below. > > > > If you start with "-cpu Haswell", MOVBE > > > will be already set in the host CPUID. > > > > > > Or am I missing something? > > > > In the Haswell example, it is unlikely but possible in theory: you would > > need a CPU that supported all features from Haswell except movbe. But > > what will happen if you are using "-cpu n270,enforce" on a SandyBridge > > host? > > That's an interesting question: AFAICT, it will fail because MOVBE is > not available on the host, right? It should, but your patch will make it stop failing because of MOVBE, as now it can be emulated[1]. > > And if so, then this is correct behavior IMHO, or how exactly is the > "enforce" thing supposed to work? Enforce host CPUID? "enforce" makes sure all features are really being enabled. It makes QEMU abort if there's any feature that can't be enabled on that host. [1] Maybe one source of confusion is that the existing code have two feature-filtering functions doing basically the same thing: filter_features_for_kvm() and kvm_check_features_against_host(). That's something we must clean up, and they should be unified. "enforce" should become synonymous to "make sure filtered_features is all zeroes". This way, libvirt can emulate what 'enforce" does while being able to collect detailed error information (which is not easy to do if QEMU simply aborts). > > > Also, we don't know anything about future CPUs or future features > > that will end up on EMULATED_CPUID. The current code doesn't have > > anything to differentiate features that were already included in the > > CPU definition and ones explicitly enabled in the command-line (and I > > would like to keep it that way). > > Ok. > > > And just because a feature was explicitly enabled in the command-line, > > that doesn't mean the user believe it is acceptable to get it running > > in emulated mode. That's why I propose a new "emulate" flag, to allow > > features to be enabled in emulated mode. > > And I think, saying "-cpu ...,+movbe" is an explicit statement enough to > say that yes, I am starting this guest and I want MOVBE emulation. Not necessarily. libvirt has some code that will translate its own CPU model definition to a "-cpu Model,+flag,+flag,+flag,-flag" command-line when necessary. It is by design that there is no difference between explicit "+flag" options and existing flags from the CPU model definition. > > > Well, x2apic is emulated by KVM, and it is on SUPPORTED_CPUID. Ditto > > for tsc-deadline. Or are you talking specifically about instruction > > emulation? > > Basically, I'm viewing this from a very practical standpoint - if I > build a kernel which requires MOVBE support but I cannot boot it in kvm > because it doesn't emulate MOVBE (TCG does now but it didn't before) > I'd like to be able to address that shortcoming by emulating that > instruction, if possible. > > And the whole discussion grew out from the standpoint of being able to > emulate stuff so that you can do quick and dirty booting of kernels but > not show that emulation capability to the wide audience since it is slow > and it shouldn't be used and then migration has issues, etc, etc. > > But hey, I don't really care all that much if I have to also say > -emulate in order to get my functionality. OK, I undestand your use case, now. Thanks for your explanation. -- Eduardo -- 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 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems
On 09/26/2013 12:01 PM, Michael Ellerman wrote:
> +int powernv_hwrng_present(void)
> +{
> + return __raw_get_cpu_var(powernv_rng) != NULL;
> +}
> +
> static unsigned long rng_whiten(struct powernv_rng *rng, unsigned long val)
> {
> unsigned long parity;
> @@ -42,6 +48,17 @@ static unsigned long rng_whiten(struct powernv_rng *rng,
> unsigned long val)
> return val;
> }
>
> +int powernv_get_random_real_mode(unsigned long *v)
> +{
> + struct powernv_rng *rng;
> +
> + rng = __raw_get_cpu_var(powernv_rng);
> +
> + *v = rng_whiten(rng, in_rm64(rng->regs_real));
> +
Will it be in_be64() instead of in_rm64() ? Its failing the build here. Except
this
all individual patches build correctly.
Regards
Anshuman
--
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: [RFC PATCH 09/11] kvm: simplify processor compat check
Alexander Graf writes:
> On 27.09.2013, at 12:03, Aneesh Kumar K.V wrote:
>
>> From: "Aneesh Kumar K.V"
>
> Missing patch description.
>
>> Signed-off-by: Aneesh Kumar K.V
>
> I fail to see how this really simplifies things, but at the end of the
> day it's Gleb's and Paolo's call.
will do. It avoid calling
for_each_online_cpu(cpu) {
smp_call_function_single()
on multiple architecture.
We also want to make the smp call function a callback of opaque. Hence
this should be made arch specific.
int kvm_arch_check_processor_compat(void *opaque)
{
int r,cpu;
struct kvmppc_ops *kvm_ops = (struct kvmppc_ops *)opaque;
for_each_online_cpu(cpu) {
smp_call_function_single(cpu,
kvm_ops->check_processor_compat,
&r, 1);
if (r < 0)
break;
}
return r;
}
against
- for_each_online_cpu(cpu) {
- smp_call_function_single(cpu,
- kvm_arch_check_processor_compat,
- &r, 1);
- if (r < 0)
- goto out_free_1;
- }
+
+ r = kvm_arch_check_processor_compat(opaque);
+ if (r < 0)
+ goto out_free_1;
>
> Which brings me to the next issue: You forgot to CC kvm@vger on your
> patch set. Gleb and Paolo don't read kvm-ppc@vger. And they shouldn't
> have to. Every kvm patch that you want review on or that should get
> applied needs to be sent to kvm@vger. If you want to tag it as PPC
> specific patch, do so by CC'ing kvm-ppc@vger.
Will do in the next update
-aneesh
--
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: [RFC PATCH 09/11] kvm: simplify processor compat check
On 27.09.2013, at 12:03, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V"
Missing patch description.
> Signed-off-by: Aneesh Kumar K.V
I fail to see how this really simplifies things, but at the end of the day it's
Gleb's and Paolo's call.
Which brings me to the next issue: You forgot to CC kvm@vger on your patch set.
Gleb and Paolo don't read kvm-ppc@vger. And they shouldn't have to. Every kvm
patch that you want review on or that should get applied needs to be sent to
kvm@vger. If you want to tag it as PPC specific patch, do so by CC'ing
kvm-ppc@vger.
Alex
> ---
> arch/arm/kvm/arm.c | 4 ++--
> arch/ia64/kvm/kvm-ia64.c | 4 ++--
> arch/mips/kvm/kvm_mips.c | 6 ++
> arch/powerpc/include/asm/kvm_ppc.h | 2 +-
> arch/powerpc/kvm/44x.c | 2 +-
> arch/powerpc/kvm/book3s.c | 15 ---
> arch/powerpc/kvm/book3s_hv.c | 9 ++---
> arch/powerpc/kvm/book3s_pr.c | 5 +++--
> arch/powerpc/kvm/e500.c| 2 +-
> arch/powerpc/kvm/e500mc.c | 2 +-
> arch/powerpc/kvm/powerpc.c | 5 -
> arch/s390/kvm/kvm-s390.c | 3 ++-
> arch/x86/kvm/x86.c | 13 +++--
> include/linux/kvm_host.h | 2 +-
> virt/kvm/kvm_main.c| 14 +-
> 15 files changed, 50 insertions(+), 38 deletions(-)
>
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 9c697db..cccb121 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -109,9 +109,9 @@ void kvm_arch_hardware_unsetup(void)
> {
> }
>
> -void kvm_arch_check_processor_compat(void *rtn)
> +int kvm_arch_check_processor_compat(void *opaque)
> {
> - *(int *)rtn = 0;
> + return 0;
> }
>
> void kvm_arch_sync_events(struct kvm *kvm)
> diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
> index bdfd878..065942c 100644
> --- a/arch/ia64/kvm/kvm-ia64.c
> +++ b/arch/ia64/kvm/kvm-ia64.c
> @@ -185,9 +185,9 @@ void kvm_arch_hardware_disable(void *garbage)
> ia64_ptr_entry(0x3, slot);
> }
>
> -void kvm_arch_check_processor_compat(void *rtn)
> +int kvm_arch_check_processor_compat(void *opaque)
> {
> - *(int *)rtn = 0;
> + return 0;
> }
>
> int kvm_dev_ioctl_check_extension(long ext)
> diff --git a/arch/mips/kvm/kvm_mips.c b/arch/mips/kvm/kvm_mips.c
> index a7b0445..4512739 100644
> --- a/arch/mips/kvm/kvm_mips.c
> +++ b/arch/mips/kvm/kvm_mips.c
> @@ -97,11 +97,9 @@ void kvm_arch_hardware_unsetup(void)
> {
> }
>
> -void kvm_arch_check_processor_compat(void *rtn)
> +int kvm_arch_check_processor_compat(void *opaque)
> {
> - int *r = (int *)rtn;
> - *r = 0;
> - return;
> + return 0;
> }
>
> static void kvm_mips_init_tlbs(struct kvm *kvm)
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h
> b/arch/powerpc/include/asm/kvm_ppc.h
> index 58e732f..592501b 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -204,7 +204,7 @@ struct kvmppc_ops {
> unsigned long npages);
> int (*init_vm)(struct kvm *kvm);
> void (*destroy_vm)(struct kvm *kvm);
> - int (*check_processor_compat)(void);
> + void (*check_processor_compat)(void *r);
> int (*get_smmu_info)(struct kvm *kvm, struct kvm_ppc_smmu_info *info);
> int (*emulate_op)(struct kvm_run *run, struct kvm_vcpu *vcpu,
> unsigned int inst, int *advance);
> diff --git a/arch/powerpc/kvm/44x.c b/arch/powerpc/kvm/44x.c
> index 2f5c6b6..a1f4e60 100644
> --- a/arch/powerpc/kvm/44x.c
> +++ b/arch/powerpc/kvm/44x.c
> @@ -43,7 +43,7 @@ void kvmppc_core_vcpu_put(struct kvm_vcpu *vcpu)
> kvmppc_booke_vcpu_put(vcpu);
> }
>
> -int kvmppc_core_check_processor_compat(void)
> +int kvm_arch_check_processor_compat(void *opaque)
> {
> int r;
>
> diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
> index ca617e1..485a6ff 100644
> --- a/arch/powerpc/kvm/book3s.c
> +++ b/arch/powerpc/kvm/book3s.c
> @@ -827,9 +827,18 @@ void kvmppc_core_destroy_vm(struct kvm *kvm)
> #endif
> }
>
> -int kvmppc_core_check_processor_compat(void)
> -{
> - return kvmppc_ops->check_processor_compat();
> +int kvm_arch_check_processor_compat(void *opaque)
> +{
> + int r,cpu;
> + struct kvmppc_ops *kvm_ops = (struct kvmppc_ops *)opaque;
> + for_each_online_cpu(cpu) {
> + smp_call_function_single(cpu,
> + kvm_ops->check_processor_compat,
> + &r, 1);
> + if (r < 0)
> + break;
> + }
> + return r;
> }
>
> EXPORT_SYMBOL_GPL(kvm_get_dirty_log);
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index ff57be8..4322db4 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -1980,11 +1980,14 @@ static int kvmppc_core_emulate_mfspr_hv(struct
> kvm_vcpu *vcpu, int sprn,
> return EMULATE_FAIL;
> }
>
> -sta
答复: [Qemu-devel] Cross-Platform KVM
I'm sorry for replying this mail for so long.
I named the 'Cross-Platform KVM' fvm ('f'is the beginning of my name
:)).
The kernel module is based on kvm-kmod 3.4, and the qemu (version 1.1~1.6) can
be patched easily for fvm.
I named the kernel module vmmr0 (VMM in Ring0).
Not like the 'WinKVM' by Kazushi Takahashi, fvm is easy to compile and use. The
build environment for windows is mingw-w64.
I will sum up the internals of fvm, and release the docs and codes on github
later.
The code of vmmr0 is disordered, so I will reorganize it before releasing.
Before this, I commited a binary package for windows on github:
https://github.com/fanwenyi0529/fvm-release
to use the fvm for windows, we should follow these steps:
you should have a computer which installed 64-bit windows 7 or higher.
1. enable 'Lock pages in memory' of current user in gpedit.msc:
http://msdn.microsoft.com/en-us/library/ms190730.aspx
fvm use awe memory in order to lock guest 's page. Windows kernel do
not have anything like mmu_notifier:(
2.windows x64 needs driver signing, so enable testmode.
bcdedit -set testsigning on
3.reboot your computer.
4.install the vmmr0.sys kernel module as service named 'vmmr0' and start it.
execute in cmd:
sc create vmmr0 binpath="(path to vmmr0.sys)" type=kernel start=demand
net start vmmr0
5. all done! Let 's run kvm on windows.
eg:
create a bat file , and type this in the target blank:
(path to fvm-x86_64w.exe) -drive
file=D:\vm\linux-0.2.img,cache=writeback -machine accel=kvm,kernel_irqchip=off
-cpu qemu64,-vmx -smp sockets=1,cores=1 -m 128 -soundhw hda -net
nic,model=e1000 -net user -rtc base=localtime -vga vmware
Save and run this bat as admin.
Known problems:
1. I have not implement the kernel_irqchip, so please disable the kirqchip
support in cmdline like this:
-machine accel=kvm,kernel_irqchip=off
2. the performance of windows x64 guests is pr, I have not found the reason.
3. do not use vmware vga card if the guest is Ubuntu 12.04, or the qemu
(version 1.3 )would core, qemu-1.6 is okay.
4. The mouse auto switching while running linux guests (Ubuntu, etc.) can not
work. And the qemu will lost response. Please use vnc to run Ubuntu.
5. If your cpu do not support ept, please give the guest only 1vcpu if the
guest is 64 bit. Or the guest will corrupt.
Regards,
Wincy
-邮件原件-
发件人: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] 代表 Andreas
F?rber
发送时间: 2013年8月22日 星期四 2:49
收件人: Wincy Van; Wincy Van
抄送: qemu-de...@nongnu.org; kvm; Stefan Weil; qemu-de...@nongnu.org; kvm; Stefan
Weil
主题: Re: [Qemu-devel] Cross-Platform KVM
Hi,
Am 16.08.2013 09:41, schrieb Wincy Van:
> Hi,there:
>
>I have implemented a version of cross-platform KVM. Now, it can
> works on Linux and Windows(kernel version 7600-9200, amd64). Is it
> useful? If so, I want make it as a branch of current KVM. Here are
> some
> screenshots:
Let's CC the KVM mailing list.
More telling than screenshots would be some info about your code! Is there a
public Git repository to look at? Is it based on a current kvm.git or some
older Win32 KVM fork on SourceForge? If so, how invasive are your changes? Or
is it a clean-room implementation of your own against the header/ioctl
interface? How does it work technically? etc.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
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
--
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: Guest memory access within hypervisor Inbox x
Thanks. On Fri, Sep 27, 2013 at 3:40 PM, Stefan Hajnoczi wrote: > On Fri, Sep 27, 2013 at 03:19:28AM +0530, Piyus Kedia wrote: >> I am working on record replay in KVM. I just want to confirm that KVM >> doesn't access guest memory except for DMA. The functions >> kvm_read_guest_page() and kvm_write_guest_page() in kvm_main.c are >> only used for mmio emulation which access memory that is always >> emulated. It will be nice if somebody else also confirm this. > > kvmclock comes to mind, I think it has a shared page between the guest > and the host kernel where clock updates are published from host -> > guest. I think kvmclock can be disabled by choosing another clocksource > in the guest Linux kernel. > > There are other exceptions like the ivshmem device which is rarely used > but can provide shared memory between guest <-> host or guest <-> guest. > I think that memory is an MMIO PCI BAR in the guest just that neither > kvm.ko nor QEMU may be catch the update if another process on the host > is writing to it. > > Stefan -- 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: Guest memory access within hypervisor Inbox x
On Fri, Sep 27, 2013 at 03:19:28AM +0530, Piyus Kedia wrote: > I am working on record replay in KVM. I just want to confirm that KVM > doesn't access guest memory except for DMA. The functions > kvm_read_guest_page() and kvm_write_guest_page() in kvm_main.c are > only used for mmio emulation which access memory that is always > emulated. It will be nice if somebody else also confirm this. kvmclock comes to mind, I think it has a shared page between the guest and the host kernel where clock updates are published from host -> guest. I think kvmclock can be disabled by choosing another clocksource in the guest Linux kernel. There are other exceptions like the ivshmem device which is rarely used but can provide shared memory between guest <-> host or guest <-> guest. I think that memory is an MMIO PCI BAR in the guest just that neither kvm.ko nor QEMU may be catch the update if another process on the host is writing to it. Stefan -- 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: KVM call for agenda for 2013-10-01
On 24/09/2013 16:09, Juan Quintela wrote: Hi Please, send any topic that you are interested in covering. Last week I forgot to send the call for topics. We still have a topic there. Thanks, Juan. Agenda so far: - Talk about qemu reverse executing (1st description was done this week) How to handle IO when we want to do reverse execution. How this relate to Kemari needs? And to icount changes? Hi Juan, Just to confirm, both Mark and I will be present. Thanks, Fred Call details: 10:00 AM to 11:00 AM EDT Every two weeks If you need phone number details, contact me privately. -- 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 -- 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
