Re: [PATCH 3/4] Drivers: hv: vmbus: Add hooks for per-CPU IRQ
On Tue, Nov 27, 2018 at 07:20:56AM +0100, Greg KH wrote: > On Mon, Nov 26, 2018 at 08:56:50PM +, Michael Kelley wrote: > > From: Greg KH Monday, November 26, 2018 11:57 > > AM > > > > > > > You created "null" hooks that do nothing, for no one in this patch > > > > > series, why? > > > > > > > > > > > > > hv_enable_vmbus_irq() and hv_disable_vmbus_irq() have non-null > > > > implementations in the ARM64 code in patch 2 of this series. The > > > > implementations are in the new file arch/arm64/hyperv/mshyperv.c. > > > > Or am I misunderstanding your point? > > > > > > So you use a hook in an earlier patch and then add it in a later one? > > > > > > Shouldn't you do it the other way around? As it is, the earlier patch > > > should not work properly, right? > > > > The earlier patch implements the hook on the ARM64 side but it is > > unused -- it's not called. The later patch then calls it. Wouldn't the > > other way around be backwards? > > Ah, it wasn't obvious that the previous patch added it at all, why not > just make that addition part of this patch? > > > The general approach is for patches 1 and 2 of the series to provide > > all the new code under arch/arm64 to enable Hyper-V. But the code > > won't get called (or even built) with just these two patches because > > CONFIG_HYPERV can't be selected. Patch 3 is separate because it > > applies to architecture independent code and arch/x86 code -- I thought > > there might be value in keeping the ARM64 and x86 patches distinct. > > Patch 4 applies to architecture independent code, and enables the > > ARM64 code in patches 1 and 2 to be compiled and run when > > CONFIG_HYPERV is selected. > > > > If combining some of the patches in the series is a better approach, I'm > > good with that. > > Ok, that makes more sense, if it is easier to get the ARM people to > review this, that's fine. Doesn't seem like anyone did that yet :( It's on the list, but thanks for having a look as well! Will ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/4] arm64: hyperv: Add support for Hyper-V as a hypervisor
On Thu, Nov 22, 2018 at 03:10:57AM +, k...@linuxonhyperv.com wrote: > From: Michael Kelley > > Add ARM64-specific code to enable Hyper-V. This code includes: > * Detecting Hyper-V and initializing the guest/Hyper-V interface > * Setting up Hyper-V's synthetic clocks > * Making hypercalls using the HVC instruction > * Setting up VMbus and stimer0 interrupts > * Setting up kexec and crash handlers > This code is architecture dependent code and is mostly driven by > architecture independent code in the VMbus driver in drivers/hv/hv.c > and drivers/hv/vmbus_drv.c. > > This code is built only when CONFIG_HYPERV is enabled. > > Signed-off-by: Michael Kelley > Signed-off-by: K. Y. Srinivasan > --- > MAINTAINERS | 1 + > arch/arm64/Makefile | 1 + > arch/arm64/hyperv/Makefile | 2 + > arch/arm64/hyperv/hv_hvc.S | 54 + > arch/arm64/hyperv/hv_init.c | 441 +++ > arch/arm64/hyperv/mshyperv.c | 178 ++ > 6 files changed, 677 insertions(+) > create mode 100644 arch/arm64/hyperv/Makefile > create mode 100644 arch/arm64/hyperv/hv_hvc.S > create mode 100644 arch/arm64/hyperv/hv_init.c > create mode 100644 arch/arm64/hyperv/mshyperv.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 72f19cef4c48..326eeb32a0cd 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6837,6 +6837,7 @@ F: arch/x86/kernel/cpu/mshyperv.c > F: arch/x86/hyperv > F: arch/arm64/include/asm/hyperv-tlfs.h > F: arch/arm64/include/asm/mshyperv.h > +F: arch/arm64/hyperv > F: drivers/hid/hid-hyperv.c > F: drivers/hv/ > F: drivers/input/serio/hyperv-keyboard.c > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile > index 6cb9fc7e9382..ad9ec0579553 100644 > --- a/arch/arm64/Makefile > +++ b/arch/arm64/Makefile > @@ -106,6 +106,7 @@ core-y+= arch/arm64/kernel/ arch/arm64/mm/ > core-$(CONFIG_NET) += arch/arm64/net/ > core-$(CONFIG_KVM) += arch/arm64/kvm/ > core-$(CONFIG_XEN) += arch/arm64/xen/ > +core-$(CONFIG_HYPERV) += arch/arm64/hyperv/ > core-$(CONFIG_CRYPTO) += arch/arm64/crypto/ > libs-y := arch/arm64/lib/ $(libs-y) > core-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a > diff --git a/arch/arm64/hyperv/Makefile b/arch/arm64/hyperv/Makefile > new file mode 100644 > index ..988eda55330c > --- /dev/null > +++ b/arch/arm64/hyperv/Makefile > @@ -0,0 +1,2 @@ > +# SPDX-License-Identifier: GPL-2.0 > +obj-y:= hv_init.o hv_hvc.o mshyperv.o > diff --git a/arch/arm64/hyperv/hv_hvc.S b/arch/arm64/hyperv/hv_hvc.S > new file mode 100644 > index ..82636969b4f2 > --- /dev/null > +++ b/arch/arm64/hyperv/hv_hvc.S > @@ -0,0 +1,54 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > + > +/* > + * Microsoft Hyper-V hypervisor invocation routines > + * > + * Copyright (C) 2018, Microsoft, Inc. > + * > + * Author : Michael Kelley > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 as published > + * by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, but > + * WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or > + * NON INFRINGEMENT. See the GNU General Public License for more > + * details. > + */ > + > +#include > + > + .text > +/* > + * Do the HVC instruction. For Hyper-V the argument is always 1. > + * x0 contains the hypercall control value, while additional registers > + * vary depending on the hypercall, and whether the hypercall arguments > + * are in memory or in registers (a "fast" hypercall per the Hyper-V > + * TLFS). When the arguments are in memory x1 is the guest physical > + * address of the input arguments, and x2 is the guest physical > + * address of the output arguments. When the arguments are in > + * registers, the register values depends on the hypercall. Note > + * that this version cannot return any values in registers. > + */ > +ENTRY(hv_do_hvc) > + hvc #1 > + ret > +ENDPROC(hv_do_hvc) > + > +/* > + * This variant of HVC invocation is for hv_get_vpreg and > + * hv_get_vpreg_128. The input parameters are passed in registers > + * along with a pointer in x4 to where the output result should > + * be stored. The output is returned in x15 and x16. x18 is used as > + * scratch space to avoid buildng a stack frame, as Hyper-V does > + * not preserve registers x0-x17. > + */ > +ENTRY(hv_do_hvc_fast_get) > + mov x18, x4 > + hvc #1 > + str x15,[x18] > + str x16,[x18,#8] > + ret > +ENDPROC(hv_do_hvc_fast_get) Why are you not following the ARM SMCCC? It would be /much/ better if you could just follow the standard, which is already implemented by include/linux/smccc.h. Will ___ devel mailing list de...@linuxdriverproject.org http://dri
Re: [PATCH 1/4] arm64: hyperv: Add core Hyper-V include files
Hi all, On Thu, Nov 22, 2018 at 03:10:56AM +, k...@linuxonhyperv.com wrote: > From: Michael Kelley > > hyperv-tlfs.h defines Hyper-V interfaces from the Hyper-V Top Level > Functional Spec (TLFS). The TLFS is distinctly oriented to x86/x64, > and Hyper-V has not separated out the architecture-dependent parts into > x86/x64 vs. ARM64. So hyperv-tlfs.h includes information for ARM64 > that is not yet formally published. The TLFS is available here: When do you plan to publish the spec? It's pretty hard to review this stuff without knowing what it's supposed to look like. > docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/reference/tlfs > > mshyperv.h defines Linux-specific structures and routines for > interacting with Hyper-V. It is split into an ARM64 specific file > and an architecture independent file in include/asm-generic. > > Signed-off-by: Michael Kelley > Signed-off-by: K. Y. Srinivasan > --- > MAINTAINERS | 3 + > arch/arm64/include/asm/hyperv-tlfs.h | 338 +++ > arch/arm64/include/asm/mshyperv.h| 116 + > include/asm-generic/mshyperv.h | 240 +++ > 4 files changed, 697 insertions(+) > create mode 100644 arch/arm64/include/asm/hyperv-tlfs.h > create mode 100644 arch/arm64/include/asm/mshyperv.h > create mode 100644 include/asm-generic/mshyperv.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index f4855974f325..72f19cef4c48 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6835,6 +6835,8 @@ F: arch/x86/include/asm/trace/hyperv.h > F: arch/x86/include/asm/hyperv-tlfs.h > F: arch/x86/kernel/cpu/mshyperv.c > F: arch/x86/hyperv > +F: arch/arm64/include/asm/hyperv-tlfs.h > +F: arch/arm64/include/asm/mshyperv.h > F: drivers/hid/hid-hyperv.c > F: drivers/hv/ > F: drivers/input/serio/hyperv-keyboard.c > @@ -6846,6 +6848,7 @@ F: drivers/video/fbdev/hyperv_fb.c > F: net/vmw_vsock/hyperv_transport.c > F: include/linux/hyperv.h > F: include/uapi/linux/hyperv.h > +F: include/asm-generic/mshyperv.h > F: tools/hv/ > F: Documentation/ABI/stable/sysfs-bus-vmbus > > diff --git a/arch/arm64/include/asm/hyperv-tlfs.h > b/arch/arm64/include/asm/hyperv-tlfs.h > new file mode 100644 > index ..924e37600e92 > --- /dev/null > +++ b/arch/arm64/include/asm/hyperv-tlfs.h > @@ -0,0 +1,338 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > + > +/* > + * This file contains definitions from the Hyper-V Hypervisor Top-Level > + * Functional Specification (TLFS): > + * > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fvirtualization%2Fhyper-v-on-windows%2Freference%2Ftlfs&data=02%7C01%7Ckys%40microsoft.com%7Cc831a45fd63e4a4b083908d641216aa8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636768009113747528&sdata=jRSrs9ZWXdmeS7LQUEpoSyUfBS7a5KLYy%2FolFdE2tI0%3D&reserved=0 As mentioned elsewhere, please use a better link here and drop the license boilerplate below. > + * > + * Copyright (C) 2018, Microsoft, Inc. > + * > + * Author : Michael Kelley > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 as published > + * by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, but > + * WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or > + * NON INFRINGEMENT. See the GNU General Public License for more > + * details. > + */ > + > +#ifndef _ASM_ARM64_HYPERV_H > +#define _ASM_ARM64_HYPERV_H __ASM_HYPER_V_H please > + > +#include > + > +/* > + * These Hyper-V registers provide information equivalent to the CPUID > + * instruction on x86/x64. > + */ > +#define HV_REGISTER_HYPERVISOR_VERSION 0x0100 /*CPUID > 0x4002 */ > +#define HV_REGISTER_PRIVILEGES_AND_FEATURES 0x0200 /*CPUID > 0x4003 */ > +#define HV_REGISTER_FEATURES0x0201 /*CPUID > 0x4004 */ > +#define HV_REGISTER_IMPLEMENTATION_LIMITS 0x0202 /*CPUID > 0x4005 */ > +#define HV_ARM64_REGISTER_INTERFACE_VERSION 0x00090006 /*CPUID 0x4001 */ > + > +/* > + * Feature identification. HvRegisterPrivilegesAndFeaturesInfo returns a > + * 128-bit value with flags indicating which features are available to the > + * partition based upon the current partition privileges. The 128-bit > + * value is broken up with different portions stored in different 32-bit > + * fields in the ms_hyperv structure. > + */ > + > +/* Partition Reference Counter available*/ > +#define HV_MSR_TIME_REF_COUNT_AVAILABLE (1 << 1) > + > +/* > + * Synthetic Timers available > + */ > +#define HV_MSR_SYNTIMER_AVAILABLE(1 << 3) > + > +/* Frequency MSRs available */ > +#define HV_FEATURE_FREQUENCY_MSRS_AVAILABLE (1 << 8) > + > +/* Reference TSC available */ >
Re: [RFCv3][PATCH 3/5] arm64: Implement ARCH_HAS_FORCE_CACHE
Hi Laura, On Mon, Sep 12, 2016 at 02:32:56PM -0700, Laura Abbott wrote: > > arm64 may need to guarantee the caches are synced. Implement versions of > the kernel_force_cache API to allow this. > > Signed-off-by: Laura Abbott > --- > v3: Switch to calling cache operations directly instead of relying on > DMA mapping. > --- > arch/arm64/include/asm/cacheflush.h | 8 > arch/arm64/mm/cache.S | 24 > arch/arm64/mm/flush.c | 11 +++ > 3 files changed, 39 insertions(+), 4 deletions(-) I'm really hesitant to expose these cache routines as an API solely to support a driver sitting in staging/. I appreciate that there's a chicken and egg problem here, but we *really* don't want people using these routines in preference to the DMA API, and I fear that we'll simply grow a bunch more users of these things if we promote it as an API like you're proposing. Can the code not be contained under staging/, as part of ion? Will ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFCv3][PATCH 3/5] arm64: Implement ARCH_HAS_FORCE_CACHE
On Tue, Sep 13, 2016 at 08:02:20AM -0700, Laura Abbott wrote: > On 09/13/2016 02:19 AM, Will Deacon wrote: > >On Mon, Sep 12, 2016 at 02:32:56PM -0700, Laura Abbott wrote: > >> > >>arm64 may need to guarantee the caches are synced. Implement versions of > >>the kernel_force_cache API to allow this. > >> > >>Signed-off-by: Laura Abbott > >>--- > >>v3: Switch to calling cache operations directly instead of relying on > >>DMA mapping. > >>--- > >> arch/arm64/include/asm/cacheflush.h | 8 > >> arch/arm64/mm/cache.S | 24 > >> arch/arm64/mm/flush.c | 11 +++ > >> 3 files changed, 39 insertions(+), 4 deletions(-) > > > >I'm really hesitant to expose these cache routines as an API solely to > >support a driver sitting in staging/. I appreciate that there's a chicken > >and egg problem here, but we *really* don't want people using these routines > >in preference to the DMA API, and I fear that we'll simply grow a bunch > >more users of these things if we promote it as an API like you're proposing. > > > >Can the code not be contained under staging/, as part of ion? > > > > I proposed that in V1 and it was suggested I make it a proper API > > http://www.mail-archive.com/driverdev-devel@linuxdriverproject.org/msg47654.html > http://www.mail-archive.com/driverdev-devel@linuxdriverproject.org/msg47672.html :/ then I guess we're in disagreement. If ion really needs this stuff (which I don't fully grok), perhaps we should be exposing something at a higher level from the architecture, so it really can't be used for anything other than ion. Will ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
