Re: [PATCH net-next] vhost: remove unnecessary forward declarations in vhost.h
From: Jason Wang Date: Thu, 27 Nov 2014 14:41:21 +0800 > Signed-off-by: Jason Wang I don't think generic vhost patches should go via my tree. If you disagree, let me know why, thanks :) -- 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] kvm: arm: vgic: Let one looping code instead of two looping code
Use one looping instead of two, so can let code more simpler and get a
little better performance.
Signed-off-by: Chen Gang
---
virt/kvm/arm/vgic.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index cf23c13..eb1a51b 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -1959,9 +1959,6 @@ int kvm_vgic_create(struct kvm *kvm)
if (!mutex_trylock(&vcpu->mutex))
goto out_unlock;
vcpu_lock_idx = i;
- }
-
- kvm_for_each_vcpu(i, vcpu, kvm) {
if (vcpu->arch.has_run_once)
goto out_unlock;
}
--
1.9.3
--
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 v2] virt: kvm: arm: vgic: Process the failure case when kvm_register_device_ops() fails
Hello maintainers: Is this discussion OK? If necessary, I shall send patch v3 according to your taste. Thanks. On 11/15/14 00:30, Chen Gang wrote: > > According to your taste, we need improve 2 contents below: > > On 11/14/2014 11:55 PM, Marc Zyngier wrote: >> >> No. This is completely overdesigned, and fixes something that really >> cannot happen. What is wrong with: >> >> diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c >> index 3aaca49..b7dffa80 100644 >> --- a/virt/kvm/arm/vgic.c >> +++ b/virt/kvm/arm/vgic.c >> @@ -2465,13 +2465,17 @@ int kvm_vgic_hyp_init(void) >> goto out_free_irq; >> } >> >> +ret = kvm_register_device_ops(&kvm_arm_vgic_v2_ops, >> + KVM_DEV_TYPE_ARM_VGIC_V2); >> +if (ret) >> +goto out_free_irq; >> + > > Need call __unregister_cpu_notifier(), since __register_cpu_notifier() > is already successfully called. > > Need print some information for failure via kvm_err(). > > Thanks. >> /* Callback into for arch code for setup */ >> vgic_arch_setup(vgic); >> >> on_each_cpu(vgic_init_maintenance_interrupt, NULL, 1); >> >> -return kvm_register_device_ops(&kvm_arm_vgic_v2_ops, >> - KVM_DEV_TYPE_ARM_VGIC_V2); >> +return 0; >> >> out_free_irq: >> free_percpu_irq(vgic->maint_irq, kvm_get_running_vcpus()); >> >> This achieves the exact same effect. >> >> Thanks, >> >> M. >> > > -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- 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
SVM nested virtualisation & lots of warnings
Greetings. I'm using KVM with a number of VMs, and quite succesfully. Thanks for the great code :) I've just started using an appliance ( IBM's Netezza 7.2 emulator ), and this launches a KVM-based VM on startup. Everything appears to be working ( though not particularly quickly ), and I get a LOT of warnings on the main VM's console: handle_exit: unexpected exit_ini_info 0x803a exit_code 0x60 handle_exit: unexpected exit_ini_info 0x80ef exit_code 0x60 handle_exit: unexpected exit_ini_info 0x80fd exit_code 0x60 ... etc Around the same time, my KVM host logged this: [146758.885232] kvm [2572]: vcpu0 unhandled rdmsr: 0xc0010112 Is this something to worry about? I have a quad-core AMD: processor : 0 vendor_id : AuthenticAMD cpu family : 21 model : 16 model name : AMD A8-5600K APU with Radeon(tm) HD Graphics stepping: 1 microcode : 0x6001119 cpu MHz : 2400.000 cache size : 2048 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 2 apicid : 16 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bmi1 bugs: fxsave_leak bogomips: 7186.51 TLB size: 1536 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro ... and I've used virt-manager to set up the VM, clicking 'Copy host CPU configuration' in the 'Processor' tab. Thanks :) Dan -- 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] [mm] trivial fixes to long lines and typo in comment
On Sat, 29 Nov 2014, Mel Gorman wrote: > > Well, the subject line says it all. > > > > Why bother? > > It adds almost nothing (one meaningful change) and git blame would no > longer points to the commit that actually modified that introduced or last > updated those comments. Agreed. I am usually taking typo fixes through trivial.git, as they might potentially help someone who is grepping around the sources and hoping to actually find something :) But just reformatting long lines in comments is just not worth it at all. -- Jiri Kosina SUSE Labs -- 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: [GIT PULL 09/11] KVM: s390: add bitmap for handling cpu-local interrupts
Am 28.11.2014 um 18:18 schrieb Paolo Bonzini:
>
>
> On 28/11/2014 14:25, Christian Borntraeger wrote:
>>
>> +struct kvm_s390_irq_payload {
>> +struct kvm_s390_io_info io;
>> +struct kvm_s390_ext_info ext;
>> +struct kvm_s390_pgm_info pgm;
>> +struct kvm_s390_emerg_info emerg;
>> +struct kvm_s390_extcall_info extcall;
>> +struct kvm_s390_prefix_info prefix;
>> +struct kvm_s390_mchk_info mchk;
>> +};
>> +
>
> struct or union?
struct. This is used for keeping the payload of the interrupts. Multiple
different interrupts can be pending and most of them have payload - we want to
keep everything.
Now, looking at that code again, as I/O is floating and emergency is also
handled via a separate bitmap we could get rid of these two in a follow-up
patch. Jens, can you have a look and prepare a followup-cleanup if appropriate?
Christian
--
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 2/7] KVM: arm: guest debug, define API headers
On Wed, Nov 26, 2014 at 03:04:10PM +, Alex Bennée wrote: > > Peter Maydell writes: > > > On 25 November 2014 at 16:10, Alex Bennée wrote: > >> +/* Exit types which define why we did a debug exit */ > >> +#define KVM_DEBUG_EXIT_ERROR 0x0 > >> +#define KVM_DEBUG_EXIT_SINGLE_STEP 0x1 > >> +#define KVM_DEBUG_EXIT_SW_BKPT 0x2 > >> +#define KVM_DEBUG_EXIT_HW_BKPT 0x3 > >> +#define KVM_DEBUG_EXIT_HW_WTPT 0x4 > > > > The names of these imply that they're generic, but they're > > defined in an arch-specific header file... > > Yeah, I think these will die and I'll just export the syndrome > information directly to QEMU. huh? -Christoffer -- 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 2/7] KVM: arm: guest debug, define API headers
On Tue, Nov 25, 2014 at 04:10:00PM +, Alex Bennée wrote:
> This commit defines the API headers for guest debugging. There are two
> architecture specific debug structures:
>
> - kvm_guest_debug_arch, allows us to pass in HW debug registers
> - kvm_debug_exit_arch, signals the exact debug exit and address
>
> The type of debugging being used is control by the architecture specific
s/control/controlled/ ?
> control bits of the kvm_guest_debug->control flags in the ioctl
> structure.
>
> Signed-off-by: Alex Bennée
>
> diff --git a/arch/arm64/include/uapi/asm/kvm.h
> b/arch/arm64/include/uapi/asm/kvm.h
> index 8e38878..de2450c 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -93,10 +93,30 @@ struct kvm_sregs {
> struct kvm_fpu {
> };
>
> +/* See ARM ARM D7.3: Debug Registers
/* needs to go on a separate line.
> + *
> + * The control registers are stored as 64bit values as the setup code
> + * is shared with the normal cpu context restore code in hyp.S which
> + * is 64 bit only.
is this comment here because the architecture defines them as 32-bits?
If so, adding that would make this comment make more sense.
> + */
> +#define KVM_ARM_NDBG_REGS 16
> struct kvm_guest_debug_arch {
> + __u64 dbg_bcr[KVM_ARM_NDBG_REGS];
> + __u64 dbg_bvr[KVM_ARM_NDBG_REGS];
> + __u64 dbg_wcr[KVM_ARM_NDBG_REGS];
> + __u64 dbg_wvr[KVM_ARM_NDBG_REGS];
> };
>
> +/* Exit types which define why we did a debug exit */
> +#define KVM_DEBUG_EXIT_ERROR 0x0
> +#define KVM_DEBUG_EXIT_SINGLE_STEP 0x1
> +#define KVM_DEBUG_EXIT_SW_BKPT 0x2
> +#define KVM_DEBUG_EXIT_HW_BKPT 0x3
> +#define KVM_DEBUG_EXIT_HW_WTPT 0x4
> +
> struct kvm_debug_exit_arch {
> + __u64 address;
> + __u32 exit_type;
> };
>
> struct kvm_sync_regs {
> @@ -198,4 +218,12 @@ struct kvm_arch_memory_slot {
>
> #endif
>
> +/* Architecture related debug defines - upper 16 bits of
same not with commenting style here
> + * kvm_guest_debug->control
> + */
> +#define KVM_GUESTDBG_USE_SW_BP_SHIFT 16
> +#define KVM_GUESTDBG_USE_SW_BP (1 <<
> KVM_GUESTDBG_USE_SW_BP_SHIFT)
> +#define KVM_GUESTDBG_USE_HW_BP_SHIFT 17
> +#define KVM_GUESTDBG_USE_HW_BP (1 <<
> KVM_GUESTDBG_USE_HW_BP_SHIFT)
> +
> #endif /* __ARM_KVM_H__ */
> --
> 2.1.3
>
--
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/7] KVM: arm: guest debug, add stub KVM_SET_GUEST_DEBUG ioctl
On Tue, Nov 25, 2014 at 04:10:01PM +, Alex Bennée wrote:
> This commit adds a stub function to support the KVM_SET_GUEST_DEBUG
> ioctl. Currently any operation flag will return EINVAL. Actual
> functionality will be added with further patches.
>
> Signed-off-by: Alex Bennée .
>
> diff --git a/Documentation/virtual/kvm/api.txt
> b/Documentation/virtual/kvm/api.txt
> index 7610eaa..2c6386e 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -2570,7 +2570,7 @@ handled.
> 4.87 KVM_SET_GUEST_DEBUG
>
> Capability: KVM_CAP_SET_GUEST_DEBUG
> -Architectures: x86, s390, ppc
> +Architectures: x86, s390, ppc, arm64
> Type: vcpu ioctl
> Parameters: struct kvm_guest_debug (in)
> Returns: 0 on success; -1 on error
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 9e193c8..a0ff410 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -180,6 +180,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long
> ext)
> case KVM_CAP_ARM_PSCI:
> case KVM_CAP_ARM_PSCI_0_2:
> case KVM_CAP_READONLY_MEM:
> + case KVM_CAP_SET_GUEST_DEBUG:
Don't we usually wait with introducing visibility to user space until
you actually do support the ioctl?
> r = 1;
> break;
> case KVM_CAP_COALESCED_MMIO:
> @@ -302,7 +303,34 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
> int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
> struct kvm_guest_debug *dbg)
> {
> - return -EINVAL;
> + /* If it's not enabled clear all flags */
> + if (!(dbg->control & KVM_GUESTDBG_ENABLE)) {
> + vcpu->guest_debug = 0;
> + return 0;
> + }
> +
> + vcpu->guest_debug = dbg->control;
> + kvm_info("%s: guest_debug is 0x%lx\n", __func__, vcpu->guest_debug);
> +
> + /* Single Step */
> + if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) {
> + kvm_info("SS requested, not yet implemented\n");
> + return -EINVAL;
> + }
> +
> + /* Software Break Points */
> + if (vcpu->guest_debug & KVM_GUESTDBG_USE_SW_BP) {
> + kvm_info("SW BP support requested, not yet implemented\n");
> + return -EINVAL;
> + }
> +
> + /* Hardware assisted Break and Watch points */
> + if (vcpu->guest_debug & KVM_GUESTDBG_USE_HW_BP) {
> + kvm_info("HW BP support requested, not yet implemented\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> }
>
>
> --
> 2.1.3
>
--
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 4/7] KVM: arm64: guest debug, add SW break point support
On Tue, Nov 25, 2014 at 04:10:02PM +, Alex Bennée wrote:
> This adds support for SW breakpoints inserted by userspace.
>
> First we need to trap all BKPT exceptions in the hypervisor (ELS). This
> in controlled through the MDCR_EL2 register. I've added a new field to
this is ?
> the vcpu structure to hold this value. There should be scope to
> rationlise this with the VCPU_DEBUG_FLAGS/KVM_ARM64_DEBUG_DIRTY_SHIFT
> manipulation in later patches.
I don't understand what you mean with rationalising something in later
patches.
>
> Once the exception arrives we triggers an exit from the main hypervisor
> loop to the hypervisor controller. The kvm_debug_exit_arch carries the
hypervisor controller is userspace?
> address of the exception. If the controller doesn't know of breakpoint
the breakint ?
> then we have a guest inserted breakpoint and the hypervisor needs to
> start again and deliver the exception to guest.
to the guest
>
> Signed-off-by: Alex Bennée
>
> diff --git a/Documentation/virtual/kvm/api.txt
> b/Documentation/virtual/kvm/api.txt
> index 2c6386e..9383359 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -2592,7 +2592,7 @@ when running. Common control bits are:
> The top 16 bits of the control field are architecture specific control
> flags which can include the following:
>
> - - KVM_GUESTDBG_USE_SW_BP: using software breakpoints [x86]
> + - KVM_GUESTDBG_USE_SW_BP: using software breakpoints [x86, arm64]
>- KVM_GUESTDBG_USE_HW_BP: using hardware breakpoints [x86, s390]
>- KVM_GUESTDBG_INJECT_DB: inject DB type exception [x86]
>- KVM_GUESTDBG_INJECT_BP: inject BP type exception [x86]
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index a0ff410..48d26bb 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -303,6 +303,9 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
> int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
> struct kvm_guest_debug *dbg)
> {
> + /* Route debug traps to el2? */
> + bool route_el2 = false;
> +
> /* If it's not enabled clear all flags */
> if (!(dbg->control & KVM_GUESTDBG_ENABLE)) {
> vcpu->guest_debug = 0;
> @@ -320,8 +323,8 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu
> *vcpu,
>
> /* Software Break Points */
> if (vcpu->guest_debug & KVM_GUESTDBG_USE_SW_BP) {
> - kvm_info("SW BP support requested, not yet implemented\n");
> - return -EINVAL;
> + kvm_info("SW BP support requested\n");
> + route_el2 = true;
> }
>
> /* Hardware assisted Break and Watch points */
> @@ -330,6 +333,20 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu
> *vcpu,
> return -EINVAL;
> }
>
> + /* If we are going to handle any debug exceptions we need to
wings on the comments
> + * set MDCE_EL2.TDE to ensure they are routed to the
> + * hypervisor. If userspace determines the exception was
> + * actually internal to the guest it needs to handle
> + * re-injecting the exception.
> + */
> + if (route_el2) {
> + kvm_info("routing debug exceptions");
> + vcpu->arch.mdcr_el2 = MDCR_EL2_TDE;
> + } else {
> + kvm_info("not routing debug exceptions");
> + vcpu->arch.mdcr_el2 = 0;
> + }
> +
> return 0;
> }
>
> diff --git a/arch/arm64/include/asm/kvm_host.h
> b/arch/arm64/include/asm/kvm_host.h
> index 2012c4b..38b0f07 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -98,6 +98,7 @@ struct kvm_vcpu_arch {
>
> /* HYP configuration */
> u64 hcr_el2;
> + u32 mdcr_el2;
>
> /* Exception Information */
> struct kvm_vcpu_fault_info fault;
> diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
> index 9a9fce0..8da1043 100644
> --- a/arch/arm64/kernel/asm-offsets.c
> +++ b/arch/arm64/kernel/asm-offsets.c
> @@ -122,6 +122,7 @@ int main(void)
>DEFINE(VCPU_HPFAR_EL2, offsetof(struct kvm_vcpu,
> arch.fault.hpfar_el2));
>DEFINE(VCPU_DEBUG_FLAGS, offsetof(struct kvm_vcpu, arch.debug_flags));
>DEFINE(VCPU_HCR_EL2, offsetof(struct kvm_vcpu,
> arch.hcr_el2));
> + DEFINE(VCPU_MDCR_EL2, offsetof(struct kvm_vcpu, arch.mdcr_el2));
>DEFINE(VCPU_IRQ_LINES, offsetof(struct kvm_vcpu, arch.irq_lines));
>DEFINE(VCPU_HOST_CONTEXT, offsetof(struct kvm_vcpu,
> arch.host_cpu_context));
>DEFINE(VCPU_TIMER_CNTV_CTL,offsetof(struct kvm_vcpu,
> arch.timer_cpu.cntv_ctl));
> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> index 34b8bd0..28dc92b 100644
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@ -71,6 +71,26 @@ static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct
> kvm_run *run)
>
Re: [PATCH 4/7] KVM: arm64: guest debug, add SW break point support
On Wed, Nov 26, 2014 at 05:07:20PM +0100, Andrew Jones wrote: > On Tue, Nov 25, 2014 at 04:10:02PM +, Alex Bennée wrote: > > This adds support for SW breakpoints inserted by userspace. > > > > First we need to trap all BKPT exceptions in the hypervisor (ELS). This > > in controlled through the MDCR_EL2 register. I've added a new field to > > the vcpu structure to hold this value. There should be scope to > > rationlise this with the VCPU_DEBUG_FLAGS/KVM_ARM64_DEBUG_DIRTY_SHIFT > > manipulation in later patches. > > I think we should start using the new mdcr_el2 field everywhere we plan > to within the same series that it is introduced. Otherwise it's hard > to tell if we need an mdcr_el2 field, or if a more generic field would > suffice. We can always translate bits of a more generic field to > mdcr_el2 bits when necessary, but not the reverse. > Agreed, this is getting messy already with this patch. -Christoffer -- 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] [mm] trivial fixes to long lines and typo in comment
On Sat, Nov 29, 2014 at 10:46:59AM -0500, Zhihui Zhang wrote: > Well, the subject line says it all. > Why bother? It adds almost nothing (one meaningful change) and git blame would no longer points to the commit that actually modified that introduced or last updated those comments. -- Mel Gorman SUSE Labs -- 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] [mm] trivial fixes to long lines and typo in comment
Well, the subject line says it all. Signed-off-by: Zhihui Zhang --- include/linux/mmzone.h | 16 +++- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h index ffe66e3..cb668b7 100644 --- a/include/linux/mmzone.h +++ b/include/linux/mmzone.h @@ -966,7 +966,9 @@ static inline int zonelist_node_idx(struct zoneref *zoneref) } /** - * next_zones_zonelist - Returns the next zone at or below highest_zoneidx within the allowed nodemask using a cursor within a zonelist as a starting point + * next_zones_zonelist - Returns the next zone at or below highest_zoneidx + * within the allowed nodemask using a cursor within + * a zonelist as a starting point * @z - The cursor used as a starting point for the search * @highest_zoneidx - The zone index of the highest zone to return * @nodes - An optional nodemask to filter the zonelist with @@ -984,7 +986,8 @@ struct zoneref *next_zones_zonelist(struct zoneref *z, struct zone **zone); /** - * first_zones_zonelist - Returns the first zone at or below highest_zoneidx within the allowed nodemask in a zonelist + * first_zones_zonelist - Returns the first zone at or below highest_zoneidx + *within the allowed nodemask in a zonelist * @zonelist - The zonelist to search for a suitable zone * @highest_zoneidx - The zone index of the highest zone to return * @nodes - An optional nodemask to filter the zonelist with @@ -1005,7 +1008,9 @@ static inline struct zoneref *first_zones_zonelist(struct zonelist *zonelist, } /** - * for_each_zone_zonelist_nodemask - helper macro to iterate over valid zones in a zonelist at or below a given zone index and within a nodemask + * for_each_zone_zonelist_nodemask - helper macro to iterate over valid zones + * in a zonelist at or below a given zone + * index and within a nodemask * @zone - The current zone in the iterator * @z - The current pointer within zonelist->zones being iterated * @zlist - The zonelist being iterated @@ -1021,7 +1026,8 @@ static inline struct zoneref *first_zones_zonelist(struct zonelist *zonelist, z = next_zones_zonelist(++z, highidx, nodemask, &zone)) \ /** - * for_each_zone_zonelist - helper macro to iterate over valid zones in a zonelist at or below a given zone index + * for_each_zone_zonelist - helper macro to iterate over valid zones in a + * zonelist at or below a given zone index * @zone - The current zone in the iterator * @z - The current pointer within zonelist->zones being iterated * @zlist - The zonelist being iterated @@ -1138,7 +1144,7 @@ extern unsigned long usemap_size(void); /* * We use the lower bits of the mem_map pointer to store * a little bit of information. There should be at least - * 3 bits here due to 32-bit alignment. + * 2 bits here due to 32-bit alignment. */ #defineSECTION_MARKED_PRESENT (1UL<<0) #define SECTION_HAS_MEM_MAP(1UL<<1) -- 1.9.1 -- 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] kvm: x86: vmx: add checks on guest RIP
Signed-off-by: Eugene Korenevsky
---
Notes:
This patch adds checks on Guest RIP specified in Intel Software Developer
Manual.
The following checks are performed on processors that support Intel 64
architecture:
- Bits 63:32 must be 0 if the "IA-32e mode guest" VM-entry control is 0 or
if
the L bit (bit 13) in the access-rights field for CS is 0.
- If the processor supports N < 64 linear-address bits, bits 63:N must be
identical
if the "IA-32e mode guest" VM-entry control is 1 and the L bit in the
access-rights
field for CS is 1. (No check applies if the processor supports 64
linear-address
bits.)
arch/x86/kvm/vmx.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 6a951d8..e2da83b 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3828,6 +3828,28 @@ static bool cs_ss_rpl_check(struct kvm_vcpu *vcpu)
(ss.selector & SELECTOR_RPL_MASK));
}
+#ifdef CONFIG_X86_64
+static bool rip_valid(struct kvm_vcpu *vcpu)
+{
+ unsigned long rip;
+ struct kvm_segment cs;
+ bool longmode;
+
+ /* RIP must be canonical in long mode
+* Bits 63:32 of RIP must be zero in other processor modes */
+ longmode = false;
+ if (vm_entry_controls_get(to_vmx(vcpu)) & VM_ENTRY_IA32E_MODE) {
+ vmx_get_segment(vcpu, &cs, VCPU_SREG_CS);
+ longmode = (cs.l != 0);
+ }
+ rip = kvm_register_read(vcpu, VCPU_REGS_RIP);
+ if (longmode)
+ return !is_noncanonical_address(rip);
+ else
+ return (rip >> 32) == 0;
+}
+#endif
+
/*
* Check if guest state is valid. Returns true if valid, false if
* not.
@@ -3873,8 +3895,11 @@ static bool guest_state_valid(struct kvm_vcpu *vcpu)
if (!ldtr_valid(vcpu))
return false;
}
+#ifdef CONFIG_X86_64
+ if (!rip_valid(vcpu))
+ return false;
+#endif
/* TODO:
-* - Add checks on RIP
* - Add checks on RFLAGS
*/
--
2.0.4
--
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 4/5] ARM: enable linking against eventfd and irqchip
On Sat, Nov 29, 2014 at 03:49:37PM +0200, Nikolay Nikolaev wrote: > On Sat, Nov 29, 2014 at 9:18 AM, Shannon Zhao > wrote: > > > > On 2014/11/25 5:27, Nikolay Nikolaev wrote: > > > This enables compilation of the eventfd feature on ARM. > > > > > > > Only enable on ARM? I think we should enable it on ARM64 as well because > > the eventfd featrue is common for ARM32 and ARM64. > > If course - thanks for pointing this out. > Please remember testing if this breaks anything on arm64 :) -Christoffer -- 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 3/5] KVM: ARM VGIC add kvm_io_bus_ frontend
On Sat, Nov 29, 2014 at 9:14 AM, Shannon Zhao wrote:
> On 2014/11/25 5:26, Nikolay Nikolaev wrote:
>> In io_mem_abort remove the call to vgic_handle_mmio. The target is to have
>> a single MMIO handling path - that is through the kvm_io_bus_ API.
>>
>> Register a kvm_io_device in kvm_vgic_init on the whole vGIC MMIO region.
>> Both read and write calls are redirected to vgic_io_dev_access where
>> kvm_exit_mmio is composed to pass it to vm_ops.handle_mmio.
>>
>>
>> Signed-off-by: Nikolay Nikolaev
>> ---
>> arch/arm/kvm/mmio.c|3 --
>> include/kvm/arm_vgic.h |3 +-
>> virt/kvm/arm/vgic.c| 88
>>
>> 3 files changed, 74 insertions(+), 20 deletions(-)
>>
>> diff --git a/arch/arm/kvm/mmio.c b/arch/arm/kvm/mmio.c
>> index 81230da..1c44a2b 100644
>> --- a/arch/arm/kvm/mmio.c
>> +++ b/arch/arm/kvm/mmio.c
>> @@ -227,9 +227,6 @@ int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run
>> *run,
>> if (mmio.is_write)
>> mmio_write_buf(mmio.data, mmio.len, data);
>>
>> - if (vgic_handle_mmio(vcpu, run, &mmio))
>> - return 1;
>> -
>> if (handle_kernel_mmio(vcpu, run, &mmio))
>> return 1;
>>
>> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
>> index e452ef7..d9b7d2a 100644
>> --- a/include/kvm/arm_vgic.h
>> +++ b/include/kvm/arm_vgic.h
>> @@ -233,6 +233,7 @@ struct vgic_dist {
>> unsigned long *irq_pending_on_cpu;
>>
>> struct vgic_vm_ops vm_ops;
>> + struct kvm_io_device*io_dev;
>> #endif
>> };
>>
>> @@ -307,8 +308,6 @@ int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid,
>> unsigned int irq_num,
>> bool level);
>> void vgic_v3_dispatch_sgi(struct kvm_vcpu *vcpu, u64 reg);
>> int kvm_vgic_vcpu_pending_irq(struct kvm_vcpu *vcpu);
>> -bool vgic_handle_mmio(struct kvm_vcpu *vcpu, struct kvm_run *run,
>> - struct kvm_exit_mmio *mmio);
>>
>> #define irqchip_in_kernel(k) (!!((k)->arch.vgic.in_kernel))
>> #define vgic_initialized(k) ((k)->arch.vgic.ready)
>> diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
>> index 1213da5..3da1115 100644
>> --- a/virt/kvm/arm/vgic.c
>> +++ b/virt/kvm/arm/vgic.c
>> @@ -31,6 +31,9 @@
>> #include
>> #include
>> #include
>> +#include
>> +
>> +#include "iodev.h"
>>
>> /*
>> * How the whole thing works (courtesy of Christoffer Dall):
>> @@ -775,28 +778,81 @@ bool vgic_handle_mmio_range(struct kvm_vcpu *vcpu,
>> struct kvm_run *run,
>> return true;
>> }
>>
>> -/**
>> - * vgic_handle_mmio - handle an in-kernel MMIO access for the GIC emulation
>> - * @vcpu: pointer to the vcpu performing the access
>> - * @run: pointer to the kvm_run structure
>> - * @mmio: pointer to the data describing the access
>> - *
>> - * returns true if the MMIO access has been performed in kernel space,
>> - * and false if it needs to be emulated in user space.
>> - * Calls the actual handling routine for the selected VGIC model.
>> - */
>> -bool vgic_handle_mmio(struct kvm_vcpu *vcpu, struct kvm_run *run,
>> - struct kvm_exit_mmio *mmio)
>> +static int vgic_io_dev_access(struct kvm_vcpu *vcpu, struct kvm_io_device
>> *this,
>> + gpa_t addr, int len, void *val, bool is_write)
>> {
>> - if (!irqchip_in_kernel(vcpu->kvm))
>> - return false;
>> + struct kvm_exit_mmio mmio;
>> + bool ret;
>> +
>> + mmio = (struct kvm_exit_mmio) {
>> + .phys_addr = addr,
>> + .len = len,
>> + .is_write = is_write,
>> + };
>> +
>> + if (is_write)
>> + memcpy(mmio.data, val, len);
>>
>> /*
>>* This will currently call either vgic_v2_handle_mmio() or
>>* vgic_v3_handle_mmio(), which in turn will call
>>* vgic_handle_mmio_range() defined above.
>>*/
>> - return vcpu->kvm->arch.vgic.vm_ops.handle_mmio(vcpu, run, mmio);
>> + ret = vcpu->kvm->arch.vgic.vm_ops.handle_mmio(vcpu, vcpu->run, &mmio);
>> +
>> + if (!is_write)
>> + memcpy(val, mmio.data, len);
>> +
>> + return ret ? 0 : 1;
>> +}
>> +
>> +static int vgic_io_dev_read(struct kvm_vcpu *vcpu, struct kvm_io_device
>> *this,
>> + gpa_t addr, int len, void *val)
>> +{
>> + return vgic_io_dev_access(vcpu, this, addr, len, val, false);
>> +}
>> +
>> +static int vgic_io_dev_write(struct kvm_vcpu *vcpu, struct kvm_io_device
>> *this,
>> +gpa_t addr, int len, const void *val)
>> +{
>> + return vgic_io_dev_access(vcpu, this, addr, len, (void *)val, true);
>> +}
>> +
>> +static const struct kvm_io_device_ops vgic_io_dev_ops = {
>> + .read = vgic_io_dev_read,
>> + .write = vgic_io_dev_write,
>> +};
>> +
>> +static int vgic_register_kvm_io_dev(struct kvm *kvm)
>> +{
>> + struct kvm_io_device *dev;
>> + int ret;
>> +
>> + struct vgic_dist *dist = &kvm->arch.vgic;
>> + unsign
Re: [RFC PATCH 3/5] KVM: ARM VGIC add kvm_io_bus_ frontend
On Sat, Nov 29, 2014 at 1:29 PM, Christoffer Dall
wrote:
> On Mon, Nov 24, 2014 at 11:26:58PM +0200, Nikolay Nikolaev wrote:
>> In io_mem_abort remove the call to vgic_handle_mmio. The target is to have
>> a single MMIO handling path - that is through the kvm_io_bus_ API.
>>
>> Register a kvm_io_device in kvm_vgic_init on the whole vGIC MMIO region.
>> Both read and write calls are redirected to vgic_io_dev_access where
>> kvm_exit_mmio is composed to pass it to vm_ops.handle_mmio.
>>
>>
>> Signed-off-by: Nikolay Nikolaev
>> ---
>> arch/arm/kvm/mmio.c|3 --
>> include/kvm/arm_vgic.h |3 +-
>> virt/kvm/arm/vgic.c| 88
>>
>> 3 files changed, 74 insertions(+), 20 deletions(-)
>>
>> diff --git a/arch/arm/kvm/mmio.c b/arch/arm/kvm/mmio.c
>> index 81230da..1c44a2b 100644
>> --- a/arch/arm/kvm/mmio.c
>> +++ b/arch/arm/kvm/mmio.c
>> @@ -227,9 +227,6 @@ int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run
>> *run,
>> if (mmio.is_write)
>> mmio_write_buf(mmio.data, mmio.len, data);
>>
>> - if (vgic_handle_mmio(vcpu, run, &mmio))
>> - return 1;
>> -
>> if (handle_kernel_mmio(vcpu, run, &mmio))
>> return 1;
>>
>> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
>> index e452ef7..d9b7d2a 100644
>> --- a/include/kvm/arm_vgic.h
>> +++ b/include/kvm/arm_vgic.h
>> @@ -233,6 +233,7 @@ struct vgic_dist {
>> unsigned long *irq_pending_on_cpu;
>>
>> struct vgic_vm_ops vm_ops;
>> + struct kvm_io_device*io_dev;
>> #endif
>> };
>>
>> @@ -307,8 +308,6 @@ int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid,
>> unsigned int irq_num,
>> bool level);
>> void vgic_v3_dispatch_sgi(struct kvm_vcpu *vcpu, u64 reg);
>> int kvm_vgic_vcpu_pending_irq(struct kvm_vcpu *vcpu);
>> -bool vgic_handle_mmio(struct kvm_vcpu *vcpu, struct kvm_run *run,
>> - struct kvm_exit_mmio *mmio);
>>
>> #define irqchip_in_kernel(k) (!!((k)->arch.vgic.in_kernel))
>> #define vgic_initialized(k) ((k)->arch.vgic.ready)
>> diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
>> index 1213da5..3da1115 100644
>> --- a/virt/kvm/arm/vgic.c
>> +++ b/virt/kvm/arm/vgic.c
>> @@ -31,6 +31,9 @@
>> #include
>> #include
>> #include
>> +#include
>> +
>> +#include "iodev.h"
>>
>> /*
>> * How the whole thing works (courtesy of Christoffer Dall):
>> @@ -775,28 +778,81 @@ bool vgic_handle_mmio_range(struct kvm_vcpu *vcpu,
>> struct kvm_run *run,
>> return true;
>> }
>>
>> -/**
>> - * vgic_handle_mmio - handle an in-kernel MMIO access for the GIC emulation
>> - * @vcpu: pointer to the vcpu performing the access
>> - * @run: pointer to the kvm_run structure
>> - * @mmio: pointer to the data describing the access
>> - *
>> - * returns true if the MMIO access has been performed in kernel space,
>> - * and false if it needs to be emulated in user space.
>> - * Calls the actual handling routine for the selected VGIC model.
>> - */
>> -bool vgic_handle_mmio(struct kvm_vcpu *vcpu, struct kvm_run *run,
>> - struct kvm_exit_mmio *mmio)
>> +static int vgic_io_dev_access(struct kvm_vcpu *vcpu, struct kvm_io_device
>> *this,
>> + gpa_t addr, int len, void *val, bool is_write)
>> {
>> - if (!irqchip_in_kernel(vcpu->kvm))
>> - return false;
>> + struct kvm_exit_mmio mmio;
>> + bool ret;
>> +
>> + mmio = (struct kvm_exit_mmio) {
>> + .phys_addr = addr,
>> + .len = len,
>> + .is_write = is_write,
>> + };
>> +
>> + if (is_write)
>> + memcpy(mmio.data, val, len);
>>
>> /*
>>* This will currently call either vgic_v2_handle_mmio() or
>>* vgic_v3_handle_mmio(), which in turn will call
>>* vgic_handle_mmio_range() defined above.
>>*/
>> - return vcpu->kvm->arch.vgic.vm_ops.handle_mmio(vcpu, run, mmio);
>> + ret = vcpu->kvm->arch.vgic.vm_ops.handle_mmio(vcpu, vcpu->run, &mmio);
>> +
>> + if (!is_write)
>> + memcpy(val, mmio.data, len);
>> +
>> + return ret ? 0 : 1;
>> +}
>> +
>> +static int vgic_io_dev_read(struct kvm_vcpu *vcpu, struct kvm_io_device
>> *this,
>> + gpa_t addr, int len, void *val)
>> +{
>> + return vgic_io_dev_access(vcpu, this, addr, len, val, false);
>> +}
>> +
>> +static int vgic_io_dev_write(struct kvm_vcpu *vcpu, struct kvm_io_device
>> *this,
>> +gpa_t addr, int len, const void *val)
>> +{
>> + return vgic_io_dev_access(vcpu, this, addr, len, (void *)val, true);
>> +}
>> +
>> +static const struct kvm_io_device_ops vgic_io_dev_ops = {
>> + .read = vgic_io_dev_read,
>> + .write = vgic_io_dev_write,
>> +};
>> +
>> +static int vgic_register_kvm_io_dev(struct kvm *kvm)
>> +{
>> + struct kvm_io_device *dev;
>> + int ret;
>> +
>> + struct vgic_dist *dist = &kvm->
Re: [RFC PATCH 4/5] ARM: enable linking against eventfd and irqchip
On Sat, Nov 29, 2014 at 9:18 AM, Shannon Zhao wrote: > > On 2014/11/25 5:27, Nikolay Nikolaev wrote: > > This enables compilation of the eventfd feature on ARM. > > > > Only enable on ARM? I think we should enable it on ARM64 as well because the > eventfd featrue is common for ARM32 and ARM64. If course - thanks for pointing this out. regards, Nikolay Nikolaev > > Thanks, > Shannon > > > Signed-off-by: Nikolay Nikolaev > > --- > > arch/arm/kvm/Kconfig |1 + > > arch/arm/kvm/Makefile |2 +- > > 2 files changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig > > index 466bd29..a4b0312 100644 > > --- a/arch/arm/kvm/Kconfig > > +++ b/arch/arm/kvm/Kconfig > > @@ -20,6 +20,7 @@ config KVM > > bool "Kernel-based Virtual Machine (KVM) support" > > select PREEMPT_NOTIFIERS > > select ANON_INODES > > + select HAVE_KVM_EVENTFD > > select HAVE_KVM_CPU_RELAX_INTERCEPT > > select KVM_MMIO > > select KVM_ARM_HOST > > diff --git a/arch/arm/kvm/Makefile b/arch/arm/kvm/Makefile > > index 443b8be..539c1a5 100644 > > --- a/arch/arm/kvm/Makefile > > +++ b/arch/arm/kvm/Makefile > > @@ -15,7 +15,7 @@ AFLAGS_init.o := -Wa,-march=armv7-a$(plus_virt) > > AFLAGS_interrupts.o := -Wa,-march=armv7-a$(plus_virt) > > > > KVM := ../../../virt/kvm > > -kvm-arm-y = $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o > > +kvm-arm-y = $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o > > > > obj-y += kvm-arm.o init.o interrupts.o > > obj-y += arm.o handle_exit.o guest.o mmu.o emulate.o reset.o > > > > ___ > > kvmarm mailing list > > kvm...@lists.cs.columbia.edu > > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm > > > > > -- 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 4/5] ARM: enable linking against eventfd and irqchip
Inidicate KVM in the subject please. On Mon, Nov 24, 2014 at 11:27:06PM +0200, Nikolay Nikolaev wrote: > This enables compilation of the eventfd feature on ARM. does this enable anything else than the ioeventfd stuff so that everything is in place to do this safely now? -Christoffer -- 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 3/5] KVM: ARM VGIC add kvm_io_bus_ frontend
On Mon, Nov 24, 2014 at 11:26:58PM +0200, Nikolay Nikolaev wrote:
> In io_mem_abort remove the call to vgic_handle_mmio. The target is to have
> a single MMIO handling path - that is through the kvm_io_bus_ API.
>
> Register a kvm_io_device in kvm_vgic_init on the whole vGIC MMIO region.
> Both read and write calls are redirected to vgic_io_dev_access where
> kvm_exit_mmio is composed to pass it to vm_ops.handle_mmio.
>
>
> Signed-off-by: Nikolay Nikolaev
> ---
> arch/arm/kvm/mmio.c|3 --
> include/kvm/arm_vgic.h |3 +-
> virt/kvm/arm/vgic.c| 88
>
> 3 files changed, 74 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/kvm/mmio.c b/arch/arm/kvm/mmio.c
> index 81230da..1c44a2b 100644
> --- a/arch/arm/kvm/mmio.c
> +++ b/arch/arm/kvm/mmio.c
> @@ -227,9 +227,6 @@ int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run
> *run,
> if (mmio.is_write)
> mmio_write_buf(mmio.data, mmio.len, data);
>
> - if (vgic_handle_mmio(vcpu, run, &mmio))
> - return 1;
> -
> if (handle_kernel_mmio(vcpu, run, &mmio))
> return 1;
>
> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
> index e452ef7..d9b7d2a 100644
> --- a/include/kvm/arm_vgic.h
> +++ b/include/kvm/arm_vgic.h
> @@ -233,6 +233,7 @@ struct vgic_dist {
> unsigned long *irq_pending_on_cpu;
>
> struct vgic_vm_ops vm_ops;
> + struct kvm_io_device*io_dev;
> #endif
> };
>
> @@ -307,8 +308,6 @@ int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid,
> unsigned int irq_num,
> bool level);
> void vgic_v3_dispatch_sgi(struct kvm_vcpu *vcpu, u64 reg);
> int kvm_vgic_vcpu_pending_irq(struct kvm_vcpu *vcpu);
> -bool vgic_handle_mmio(struct kvm_vcpu *vcpu, struct kvm_run *run,
> - struct kvm_exit_mmio *mmio);
>
> #define irqchip_in_kernel(k) (!!((k)->arch.vgic.in_kernel))
> #define vgic_initialized(k) ((k)->arch.vgic.ready)
> diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
> index 1213da5..3da1115 100644
> --- a/virt/kvm/arm/vgic.c
> +++ b/virt/kvm/arm/vgic.c
> @@ -31,6 +31,9 @@
> #include
> #include
> #include
> +#include
> +
> +#include "iodev.h"
>
> /*
> * How the whole thing works (courtesy of Christoffer Dall):
> @@ -775,28 +778,81 @@ bool vgic_handle_mmio_range(struct kvm_vcpu *vcpu,
> struct kvm_run *run,
> return true;
> }
>
> -/**
> - * vgic_handle_mmio - handle an in-kernel MMIO access for the GIC emulation
> - * @vcpu: pointer to the vcpu performing the access
> - * @run: pointer to the kvm_run structure
> - * @mmio: pointer to the data describing the access
> - *
> - * returns true if the MMIO access has been performed in kernel space,
> - * and false if it needs to be emulated in user space.
> - * Calls the actual handling routine for the selected VGIC model.
> - */
> -bool vgic_handle_mmio(struct kvm_vcpu *vcpu, struct kvm_run *run,
> - struct kvm_exit_mmio *mmio)
> +static int vgic_io_dev_access(struct kvm_vcpu *vcpu, struct kvm_io_device
> *this,
> + gpa_t addr, int len, void *val, bool is_write)
> {
> - if (!irqchip_in_kernel(vcpu->kvm))
> - return false;
> + struct kvm_exit_mmio mmio;
> + bool ret;
> +
> + mmio = (struct kvm_exit_mmio) {
> + .phys_addr = addr,
> + .len = len,
> + .is_write = is_write,
> + };
> +
> + if (is_write)
> + memcpy(mmio.data, val, len);
>
> /*
>* This will currently call either vgic_v2_handle_mmio() or
>* vgic_v3_handle_mmio(), which in turn will call
>* vgic_handle_mmio_range() defined above.
>*/
> - return vcpu->kvm->arch.vgic.vm_ops.handle_mmio(vcpu, run, mmio);
> + ret = vcpu->kvm->arch.vgic.vm_ops.handle_mmio(vcpu, vcpu->run, &mmio);
> +
> + if (!is_write)
> + memcpy(val, mmio.data, len);
> +
> + return ret ? 0 : 1;
> +}
> +
> +static int vgic_io_dev_read(struct kvm_vcpu *vcpu, struct kvm_io_device
> *this,
> + gpa_t addr, int len, void *val)
> +{
> + return vgic_io_dev_access(vcpu, this, addr, len, val, false);
> +}
> +
> +static int vgic_io_dev_write(struct kvm_vcpu *vcpu, struct kvm_io_device
> *this,
> +gpa_t addr, int len, const void *val)
> +{
> + return vgic_io_dev_access(vcpu, this, addr, len, (void *)val, true);
> +}
> +
> +static const struct kvm_io_device_ops vgic_io_dev_ops = {
> + .read = vgic_io_dev_read,
> + .write = vgic_io_dev_write,
> +};
> +
> +static int vgic_register_kvm_io_dev(struct kvm *kvm)
> +{
> + struct kvm_io_device *dev;
> + int ret;
> +
> + struct vgic_dist *dist = &kvm->arch.vgic;
> + unsigned long base = dist->vgic_dist_base;
> +
> + dev = kzalloc(sizeof(struct kvm_io_device), GFP_KERNEL);
> + if (!dev)
> + return -ENOMEM;
Re: [RFC PATCH 3/5] KVM: ARM VGIC add kvm_io_bus_ frontend
On Mon, Nov 24, 2014 at 11:26:58PM +0200, Nikolay Nikolaev wrote:
> In io_mem_abort remove the call to vgic_handle_mmio. The target is to have
> a single MMIO handling path - that is through the kvm_io_bus_ API.
>
> Register a kvm_io_device in kvm_vgic_init on the whole vGIC MMIO region.
> Both read and write calls are redirected to vgic_io_dev_access where
> kvm_exit_mmio is composed to pass it to vm_ops.handle_mmio.
>
>
> Signed-off-by: Nikolay Nikolaev
> ---
> arch/arm/kvm/mmio.c|3 --
> include/kvm/arm_vgic.h |3 +-
> virt/kvm/arm/vgic.c| 88
>
> 3 files changed, 74 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/kvm/mmio.c b/arch/arm/kvm/mmio.c
> index 81230da..1c44a2b 100644
> --- a/arch/arm/kvm/mmio.c
> +++ b/arch/arm/kvm/mmio.c
> @@ -227,9 +227,6 @@ int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run
> *run,
> if (mmio.is_write)
> mmio_write_buf(mmio.data, mmio.len, data);
>
> - if (vgic_handle_mmio(vcpu, run, &mmio))
> - return 1;
> -
> if (handle_kernel_mmio(vcpu, run, &mmio))
> return 1;
>
> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
> index e452ef7..d9b7d2a 100644
> --- a/include/kvm/arm_vgic.h
> +++ b/include/kvm/arm_vgic.h
> @@ -233,6 +233,7 @@ struct vgic_dist {
> unsigned long *irq_pending_on_cpu;
>
> struct vgic_vm_ops vm_ops;
> + struct kvm_io_device*io_dev;
> #endif
> };
>
> @@ -307,8 +308,6 @@ int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid,
> unsigned int irq_num,
> bool level);
> void vgic_v3_dispatch_sgi(struct kvm_vcpu *vcpu, u64 reg);
> int kvm_vgic_vcpu_pending_irq(struct kvm_vcpu *vcpu);
> -bool vgic_handle_mmio(struct kvm_vcpu *vcpu, struct kvm_run *run,
> - struct kvm_exit_mmio *mmio);
>
> #define irqchip_in_kernel(k) (!!((k)->arch.vgic.in_kernel))
> #define vgic_initialized(k) ((k)->arch.vgic.ready)
> diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
> index 1213da5..3da1115 100644
> --- a/virt/kvm/arm/vgic.c
> +++ b/virt/kvm/arm/vgic.c
> @@ -31,6 +31,9 @@
> #include
> #include
> #include
> +#include
> +
> +#include "iodev.h"
>
> /*
> * How the whole thing works (courtesy of Christoffer Dall):
> @@ -775,28 +778,81 @@ bool vgic_handle_mmio_range(struct kvm_vcpu *vcpu,
> struct kvm_run *run,
> return true;
> }
>
> -/**
> - * vgic_handle_mmio - handle an in-kernel MMIO access for the GIC emulation
> - * @vcpu: pointer to the vcpu performing the access
> - * @run: pointer to the kvm_run structure
> - * @mmio: pointer to the data describing the access
> - *
> - * returns true if the MMIO access has been performed in kernel space,
> - * and false if it needs to be emulated in user space.
> - * Calls the actual handling routine for the selected VGIC model.
> - */
> -bool vgic_handle_mmio(struct kvm_vcpu *vcpu, struct kvm_run *run,
> - struct kvm_exit_mmio *mmio)
> +static int vgic_io_dev_access(struct kvm_vcpu *vcpu, struct kvm_io_device
> *this,
> + gpa_t addr, int len, void *val, bool is_write)
> {
> - if (!irqchip_in_kernel(vcpu->kvm))
> - return false;
> + struct kvm_exit_mmio mmio;
> + bool ret;
> +
> + mmio = (struct kvm_exit_mmio) {
> + .phys_addr = addr,
> + .len = len,
> + .is_write = is_write,
> + };
> +
> + if (is_write)
> + memcpy(mmio.data, val, len);
>
> /*
>* This will currently call either vgic_v2_handle_mmio() or
>* vgic_v3_handle_mmio(), which in turn will call
>* vgic_handle_mmio_range() defined above.
>*/
> - return vcpu->kvm->arch.vgic.vm_ops.handle_mmio(vcpu, run, mmio);
> + ret = vcpu->kvm->arch.vgic.vm_ops.handle_mmio(vcpu, vcpu->run, &mmio);
> +
> + if (!is_write)
> + memcpy(val, mmio.data, len);
> +
> + return ret ? 0 : 1;
> +}
> +
> +static int vgic_io_dev_read(struct kvm_vcpu *vcpu, struct kvm_io_device
> *this,
> + gpa_t addr, int len, void *val)
> +{
> + return vgic_io_dev_access(vcpu, this, addr, len, val, false);
> +}
> +
> +static int vgic_io_dev_write(struct kvm_vcpu *vcpu, struct kvm_io_device
> *this,
> +gpa_t addr, int len, const void *val)
> +{
> + return vgic_io_dev_access(vcpu, this, addr, len, (void *)val, true);
> +}
> +
> +static const struct kvm_io_device_ops vgic_io_dev_ops = {
> + .read = vgic_io_dev_read,
> + .write = vgic_io_dev_write,
> +};
> +
> +static int vgic_register_kvm_io_dev(struct kvm *kvm)
> +{
> + struct kvm_io_device *dev;
> + int ret;
> +
> + struct vgic_dist *dist = &kvm->arch.vgic;
> + unsigned long base = dist->vgic_dist_base;
> +
> + dev = kzalloc(sizeof(struct kvm_io_device), GFP_KERNEL);
> + if (!dev)
> + return -ENOMEM;
Re: [RFC PATCH 3/5] KVM: ARM VGIC add kvm_io_bus_ frontend
On Mon, Nov 24, 2014 at 11:26:58PM +0200, Nikolay Nikolaev wrote:
> In io_mem_abort remove the call to vgic_handle_mmio. The target is to have
> a single MMIO handling path - that is through the kvm_io_bus_ API.
>
> Register a kvm_io_device in kvm_vgic_init on the whole vGIC MMIO region.
> Both read and write calls are redirected to vgic_io_dev_access where
> kvm_exit_mmio is composed to pass it to vm_ops.handle_mmio.
>
>
> Signed-off-by: Nikolay Nikolaev
> ---
> arch/arm/kvm/mmio.c|3 --
> include/kvm/arm_vgic.h |3 +-
> virt/kvm/arm/vgic.c| 88
>
> 3 files changed, 74 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/kvm/mmio.c b/arch/arm/kvm/mmio.c
> index 81230da..1c44a2b 100644
> --- a/arch/arm/kvm/mmio.c
> +++ b/arch/arm/kvm/mmio.c
> @@ -227,9 +227,6 @@ int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run
> *run,
> if (mmio.is_write)
> mmio_write_buf(mmio.data, mmio.len, data);
>
> - if (vgic_handle_mmio(vcpu, run, &mmio))
> - return 1;
> -
> if (handle_kernel_mmio(vcpu, run, &mmio))
> return 1;
>
> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
> index e452ef7..d9b7d2a 100644
> --- a/include/kvm/arm_vgic.h
> +++ b/include/kvm/arm_vgic.h
> @@ -233,6 +233,7 @@ struct vgic_dist {
> unsigned long *irq_pending_on_cpu;
>
> struct vgic_vm_ops vm_ops;
> + struct kvm_io_device*io_dev;
> #endif
> };
>
> @@ -307,8 +308,6 @@ int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid,
> unsigned int irq_num,
> bool level);
> void vgic_v3_dispatch_sgi(struct kvm_vcpu *vcpu, u64 reg);
> int kvm_vgic_vcpu_pending_irq(struct kvm_vcpu *vcpu);
> -bool vgic_handle_mmio(struct kvm_vcpu *vcpu, struct kvm_run *run,
> - struct kvm_exit_mmio *mmio);
>
> #define irqchip_in_kernel(k) (!!((k)->arch.vgic.in_kernel))
> #define vgic_initialized(k) ((k)->arch.vgic.ready)
> diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
> index 1213da5..3da1115 100644
> --- a/virt/kvm/arm/vgic.c
> +++ b/virt/kvm/arm/vgic.c
> @@ -31,6 +31,9 @@
> #include
> #include
> #include
> +#include
> +
> +#include "iodev.h"
>
> /*
> * How the whole thing works (courtesy of Christoffer Dall):
> @@ -775,28 +778,81 @@ bool vgic_handle_mmio_range(struct kvm_vcpu *vcpu,
> struct kvm_run *run,
> return true;
> }
>
> -/**
> - * vgic_handle_mmio - handle an in-kernel MMIO access for the GIC emulation
> - * @vcpu: pointer to the vcpu performing the access
> - * @run: pointer to the kvm_run structure
> - * @mmio: pointer to the data describing the access
> - *
> - * returns true if the MMIO access has been performed in kernel space,
> - * and false if it needs to be emulated in user space.
> - * Calls the actual handling routine for the selected VGIC model.
> - */
> -bool vgic_handle_mmio(struct kvm_vcpu *vcpu, struct kvm_run *run,
> - struct kvm_exit_mmio *mmio)
> +static int vgic_io_dev_access(struct kvm_vcpu *vcpu, struct kvm_io_device
> *this,
> + gpa_t addr, int len, void *val, bool is_write)
> {
> - if (!irqchip_in_kernel(vcpu->kvm))
> - return false;
> + struct kvm_exit_mmio mmio;
> + bool ret;
> +
> + mmio = (struct kvm_exit_mmio) {
> + .phys_addr = addr,
> + .len = len,
> + .is_write = is_write,
> + };
> +
> + if (is_write)
> + memcpy(mmio.data, val, len);
>
> /*
>* This will currently call either vgic_v2_handle_mmio() or
>* vgic_v3_handle_mmio(), which in turn will call
>* vgic_handle_mmio_range() defined above.
>*/
> - return vcpu->kvm->arch.vgic.vm_ops.handle_mmio(vcpu, run, mmio);
> + ret = vcpu->kvm->arch.vgic.vm_ops.handle_mmio(vcpu, vcpu->run, &mmio);
> +
> + if (!is_write)
> + memcpy(val, mmio.data, len);
> +
> + return ret ? 0 : 1;
> +}
> +
> +static int vgic_io_dev_read(struct kvm_vcpu *vcpu, struct kvm_io_device
> *this,
> + gpa_t addr, int len, void *val)
> +{
> + return vgic_io_dev_access(vcpu, this, addr, len, val, false);
> +}
> +
> +static int vgic_io_dev_write(struct kvm_vcpu *vcpu, struct kvm_io_device
> *this,
> +gpa_t addr, int len, const void *val)
> +{
> + return vgic_io_dev_access(vcpu, this, addr, len, (void *)val, true);
> +}
> +
> +static const struct kvm_io_device_ops vgic_io_dev_ops = {
> + .read = vgic_io_dev_read,
> + .write = vgic_io_dev_write,
> +};
> +
> +static int vgic_register_kvm_io_dev(struct kvm *kvm)
> +{
> + struct kvm_io_device *dev;
> + int ret;
> +
> + struct vgic_dist *dist = &kvm->arch.vgic;
> + unsigned long base = dist->vgic_dist_base;
> +
> + dev = kzalloc(sizeof(struct kvm_io_device), GFP_KERNEL);
when is this freed?
-Christoffer
--
To unsubscri
Re: [RFC PATCH 2/5] ARM: on IO mem abort - route the call to KVM MMIO bus
The subject could use a KVM: prefix.
On Mon, Nov 24, 2014 at 11:26:51PM +0200, Nikolay Nikolaev wrote:
> On IO memory abort, try to handle the MMIO access thorugh the KVM
> registered read/write callbacks. This is done by invoking the relevant
> kvm_io_bus_* API.
>
> Signed-off-by: Nikolay Nikolaev
> ---
> arch/arm/kvm/mmio.c | 33 +
> 1 file changed, 33 insertions(+)
>
> diff --git a/arch/arm/kvm/mmio.c b/arch/arm/kvm/mmio.c
> index 4cb5a93..81230da 100644
> --- a/arch/arm/kvm/mmio.c
> +++ b/arch/arm/kvm/mmio.c
> @@ -162,6 +162,36 @@ static int decode_hsr(struct kvm_vcpu *vcpu, phys_addr_t
> fault_ipa,
> return 0;
> }
>
> +/**
> + * kvm_handle_mmio - handle an in-kernel MMIO access
> + * @vcpu:pointer to the vcpu performing the access
> + * @run: pointer to the kvm_run structure
> + * @mmio:pointer to the data describing the access
> + *
> + * returns true if the MMIO access has been performed in kernel space,
> + * and false if it needs to be emulated in user space.
> + */
> +static bool handle_kernel_mmio(struct kvm_vcpu *vcpu, struct kvm_run *run,
> + struct kvm_exit_mmio *mmio)
> +{
> + int ret;
> +
> + if (mmio->is_write) {
> + ret = kvm_io_bus_write(vcpu, KVM_MMIO_BUS, mmio->phys_addr,
> + mmio->len, &mmio->data);
> +
> + } else {
> + ret = kvm_io_bus_read(vcpu, KVM_MMIO_BUS, mmio->phys_addr,
> + mmio->len, &mmio->data);
> + }
> + if (!ret) {
> + kvm_prepare_mmio(run, mmio);
> + kvm_handle_mmio_return(vcpu, run);
> + }
> +
> + return !ret;
> +}
> +
> int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run *run,
>phys_addr_t fault_ipa)
> {
> @@ -200,6 +230,9 @@ int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run
> *run,
> if (vgic_handle_mmio(vcpu, run, &mmio))
> return 1;
>
> + if (handle_kernel_mmio(vcpu, run, &mmio))
> + return 1;
> +
> kvm_prepare_mmio(run, &mmio);
> return 0;
> }
>
--
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 2/5] ARM: on IO mem abort - route the call to KVM MMIO bus
On Mon, Nov 24, 2014 at 11:26:51PM +0200, Nikolay Nikolaev wrote:
> On IO memory abort, try to handle the MMIO access thorugh the KVM
> registered read/write callbacks. This is done by invoking the relevant
> kvm_io_bus_* API.
>
> Signed-off-by: Nikolay Nikolaev
> ---
> arch/arm/kvm/mmio.c | 33 +
> 1 file changed, 33 insertions(+)
>
> diff --git a/arch/arm/kvm/mmio.c b/arch/arm/kvm/mmio.c
> index 4cb5a93..81230da 100644
> --- a/arch/arm/kvm/mmio.c
> +++ b/arch/arm/kvm/mmio.c
> @@ -162,6 +162,36 @@ static int decode_hsr(struct kvm_vcpu *vcpu, phys_addr_t
> fault_ipa,
> return 0;
> }
>
> +/**
> + * kvm_handle_mmio - handle an in-kernel MMIO access
> + * @vcpu:pointer to the vcpu performing the access
> + * @run: pointer to the kvm_run structure
> + * @mmio:pointer to the data describing the access
> + *
> + * returns true if the MMIO access has been performed in kernel space,
> + * and false if it needs to be emulated in user space.
> + */
> +static bool handle_kernel_mmio(struct kvm_vcpu *vcpu, struct kvm_run *run,
> + struct kvm_exit_mmio *mmio)
> +{
> + int ret;
> +
> + if (mmio->is_write) {
> + ret = kvm_io_bus_write(vcpu, KVM_MMIO_BUS, mmio->phys_addr,
> + mmio->len, &mmio->data);
> +
> + } else {
> + ret = kvm_io_bus_read(vcpu, KVM_MMIO_BUS, mmio->phys_addr,
> + mmio->len, &mmio->data);
> + }
> + if (!ret) {
> + kvm_prepare_mmio(run, mmio);
> + kvm_handle_mmio_return(vcpu, run);
> + }
> +
> + return !ret;
> +}
> +
> int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run *run,
>phys_addr_t fault_ipa)
> {
> @@ -200,6 +230,9 @@ int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run
> *run,
> if (vgic_handle_mmio(vcpu, run, &mmio))
> return 1;
>
> + if (handle_kernel_mmio(vcpu, run, &mmio))
> + return 1;
> +
Is this stuff always synchronously handled so that the mmio is properly
populated upon handle_kernel_mmio on reads?
-Christoffer
--
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
KVM checkpatch.pl issue
Hi there, I run $perl scripts/checkpatch.pl -f arch/x86/kvm/* $perl scripts/checkpatch.pl -f virt/kvm/*.c $perl scripts/checkpatch.pl -f virt/kvm/*.h and see lot of WARNINGs and ERRORs. Can I fix this issue? -- Eugene -- 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
