v4:
- rebase to v5.8-rc2
v3: https://lore.kernel.org/lkml/20200406231606.37619-1-keesc...@chromium.org/
v2: https://lore.kernel.org/lkml/20200324203231.64324-1-keesc...@chromium.org/
rfc:
https://lore.kernel.org/kernel-hardening/20190329081358.30497-1-elena.reshet...@intel.com/
Hi,
This is a con
Allow for a randomized stack offset on a per-syscall basis, with roughly
5 bits of entropy.
Signed-off-by: Kees Cook
---
arch/x86/Kconfig| 1 +
arch/x86/entry/common.c | 11 +++
2 files changed, 12 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 6a0cc524882
On Mon 22 Jun 02:03 PDT 2020, Stephen Boyd wrote:
> Quoting Maulik Shah (2020-06-21 23:53:25)
> > rpmh-rsc driver is fairly core to system and should not be removable
> > once its probed. However it allows to unbind driver from sysfs using
> > below command which results into a crash on sc7180.
>
On Sun, 21 Jun 2020 12:56:28 -0400 Gaurav Singh wrote:
> Remove the redundant null check for skb.
>
> Signed-off-by: Gaurav Singh
Thanks for the patch, it looks correct, but could you describe your
proof / reasoning based on which this change is correct?
Please post non-bug fixes like this with
On Mon, Jun 22, 2020 at 12:28:56PM -0700, Minchan Kim wrote:
> Now, we have MADV_PAGEOUT and MADV_COLD as madvise hinting API. With that,
> application could give hints to kernel what memory range are preferred to be
> reclaimed. However, in some platform(e.g., Android), the information
> required
On 6/21/20 4:20 PM, Zi Yan wrote:
On 19 Jun 2020, at 17:56, Ralph Campbell wrote:
Support transparent huge page migration to ZONE_DEVICE private memory.
A new flag (MIGRATE_PFN_COMPOUND) is added to the input PFN array to
indicate the huge page was fully mapped by the CPU.
Export prep_compoun
On Tue, 23 Jun 2020 00:03:06 +0800 yunaixin03...@163.com wrote:
> From: yunaixin
>
> This patch set contains 5 communication drivers for Huawei BMA software.
> The BMA software is a system management software. It supports the status
> monitoring, performance monitoring, and event monitoring of va
On Wed, Jun 10, 2020 at 11:57:32AM -0700, Ben Gardon wrote:
> > ---
> > arch/x86/include/asm/kvm_host.h | 1 +
> > arch/x86/kvm/mmu/mmu.c | 7 ++-
> > 2 files changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/include/asm/kvm_host.h
> > b/arch/x86/include/asm/kvm_h
On 6/22/20 12:31 PM, Kees Cook wrote:
> This provides the ability for architectures to enable kernel stack base
> address offset randomization. This feature is controlled by the boot
> param "randomize_kstack_offset=on/off", with its default value set by
> CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT.
>
On Mon, Jun 22, 2020 at 07:53:50AM +0100, Lee Jones wrote:
> On Wed, 17 Jun 2020, Lubomir Rintel wrote:
>
> > Add binding document for the ENE KB3930 Embedded Controller.
> >
> > Signed-off-by: Lubomir Rintel
> > Reviewed-by: Rob Herring
> >
> > ---
> > Changes since v4:
> > - Collected Rob's
On Mon, Jun 22, 2020 at 09:04:06PM +0200, Uladzislau Rezki wrote:
> > > >
> > > > Very good. When does kfree_rcu() and friends move out of kernel/rcu?
> > > >
> > > Do you mean to move the whole logic of kfree_rcu() from top to down to
> > > mm/?
> >
> > I do mean exactly that.
> >
> > That w
> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Tuesday, June 23, 2020 6:28 AM
> To: Colin King
> Cc: Seth Jennings ; Dan Streetman
> ; Vitaly Wool ; Andrew
> Morton ; Song Bao Hua (Barry Song)
> ; Stephen Rothwell ;
> linux...@kvack.org; kernel-jani
Reflect an information about an author, date
and year when the KVA rework has been done.
Signed-off-by: Uladzislau Rezki (Sony)
---
mm/vmalloc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 1e94497b7388..3c3b6ec26f9c 100644
--- a/mm/vmalloc.c
+++ b/mm/vma
Fix build warning in k3_ringacc_ring_cfg():
smatch warnings:
drivers/soc/ti/k3-ringacc.c:562 k3_ringacc_ring_cfg() warn: variable
dereferenced before check 'ring' (see line 559)
557 int k3_ringacc_ring_cfg(struct k3_ring *ring, struct k3_ring_cfg *cfg)
558 {
@559 struct k3_ringa
On Mon, Jun 22, 2020 at 7:16 PM Chen Yu wrote:
>
> Hi Rafael,
> On Mon, Jun 22, 2020 at 06:19:35PM +0200, Rafael J. Wysocki wrote:
> [cut]
> > > +{
> > > + if (!current_clr_polling_and_test())
> > > + s2idle_enter(drv, dev, index);
> > > +
> > > + return index;
> >
> > Is
The other thing you ought to consider fixing:
initrd is documented as follows:
initrd= [BOOT] Specify the location of the initial ramdisk
for bootloaders only.
UEFI consumes initrd from the command line as well. As ARM servers
increasingly use UEFI, there may be situations in whi
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
On Sat, Jun 20, 2020 at 2:26 PM Maciej Żenczykowski
wrote:
>
> From: Maciej Żenczykowski
>
> This is a fix for a regression introduced in 5.8-rc1 by:
> commit 2c78ee898d8f10ae6fb2fa23a3fbaec96b1b7366
> 'bpf: Implement CAP_BPF'
>
> Before the above commit it was possible to load network bpf pr
On 18/06/2020 15:38, Neil Armstrong wrote:
> The new Khadas VIM2 and VIM3 boards controls the cooling fan via the
> on-board microcontroller.
>
> This implements the FAN control as thermal devices and as cell of the Khadas
> MCU MFD driver.
>
> Signed-off-by: Neil Armstrong
> Reviewed-by: Amit K
Nitro Enclaves (NE) is a new Amazon Elastic Compute Cloud (EC2) capability
that allows customers to carve out isolated compute environments within EC2
instances [1].
For example, an application that processes sensitive data and runs in a VM,
can be separated from other applications running in the
The Nitro Enclaves (NE) driver communicates with a new PCI device, that
is exposed to a virtual machine (VM) and handles commands meant for
handling enclaves lifetime e.g. creation, termination, setting memory
regions. The communication with the PCI device is handled using a MMIO
space and MSI-X in
The Nitro Enclaves PCI device exposes a MMIO space that this driver
uses to submit command requests and to receive command replies e.g. for
enclave creation / termination or setting enclave resources.
Add logic for handling PCI device command requests based on the given
command type.
Register an
The Nitro Enclaves driver handles the enclave lifetime management. This
includes enclave creation, termination and setting up its resources such
as memory and CPU.
An enclave runs alongside the VM that spawned it. It is abstracted as a
process running in the VM that launched it. The process intera
The Nitro Enclaves driver keeps an internal info per each enclave.
This is needed to be able to manage enclave resources state, enclave
notifications and have a reference of the PCI device that handles
command requests for enclave lifetime management.
Signed-off-by: Alexandru-Catalin Vasile
Sign
The Nitro Enclaves driver provides an ioctl interface to the user space
for enclave lifetime management e.g. enclave creation / termination and
setting enclave resources such as memory and CPU.
This ioctl interface is mapped to a Nitro Enclaves misc device.
Signed-off-by: Andra Paraschiv
---
Cha
Add ioctl command logic for enclave VM creation. It triggers a slot
allocation. The enclave resources will be associated with this slot and
it will be used as an identifier for triggering enclave run.
Return a file descriptor, namely enclave fd. This is further used by the
associated user space en
The Nitro Enclaves PCI device is used by the kernel driver as a means of
communication with the hypervisor on the host where the primary VM and
the enclaves run. It handles requests with regard to enclave lifetime.
Setup the PCI device driver and add support for MSI-X interrupts.
Signed-off-by: A
In addition to the replies sent by the Nitro Enclaves PCI device in
response to command requests, out-of-band enclave events can happen e.g.
an enclave crashes. In this case, the Nitro Enclaves driver needs to be
aware of the event and notify the corresponding user space process that
abstracts the
An enclave, before being started, has its resources set. One of its
resources is CPU.
The NE CPU pool is set for choosing CPUs for enclaves from it. Offline
the CPUs from the NE CPU pool during the pool setup and online them back
during the NE CPU pool teardown.
The enclave CPUs need to be full c
An enclave is associated with an fd that is returned after the enclave
creation logic is completed. This enclave fd is further used to setup
enclave resources. Once the enclave needs to be terminated, the enclave
fd is closed.
Add logic for enclave termination, that is mapped to the enclave fd
rel
After all the enclave resources are set, the enclave is ready for
beginning to run.
Add ioctl command logic for starting an enclave after all its resources,
memory regions and CPUs, have been set.
The enclave start information includes the local channel addressing -
vsock CID - and the flags asso
Before setting the memory regions for the enclave, the enclave image
needs to be placed in memory. After the memory regions are set, this
memory cannot be used anymore by the VM, being carved out.
Add ioctl command logic to get the offset in enclave memory where to
place the enclave image. Then th
Another resource that is being set for an enclave is memory. User space
memory regions, that need to be backed by contiguous memory regions,
are associated with the enclave.
One solution for allocating / reserving contiguous memory regions, that
is used for integration, is hugetlbfs. The user spac
Signed-off-by: Andra Paraschiv
---
Changelog
v3 -> v4
* No changes.
v2 -> v3
* Update file entries to be in alphabetical order.
v1 -> v2
* No changes.
---
MAINTAINERS | 13 +
1 file changed, 13 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7b5ffd646c6b..66f35c4de16
Signed-off-by: Alexandru Vasile
Signed-off-by: Andra Paraschiv
---
Changelog
v3 -> v4
* Update usage details to match the updates in v4.
* Update NE ioctl interface usage.
v2 -> v3
* Remove the include directory to use the uapi from the kernel.
* Remove the GPL additional wording as SPDX-Lice
Signed-off-by: Andra Paraschiv
---
Changelog
v3 -> v4
* No changes.
v2 -> v3
* Remove the GPL additional wording as SPDX-License-Identifier is
already in place.
v1 -> v2
* Update path to Makefile to match the drivers/virt/nitro_enclaves
directory.
---
drivers/virt/Makefile
Signed-off-by: Andra Paraschiv
---
Changelog
v3 -> v4
* Add PCI and SMP dependencies.
v2 -> v3
* Remove the GPL additional wording as SPDX-License-Identifier is
already in place.
v1 -> v2
* Update path to Kconfig to match the drivers/virt/nitro_enclaves
directory.
* Update help in Kconfi
Signed-off-by: Andra Paraschiv
---
Changelog
v3 -> v4
* Update doc type from .txt to .rst.
* Update documentation based on the changes from v4.
v2 -> v3
* No changes.
v1 -> v2
* New in v2.
---
Documentation/nitro_enclaves/ne_overview.rst | 87
1 file changed, 87 inserti
On Mon, Jun 22, 2020 at 7:29 PM Joe Perches wrote:
>
> scripts/get_maintainer.pl --self-test=links has a reachability test
> using wget.
>
> Perhaps a script like that could be used for http:// vs https://
+1
Not sure about `--no-check-certificate` if the goal is to move to
"proper HTTPS". Perha
The binder driver makes the assumption proc->context pointer is invariant after
initialization (as documented in the kerneldoc header for struct proc).
However, in commit f0fe2c0f050d ("binder: prevent UAF for binderfs devices II")
proc->context is set to NULL during binder_deferred_release().
Ano
While we expose the ability to turn off hardware dithering for nouveau,
we actually make the mistake of turning it on anyway, due to
dithering_depth containing a non-zero value if our dithering depth isn't
also set to 6 bpc.
So, fix it by never enabling dithering when it's disabled.
Signed-off-by
Currently, we modify the depth value stored in the atomic state when
performing a commit in order to workaround the fact we haven't
implemented support for depths higher then 10 yet. This isn't idempotent
though, as it will happen every atomic commit where we modify the OR
state even if the head's
Add some kind of vblank workers. The interface is similar to regular
delayed works, and is mostly based off kthread_work. It allows for
scheduling delayed works that execute once a particular vblank sequence
has passed. It also allows for accurate flushing of scheduled vblank
works - in that flushi
Since we'll be allocating resources for kthread_create_worker() in the
next commit (which could fail and require us to clean up the mess),
let's simplify the cleanup process a bit by registering a
drm_vblank_init_release() action for each drm_vblank_crtc so they're
still cleaned up if we fail to in
While we're not quite ready yet to add support for flexible wndw
mappings, we are going to need to at least keep track of the static wndw
mappings we're currently using in each head's atomic state. We'll likely
use this in the future to implement real flexible window mapping, but
the primary reason
We refer to the armed hardware assembly as armh elsewhere in nouveau, so
fix the naming here to make it consistent.
This patch contains no functional changes.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
On Mon, Jun 22, 2020 at 9:31 PM Kees Cook wrote:
> This provides the ability for architectures to enable kernel stack base
> address offset randomization. This feature is controlled by the boot
> param "randomize_kstack_offset=on/off", with its default value set by
> CONFIG_RANDOMIZE_KSTACK_OFFSET
We'll be rolling back more things in this function, and the way it's
structured is a bit confusing. So, let's clean this up a bit and just
unroll in the event of failure.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/head.c | 33 +
1 file changed, 23 inse
Add a "gfp_zero" member to arm64's 'struct kvm_mmu_memory_cache' to make
the struct and its usage compatible with the common 'struct
kvm_mmu_memory_cache' in linux/kvm_host.h. This will minimize code
churn when arm64 moves to the common implementation in a future patch, at
the cost of temporarily
Use GFP_KERNEL_ACCOUNT instead of GFP_KERNEL when allocating pages for
the the GPA page tables. The primary motivation for accounting the
allocations is to align with the common KVM memory cache helpers in
preparation for moving to the common implementation in a future patch.
The actual accounting
Move x86's 'struct kvm_mmu_memory_cache' to common code in anticipation
of moving the entire x86 implementation code to common KVM and reusing
it for arm64 and MIPS. Add a new architecture specific asm/kvm_types.h
to control the existence and parameters of the struct. The new header
is needed to
Use separate caches for allocating shadow pages versus gfn arrays. This
sets the stage for specifying __GFP_ZERO when allocating shadow pages
without incurring extra cost for gfn arrays.
No functional change intended.
Reviewed-by: Ben Gardon
Signed-off-by: Sean Christopherson
---
arch/x86/inc
This introduces support for CRC readback on gf119+, using the
documentation generously provided to us by Nvidia:
https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt
We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed
through a single set of "outp" so
Replace the @max param in mmu_topup_memory_cache() and instead use
ARRAY_SIZE() to terminate the loop to fill the cache. This removes a
BUG_ON() and sets the stage for moving arm64 to the common memory cache
implementation.
No functional change intended.
Tested-by: Marc Zyngier
Signed-off-by: S
On Mon, Jun 22, 2020 at 01:07:15PM -0700, Todd Kjos wrote:
> The binder driver makes the assumption proc->context pointer is invariant
> after
> initialization (as documented in the kerneldoc header for struct proc).
> However, in commit f0fe2c0f050d ("binder: prevent UAF for binderfs devices
> I
Move to the common MMU memory cache implementation now that the common
code and MIPS's existing code are semantically compatible.
No functional change intended.
Suggested-by: Christoffer Dall
Signed-off-by: Sean Christopherson
---
arch/mips/include/asm/Kbuild | 1 -
arch/mips/include/asm
Move x86's memory cache helpers to common KVM code so that they can be
reused by arm64 and MIPS in future patches.
Suggested-by: Christoffer Dall
Reviewed-by: Ben Gardon
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu/mmu.c | 53 --
include/linux/k
Replace the @max param in mmu_topup_memory_cache() and instead use
ARRAY_SIZE() to terminate the loop to fill the cache. This removes a
BUG_ON() and sets the stage for moving MIPS to the common memory cache
implementation.
No functional change intended.
Signed-off-by: Sean Christopherson
---
a
Move to the common MMU memory cache implementation now that the common
code and arm64's existing code are semantically compatible.
No functional change intended.
Suggested-by: Christoffer Dall
Tested-by: Marc Zyngier
Signed-off-by: Sean Christopherson
---
arch/arm64/include/asm/Kbuild |
Return errors directly from mmu_topup_memory_caches() instead of
branching to a label that does the same.
No functional change intended.
Reviewed-by: Ben Gardon
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu/mmu.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --g
Don't bother filling the gfn array cache when the caller is a fully
direct MMU, i.e. won't need a gfn array for shadow pages.
Reviewed-by: Ben Gardon
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu/mmu.c | 18 ++
arch/x86/kvm/mmu/paging_tmpl.h | 4 ++--
2 files
Rename the memory helpers that will soon be moved to common code and be
made globaly available via linux/kvm_host.h. "mmu" alone is not a
sufficient namespace for globally available KVM symbols.
Opportunistically add "nr_" in mmu_memory_cache_free_objects() to make
it clear the function returns t
In order to make sure that we flush disable updates at the right time
when disabling CRCs, we'll need to be able to look at the outp state to
see if we're changing it at the same time that we're disabling CRCs.
So, expose the struct in disp.h.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouve
On 22 Jun 2020, at 15:36, Ralph Campbell wrote:
> On 6/21/20 4:20 PM, Zi Yan wrote:
>> On 19 Jun 2020, at 17:56, Ralph Campbell wrote:
>>
>>> Support transparent huge page migration to ZONE_DEVICE private memory.
>>> A new flag (MIGRATE_PFN_COMPOUND) is added to the input PFN array to
>>> indicate
Track the kmem_cache used for non-page KVM MMU memory caches instead of
passing in the associated kmem_cache when filling the cache. This will
allow consolidating code and other cleanups.
No functional change intended.
Reviewed-by: Ben Gardon
Signed-off-by: Sean Christopherson
---
arch/x86/in
Set __GFP_ZERO for the shadow page memory cache and drop the explicit
clear_page() from kvm_mmu_get_page(). This moves the cost of zeroing a
page to the allocation time of the physical page, i.e. when topping up
the memory caches, and thus avoids having to zero out an entire page
while holding mmu
Add a gfp_zero flag to 'struct kvm_mmu_memory_cache' and use it to
control __GFP_ZERO instead of hardcoding a call to kmem_cache_zalloc().
A future patch needs such a flag for the __get_free_page() path, as
gfn arrays do not need/want the allocator to zero the memory. Convert
the kmem_cache paths
While most of the functionality on Nvidia GPUs doesn't require using an
explicit handle instead of the main VRAM handle + offset, there are a
couple of places that do require explicit handles, such as CRC
functionality. Since this means we're about to add another
nouveau-chosen handle, let's just g
Topup memory caches after walking the GVA->GPA translation during a
shadow page fault, there is no need to ensure the caches are full when
walking the GVA. As of commit f5a1e9f89504f ("KVM: MMU: remove call
to kvm_mmu_pte_write from walk_addr"), the FNAME(walk_addr) flow no
longer add rmaps via kv
Clean up the minimums in mmu_topup_memory_caches() to document the
driving mechanisms behind the minimums. Now that encountering an empty
cache is unlikely to trigger BUG_ON(), it is less dangerous to be more
precise when defining the minimums.
For rmaps, the logic is 1 parent PTE per level, plus
Attempt to allocate a new object instead of crashing KVM (and likely the
kernel) if a memory cache is unexpectedly empty. Use GFP_ATOMIC for the
allocation as the caches are used while holding mmu_lock. The immediate
BUG_ON() makes the code unnecessarily explosive and led to confusing
minimums be
Avoid refilling the memory caches and potentially slow reclaim/swap when
handling a fast page fault, which does not need to allocate any new
objects.
Reviewed-by: Ben Gardon
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu/mmu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Note, patch 18 will conflict with the p4d rework in 5.8. I originally
stated I would send v2 only after that got pulled into Paolo's tree, but
I got my timing wrong, i.e. I was thinking that would have already
happened. I'll send v3 if necessary. I wanted to get v2 out there now
that I actually
Use "mc" for local variables to shorten line lengths and provide
consistent names, which will be especially helpful when some of the
helpers are moved to common KVM code in future patches.
No functional change intended.
Reviewed-by: Ben Gardon
Signed-off-by: Sean Christopherson
---
arch/x86/kv
Drop the "page" variants of the topup/free memory cache helpers, using
the existence of an associated kmem_cache to select the correct alloc
or free routine.
No functional change intended.
Reviewed-by: Ben Gardon
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu/mmu.c | 37 +++---
On Thu, 2020-06-18 at 16:11 -0400, Maurizio Drocco wrote:
> From: Maurizio
>
> If PCRs 8 - 9 are set (i.e. not all-zeros), cal_bootaggr should include
> them into the digest.
>
> Signed-off-by: Maurizio Drocco
> ---
> src/evmctl.c | 16 +++-
> 1 file changed, 15 insertions(+), 1 de
Am 22.06.20 um 22:06 schrieb Miguel Ojeda:
On Mon, Jun 22, 2020 at 7:29 PM Joe Perches wrote:
scripts/get_maintainer.pl --self-test=links has a reachability test
using wget.
Perhaps a script like that could be used for http:// vs https://
+1
Not sure about `--no-check-certificate` if th
On Mon, Jun 22, 2020 at 08:46:17AM -0300, Jason Gunthorpe wrote:
> On Fri, Jun 19, 2020 at 04:31:47PM -0400, Jerome Glisse wrote:
> > Not doable as page refcount can change for things unrelated to GUP, with
> > John changes we can identify GUP and we could potentialy copy GUPed page
> > instead of
On Mon, Jun 22, 2020 at 03:28:13PM -0400, Mimi Zohar wrote:
> On Mon, 2020-06-22 at 14:27 -0300, Bruno Meneguele wrote:
> > IMA_APPRAISE_BOOTPARAM has been marked as dependent on !IMA_ARCH_POLICY in
> > compile time, enforcing the appraisal whenever the kernel had the arch
> > policy option enabled
num_extents is already checked in the next if condition and can
be safely removed.
Signed-off-by: Denis Efremov
---
fs/btrfs/tests/free-space-tree-tests.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/fs/btrfs/tests/free-space-tree-tests.c
b/fs/btrfs/tests/free-space-tree-tests.c
index 9
Fix the parameter names in the comment to correspond to those in the
function header.
Drop comments about return values when there is no return value.
Signed-off-by: Julia Lawall
---
arch/arm/mach-omap2/omap-secure.c| 2 +-
arch/arm/mach-prima2/rtciobrg.c | 2
On Mon, Jun 22, 2020 at 1:09 PM Christian Brauner
wrote:
>
> On Mon, Jun 22, 2020 at 01:07:15PM -0700, Todd Kjos wrote:
> > The binder driver makes the assumption proc->context pointer is invariant
> > after
> > initialization (as documented in the kerneldoc header for struct proc).
> > However,
Introduce sptep_to_sp() to reduce the boilerplate code needed to get the
shadow page associated with a spte pointer, and to improve readability
as it's not immediately obvious that "page_header" is a KVM-specific
accessor for retrieving a shadow page.
Signed-off-by: Sean Christopherson
---
arch/
Move more files to the mmu/ directory, and an mmu_internal.h to share
stuff amongst the mmu/ files, and clean up the helpers for retrieving a
shadow page from a sptep and/or hpa.
Sean Christopherson (6):
KVM: x86/mmu: Move mmu_audit.c and mmutrace.h into the mmu/
sub-directory
KVM: x86/mmu
Move kvm_mmu_available_pages() from mmu.h to mmu.c, it has a single
caller and has no business being exposed via mmu.h.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu.h | 9 -
arch/x86/kvm/mmu/mmu.c | 9 +
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git
Move mmu_audit.c and mmutrace.h under mmu/ where they belong.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/{ => mmu}/mmu_audit.c | 0
arch/x86/kvm/{ => mmu}/mmutrace.h | 2 +-
2 files changed, 1 insertion(+), 1 deletion(-)
rename arch/x86/kvm/{ => mmu}/mmu_audit.c (100%)
rename arch/x8
Add mmu/mmu_internal.h to hold declarations and definitions that need
to be shared between various mmu/ files, but should not be used by
anything outside of the MMU.
Begin populating mmu_internal.h with declarations of the helpers used by
page_track.c.
Signed-off-by: Sean Christopherson
---
arc
Make 'struct kvm_mmu_page' MMU-only, nothing outside of the MMU should
be poking into the gory details of shadow pages.
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm_host.h | 46 ++-
arch/x86/kvm/mmu/mmu_internal.h | 48 ++
Rename KVM's accessor for retrieving a 'struct kvm_mmu_page' from the
associated host physical address to better convey what the function is
doing.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu/mmu.c | 20 ++--
arch/x86/kvm/mmu/mmu_audit.c| 6 +++---
arch/
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Gustavo A. R. Silva
> Sent: Friday, June 19, 2020 10:56 AM
> To: Kirsher, Jeffrey T ; David S. Miller
> ; Jakub Kicinski
> Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-
> ker...@vger.kernel.org
> Subject: [
Running a guest with a virtio-iommu protecting virtio devices
is broken since commit 515e5b6d90d4 ("dma-mapping: use vmap insted
of reimplementing it"). Before the conversion, the size was
page aligned in __get_vm_area_node(). Doing so fixes the
regression.
Fixes: 515e5b6d90d4 ("dma-mapping: use v
On June 19, 2020 5:03:33 PM PDT, ron minnich wrote:
>It seems fine to me, but I did not initially object to the use of that
>name anyway. hpa, what do you think?
>
>On Fri, Jun 19, 2020 at 7:31 AM Tom Rini wrote:
>>
>> Most architectures have been passing the location of an initrd via
>the
>> ini
Hi Mathieu,
On 6/22/20 12:35 PM, Mathieu Poirier wrote:
Hi Suman,
Apologies for the late reply, this one slipped through the cracks...
No problem :)
On Fri, Jun 12, 2020 at 05:49:10PM -0500, Suman Anna wrote:
Texas Instruments' K3 generation SoCs have specific modules/register
spaces use
Running the crypto manager self tests with
CONFIG_CRYPTO_MANAGER_EXTRA_TESTS may result in several types of errors
when using the ccp-crypto driver:
alg: skcipher: cbc-des3-ccp encryption failed on test vector 0;
expected_error=0, actual_error=-5 ...
alg: skcipher: ctr-aes-ccp decryption overran
Hi,
On Mon, Jun 22, 2020 at 5:16 AM Stanimir Varbanov
wrote:
>
> From: Mansur Alisha Shaik
>
> Currently we are considering the instances which are available
> in core->inst list for load calculation in min_loaded_core()
> function, but this is incorrect because by the time we call
> decide_core
On Mon, 2020-06-22 at 21:37 +0200, Julia Lawall wrote:
> Fix the parameter names in the comment to correspond to those in the
> function header.
>
> Drop comments about return values when there is no return value.
Done by hand or script?
[]
> diff --git a/arch/mips/cavium-octeon/executive/cvmx-s
clk_s is checked twice in a row in ni_init_smc_spll_table().
fb_div should be checked instead.
Fixes: 69e0b57a91ad ("drm/radeon/kms: add dpm support for cayman (v5)")
Cc: sta...@vger.kernel.org
Signed-off-by: Denis Efremov
---
drivers/gpu/drm/radeon/ni_dpm.c | 2 +-
1 file changed, 1 insertion(+
On Mon, Jun 22, 2020 at 8:50 AM Sedat Dilek wrote:
>
> When building with LLVM_IAS=1 means using Clang's Integrated Assembly (IAS)
> from LLVM/Clang >= v10.0.1-rc1+ instead of GNU/as from GNU/binutils
> I see the following breakage in Debian/testing AMD64:
>
> :15:74: error: too many positional ar
On Mon, Jun 22, 2020 at 12:21:28PM -0700, Shakeel Butt wrote:
> On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin wrote:
> >
> > Instead of having two sets of kmem_caches: one for system-wide and
> > non-accounted allocations and the second one shared by all accounted
> > allocations, we can use just
On Mon, Jun 22, 2020 at 01:02:16PM -0700, ron minnich wrote:
> The other thing you ought to consider fixing:
> initrd is documented as follows:
>
> initrd= [BOOT] Specify the location of the initial ramdisk
>
> for bootloaders only.
>
> UEFI consumes initrd from the command line
701 - 800 of 1785 matches
Mail list logo
