Hi Marc,
On 19/03/18 16:57, Marc Zyngier wrote:
> On 19/03/18 09:20, Eric Auger wrote:
>> To prepare for multiple RDIST regions, let's record the RDIST
>> Last bit field when registering the IO device.
>>
>> As a reminder the Last bit indicates whether the redistributor
>> is the highest one in a
Hi Marc,
On 19/03/18 15:15, Marc Zyngier wrote:
> On 19/03/18 09:20, Eric Auger wrote:
>> We introduce a new KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION attribute in
>> KVM_DEV_ARM_VGIC_GRP_ADDR group. It allows userspace to provide the
>> base address and size of a redistributor region
>>
>> Compared to
Hi Marc,
On 19/03/18 14:46, Marc Zyngier wrote:
> On 19/03/18 09:20, Eric Auger wrote:
>> in case kvm_vgic_map_resources() fails, typically if the vgic
>> distributor is not defined, __kvm_vgic_destroy will be called
>> several times. Indeed kvm_vgic_map_resources() is called on
>> first vcpu run.
Hi Andrey,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc6]
[cannot apply to next-20180319]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com
On 06/03/18 10:32, Marc Zyngier wrote:
> On Mon, 05 Mar 2018 17:06:43 +,
> Shanker Donthineni wrote:
>>
>> The function SMCCC_ARCH_WORKAROUND_1 was introduced as part of SMC
>> V1.1 Calling Convention to mitigate CVE-2017-5715. This patch uses
>> the standard call SMCCC_ARCH_WORKAROUND_1 for Fa
On 19/03/18 09:20, Eric Auger wrote:
> To prepare for multiple RDIST regions, let's record the RDIST
> Last bit field when registering the IO device.
>
> As a reminder the Last bit indicates whether the redistributor
> is the highest one in a series of contiguous redistributor pages.
>
> Since at
Hi Borislav,
On 08/03/18 10:44, Borislav Petkov wrote:
> On Wed, Mar 07, 2018 at 06:15:02PM +, James Morse wrote:
>> Today its just x86 and arm64. arm64 doesn't have a hook to do this. I'm
>> happy to
>> add an empty declaration or leave it under an ifdef until someone complains
>> about any
On 19/03/18 09:20, Eric Auger wrote:
> We introduce a new KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION attribute in
> KVM_DEV_ARM_VGIC_GRP_ADDR group. It allows userspace to provide the
> base address and size of a redistributor region
>
> Compared to KVM_VGIC_V3_ADDR_TYPE_REDIST, this new attribute allows
On 19/03/18 09:20, Eric Auger wrote:
> in case kvm_vgic_map_resources() fails, typically if the vgic
> distributor is not defined, __kvm_vgic_destroy will be called
> several times. Indeed kvm_vgic_map_resources() is called on
> first vcpu run. As a result dist->spis is freeed twice and on
> the se
Now all the internals are ready to handle multiple redistributor
regions, let's allow the userspace to register them.
Signed-off-by: Eric Auger
---
virt/kvm/arm/vgic/vgic-kvm-device.c | 34 +-
virt/kvm/arm/vgic/vgic-mmio-v3.c| 4 ++--
virt/kvm/arm/vgic/vgic.h
On vcpu first run, we eventually know the actual number of vcpus.
This is a synchronization point to check all redistributors regions
were assigned. On kvm_vgic_map_resources() we check both dist and
redist were set, eventually check potential base address inconsistencies.
Signed-off-by: Eric Auge
This new attribute allows the userspace to set the base address
of a reditributor region, relaxing the constraint of having all
consecutive redistibutor frames contiguous.
Signed-off-by: Eric Auger
---
arch/arm/include/uapi/asm/kvm.h | 7 ---
arch/arm64/include/uapi/asm/kvm.h | 7 ---
As we are going to register several redist regions,
vgic_register_all_redist_iodevs() may be called several times. We need
to register a redist_iodev for a given vcpu only once. So let's
check if the base address has already been set. Initialize this latter
in kvm_vgic_vcpu_early_init().
Signed-of
We introduce a new helper that creates and inserts a new redistributor
region into the rdist region list. This helper both handles the case
where the redistributor region size is known at registration time
and the legacy case where it is not (eventually depending on the number
of online vcpus). Dep
We introduce vgic_v3_rdist_free_slot to help identifying
where we can place a new 2x64KB redistributor.
Signed-off-by: Eric Auger
---
virt/kvm/arm/vgic/vgic-mmio-v3.c | 4 ++--
virt/kvm/arm/vgic/vgic-v3.c | 21 +
virt/kvm/arm/vgic/vgic.h | 12
3 fil
We introduce a new helper to check there is no overlap between
dist region (if set) and registered rdist regions. This both
handles the case of legacy single rdist region (implicitly sized
with the number of online vcpus) and the new case of multiple
explicitly sized rdist regions.
Signed-off-by:
The TYPER of an redistributor needs to reflect whether the rdist is
the last one of the redistributor region. With a single region we compared
the vcpu id against the number of online vcpus. With multiple regions,
we also need to check the region is not full.
Signed-off-by: Eric Auger
---
virt/k
At the moment KVM supports a single rdist region. We want to
support several separate rdist regions so let's introduce a list
of them. This patch currently only cares about a single
entry in this list as the functionality to register several redist
regions is not yet there. So this only translates
To prepare for multiple RDIST regions, let's record the RDIST
Last bit field when registering the IO device.
As a reminder the Last bit indicates whether the redistributor
is the highest one in a series of contiguous redistributor pages.
Since at the moment KVM only supports a single redist regio
in case kvm_vgic_map_resources() fails, typically if the vgic
distributor is not defined, __kvm_vgic_destroy will be called
several times. Indeed kvm_vgic_map_resources() is called on
first vcpu run. As a result dist->spis is freeed twice and on
the second time it causes a "kernel BUG at mm/slub.c:
We introduce a new KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION attribute in
KVM_DEV_ARM_VGIC_GRP_ADDR group. It allows userspace to provide the
base address and size of a redistributor region
Compared to KVM_VGIC_V3_ADDR_TYPE_REDIST, this new attribute allows
to declare several separate redistributor regi
At the moment the KVM VGICv3 only supports a single redistributor
region (whose base address is set through the GICv3 kvm device
KVM_DEV_ARM_VGIC_GRP_ADDR/KVM_VGIC_V3_ADDR_TYPE_REDIST). There,
all the redistributors are laid out contiguously. The size of this
single redistributor region is not set
On Mon, Mar 19, 2018 at 2:56 AM, Liuwenliang (Abbott Liu)
wrote:
> On 03/19/2018 09:23 AM, Florian Fainelli wrote:
>>On 03/18/2018 06:20 PM, Liuwenliang (Abbott Liu) wrote:
>>> On 03/19/2018 03:14 AM, Florian Fainelli wrote:
Thanks for posting these patches! Just FWIW, you cannot quite add
>>
On 18/03/18 12:53, Abbott Liu wrote:
> From: Andrey Ryabinin
>
> Disable instrumentation for arch/arm/boot/compressed/*
> and arch/arm/vdso/* because those code won't linkd with
> kernel image.
>
> Disable kasan check in the function unwind_pop_register
> because it doesn't matter that kasan che
On 03/19/2018 09:23 AM, Florian Fainelli wrote:
>On 03/18/2018 06:20 PM, Liuwenliang (Abbott Liu) wrote:
>> On 03/19/2018 03:14 AM, Florian Fainelli wrote:
>>> Thanks for posting these patches! Just FWIW, you cannot quite add
>>> someone's Tested-by for a patch series that was just resubmitted give
On 03/18/2018 06:20 PM, Liuwenliang (Abbott Liu) wrote:
> On 03/19/2018 03:14 AM, Florian Fainelli wrote:
>> Thanks for posting these patches! Just FWIW, you cannot quite add
>> someone's Tested-by for a patch series that was just resubmitted given
>> the differences with v1. I just gave it a spi
On 03/19/2018 03:14 AM, Florian Fainelli wrote:
>Thanks for posting these patches! Just FWIW, you cannot quite add
>someone's Tested-by for a patch series that was just resubmitted given
>the differences with v1. I just gave it a spin on a Cortex-A5 (no LPAE)
>and it looks like test_kasan.ko is pas
On Sun, Mar 18, 2018 at 21:21:20PM +0800, Russell King wrote:
>On Sun, Mar 18, 2018 at 08:53:36PM +0800, Abbott Liu wrote:
>> Because in some architecture(eg. arm) instruction set, non-aligned
>> access support is not very well, so 2 1-byte checks is more
>> safer than 1 2-byte check. The impact on
Define KASAN_SHADOW_OFFSET,KASAN_SHADOW_START and KASAN_SHADOW_END for arm
kernel address sanitizer.
++ 0x
||
||
||
++ CONFIG_PAGE_OFFSET
||\
|| |-> module virtual address space area.
||/
++ MODULE_VADDR = KA
From: Andrey Ryabinin
This patch enable kernel address sanitizer for arm.
Cc: Andrey Ryabinin
Tested-by: Florian Fainelli
Signed-off-by: Abbott Liu
---
arch/arm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 7e3d535..ac2287b 100644
--- a
Hi Abbott,
On 03/18/2018 05:53 AM, Abbott Liu wrote:
> Changelog:
> v2 - v1
> - Fixed some compiling error which happens on changing kernel compression
> mode to lzma/xz/lzo/lz4.
> ---Reported by: Florian Fainelli ,
>Russell King - ARM Linux
> - Fixed a compiling error cause by so
The purpose of this patch is to provide set_ttbr0/get_ttbr0
to kasan_init function. The definitions of cp15 registers
should be in arch/arm/include/asm/cp15.h rather than
arch/arm/include/asm/kvm_hyp.h, so move them.
Cc: Andrey Ryabinin
Reviewed-by: Marc Zyngier
Reviewed-by: Russell King - ARM L
From: Andrey Ryabinin
Functions like memset/memmove/memcpy do a lot of memory accesses.
If bad pointer passed to one of these function it is important
to catch this. Compiler's instrumentation cannot do this since
these functions are written in assembly.
KASan replaces memory functions with manu
From: Andrey Ryabinin
This patch initializes KASan shadow region's page table and memory.
There are two stage for KASan initializing:
1. At early boot stage the whole shadow region is mapped to just
one physical page (kasan_zero_page). It's finished by the function
kasan_early_init which is
Changelog:
v2 - v1
- Fixed some compiling error which happens on changing kernel compression
mode to lzma/xz/lzo/lz4.
---Reported by: Florian Fainelli ,
Russell King - ARM Linux
- Fixed a compiling error cause by some older arm instruction set(armv4t)
don't suppory movw/movt whi
From: Andrey Ryabinin
Disable instrumentation for arch/arm/boot/compressed/*
and arch/arm/vdso/* because those code won't linkd with
kernel image.
Disable kasan check in the function unwind_pop_register
because it doesn't matter that kasan checks failed when
unwind_pop_register read stack memory
Because in some architecture(eg. arm) instruction set, non-aligned
access support is not very well, so 2 1-byte checks is more
safer than 1 2-byte check. The impact on performance is small
because 16-byte accesses are not too common.
Cc: Andrey Ryabinin
Reviewed-by: Andrew Morton
Reviewed-by: Ru
37 matches
Mail list logo
