On 2019-10-12, Aleksa Sarai wrote:
> On 2019-10-12, Aleksa Sarai wrote:
> > On 2019-10-10, Linus Torvalds wrote:
> > > On Wed, Oct 9, 2019 at 10:42 PM Aleksa Sarai wrote:
> > > >
> > > > --- a/fs/namei.c
> > > > +++ b/fs/namei.c
> > > > @@ -2277,6 +2277,11 @@ static const char *path_init(struct
mm_tlb_flush_nested change was added in the mmu gather tlb flush to handle
the case of parallel pte invalidate happening with mmap_sem held in read
mode. This fix was done by commit: 02390f66bd23 ("powerpc/64s/radix: Fix
MADV_[FREE|DONTNEED] TLB flush miss problem with THP") and the problem is
expl
With commit: 22a61c3c4f13 ("asm-generic/tlb: Track freeing of page-table
directories in struct mmu_gather") we now track whether we freed page
table in mmu_gather. Use that to decide whether to flush Page Walk Cache.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/pgalloc.
With the previous patch, we should now not be using need_flush_all for powerpc.
But then make sure we force a PID tlbie flush with RIC=2 if we ever
find need_flush_all set. Also don't reset it after a mmu gather flush
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/book3s64/radix_tlb.c | 3 +
https://bugzilla.kernel.org/show_bug.cgi?id=205303
Bug ID: 205303
Summary: Compilation for PPC64 fails on warning in watchdog.o
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: 5.3.7
Hardware: PPC-64
OS: Lin
On 24.10.19 05:53, Anshuman Khandual wrote:
On 10/22/2019 10:42 PM, David Hildenbrand wrote:
Our onlining/offlining code is unnecessarily complicated. Only memory
blocks added during boot can have holes. Hotplugged memory never has
holes. That memory is already online.
Why hot plugged memory
On 18/10/2019 18.08, Christoph Hellwig wrote:
> On Fri, Oct 18, 2019 at 02:52:31PM +0200, Rasmus Villemoes wrote:
>> /* wait for the QE_CR_FLG to clear */
>> -ret = spin_event_timeout((ioread32be(&qe_immr->cp.cecr) & QE_CR_FLG) ==
>> 0,
>> - 100, 0);
>> -/*
https://bugzilla.kernel.org/show_bug.cgi?id=205303
--- Comment #1 from Edward Swiftwood (payphon...@gmail.com) ---
I failed to mention, the machine is an Apple iMac G5 "PowerMac8,1", PPC970FX @
1600MHz. (https://everymac.com/systems/apple/imac/specs/imac_g5_1.6_17.html)
--
You are receiving this
Some user might want to go through all registered wakeup sources
and doing things accordingly. For example, SoC PM driver might need to
do HW programming to prevent powering down specific IP which wakeup
source depending on. So add this API to help walk through all registered
wakeup source objects
By default, QorIQ SoC's RCPM register block is Big Endian. But
there are some exceptions, such as LS1088A and LS2088A, are
Little Endian. So add this optional property to help identify
them.
Actually LS2021A and other Layerscapes won't totally follow Chassis
2.1, so separate them from powerpc SoC.
The NXP's QorIQ processors based on ARM Core have RCPM module
(Run Control and Power Management), which performs system level
tasks associated with power management such as wakeup source control.
Note that this driver will not support PowerPC based QorIQ processors,
and it depends on PM wakeup sou
No functional change in this patch.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/platforms/pseries/lpar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/lpar.c
b/arch/powerpc/platforms/pseries/lpar.c
index f87a5c64e24d..3126fc02e50b 100644
With bolted hash page table entry, kernel currently only use primary hash group
when inserting the hash page table entry. In the rare case where kernel find
all the
8 primary hash slot occupied by bolted entries, this can result in hash page
table insert failure for bolted entries. Avoid this by u
If the hypervisor returned H_PTEG_FULL for H_ENTER hcall, retry a hash page
table
insert by removing a random entry from the group.
After some runtime, it is very well possible to find all the 8 hash page table
entry slot in the hpte group used for mapping. Don't fail a bolted entry insert
in tha
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_leaf() functions/macros.
For powerpc pmd_large() already exists and does what we wan
Hi,
these two patches come from discussion with Christoph, Bjorn, Palmer and
Waiman. The first patch was suggestion by Christoph here
https://lore.kernel.org/linux-riscv/20191008154604.ga7...@infradead.org/
The second part was discussed
https://lore.kernel.org/linux-pci/mhng-5d9bcb53-225e-441f-86c
msi.h is generic for all architectures expect of x86 which has own version.
Enabling MSI by including msi.h to architecture Kbuild is just additional
step which doesn't need to be done.
The patch was created based on request to enable MSI for Microblaze.
Suggested-by: Christoph Hellwig
Signed-off
Michal, thanks for looking into this.
On 23/10/19 11:26 PM, Michal Suchanek wrote:
> There is duplicate message about lack of support by firmware in
> fadump_reserve_mem and setup_fadump. Due to different capitalization it
> is clear that the one in setup_fadump is shown on boot. Remove the
> du
On Thu, Oct 24, 2019 at 04:08:08PM +0530, Hari Bathini wrote:
>
> Michal, thanks for looking into this.
>
> On 23/10/19 11:26 PM, Michal Suchanek wrote:
> > There is duplicate message about lack of support by firmware in
> > fadump_reserve_mem and setup_fadump. Due to different capitalization it
This patch adds group registration for the OpenCAPI devices.
An unique iommu group is register for multiple PE, ie for a set of
multiple devices sharing the same domain, same bus and same slot.
This groud registration will be used to assign an OpenCAPI device to a
guest to participate in VFIO, lik
This series adds support for the OpenCAPI devices for vfio pci.
It builds on top of the existing ocxl driver +
http://patchwork.ozlabs.org/patch/1177999/
VFIO is a Linux kernel driver framework used by QEMU to make devices
directly assignable to virtual machines.
All OpenCAPI devices on the same
This patch adds new IOCTL commands for VFIO PCI driver to support
configuration and management for OpenCAPI devices, which have been passed
through from host to QEMU VFIO.
OpenCAPI (Open Coherent Accelerator Processor Interface) is an interface
between processors and accelerators.
The main IOCTL c
From: Thomas Gleixner
CONFIG_PREEMPTION is selected by CONFIG_PREEMPT and by CONFIG_PREEMPT_RT.
Both PREEMPT and PREEMPT_RT require the same functionality which today
depends on CONFIG_PREEMPT.
Switch the entry code over to use CONFIG_PREEMPTION. Add PREEMPT_RT
output in __die().
Cc: Benjamin H
On Thu, Oct 24, 2019 at 7:13 PM Michal Simek wrote:
>
> msi.h is generic for all architectures expect of x86 which has own version.
Maybe a typo? "except"
Anyway, the code looks good to me.
Reviewed-by: Masahiro Yamada
> Enabling MSI by including msi.h to architecture Kbuild is just additi
Hi Christophe,
Sorry, I didn't have time to look at your other series yet and
likely the same for this one with the upcoming KVM Forum... :-\
Anyway, for any VFIO related patch, don't forget to Cc the
maintainer, Alex Williamson .
Cheers,
--
Greg
On Thu, 24 Oct 2019 15:28:03 +0200
christophe l
From: Thomas Gleixner
CONFIG_PREEMPTION is selected by CONFIG_PREEMPT and by CONFIG_PREEMPT_RT.
Both PREEMPT and PREEMPT_RT require the same functionality which today
depends on CONFIG_PREEMPT.
Switch the entry code over to use CONFIG_PREEMPTION.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
> On Oct 24, 2019, at 10:50 AM, Anshuman Khandual
> wrote:
>
> Changes in V7:
>
> - Memory allocation and free routines for mapped pages have been droped
> - Mapped pfns are derived from standard kernel text symbol per Matthew
> - Moved debug_vm_pgtaable() after page_alloc_init_late() per Mi
On 10/24/19 6:13 AM, Michal Simek wrote:
> Hi,
>
> these two patches come from discussion with Christoph, Bjorn, Palmer and
> Waiman. The first patch was suggestion by Christoph here
> https://lore.kernel.org/linux-riscv/20191008154604.ga7...@infradead.org/
> The second part was discussed
> https:/
This is a yet another approach to fix an old [1-2] concurrency issue, when:
- two or more devices are being hot-added into a bridge which was
initially empty;
- a bridge with two or more devices is being hot-added;
- during boot, if BIOS/bootloader/firmware doesn't pre-enable bridges.
The pr
The PCI_COMMAND_IO and PCI_COMMAND_MEMORY bits of the bridge must be
updated not only when enabling the bridge for the first time, but also if a
hotplugged device requests these types of resources.
Originally these bits were set by the pci_enable_device_flags() only, which
exits early if the bridg
When hot-adding a device, the bridge may have windows not big enough (or
fragmented too much) for newly requested BARs to fit in. And expanding
these bridge windows may be impossible because blocked by "neighboring"
BARs and bridge windows.
Still, it may be possible to allocate a memory region for
Currently PCI hotplug works on top of resources, which are usually reserved
not by the kernel, but by BIOS, bootloader, firmware, etc. These resources
are gaps in the address space where BARs of new devices may fit, and extra
bus number per port, so bridges can be hot-added. This series aim the
for
If release the bridge resources with standard release_child_resources(), it
drops the .start field of children's BARs to zero, but with the STARTALIGN
flag remaining set, which makes the resource invalid for reassignment.
Some resources must preserve their offset and size: those marked with the
PC
On a hotplug event with enabled BAR movement, calculating the new bridge
windows takes some time. During this procedure, the structures that
represent these windows are released - marked for recalculation.
When new bridge windows are ready, they are written to the registers of
every bridge via pci
When a bridge window is temporarily released during the rescan, its old
size is not relevant anymore - it will be recreated from pbus_size_*(), so
it's start value should be zero.
If such window can't be reassigned, don't apply reset_resource(), so the
next retry may succeed.
Signed-off-by: Serge
When movable BARs are enabled, the PCI subsystem at first releases all the
bridge windows and then attempts to assign resources both to previously
working devices and to the newly hotplugged ones, with the same priority.
If a hotplugged device gets its BARs first, this may lead to lack of space
fo
When the movable BARs feature is enabled and a rescan has been requested,
release all the bridge windows and recalculate them from scratch, taking
into account all kinds for BARs: fixed, immovable, movable, new.
This increases the chances to find a memory space to fit BARs for newly
hotplugged dev
The only difference between the fixed/immovable and movable BARs is a size
and offset preservation after they are released (the corresponding struct
resource* detached from a bridge window for a while during a bus rescan).
Include fixed/immovable BARs into result of pbus_size_mem() and prohibit
as
When movable BARs are enabled, the feature of resource relocating from
commit 2bbc6942273b5 ("PCI : ability to relocate assigned pci-resources")
is not used. Instead, inability to assign a resource is used as a signal
to retry BAR assignment with other configuration of bridge windows.
Signed-off-b
With enabled BAR movement, BARs and bridge windows can only be assigned to
their direct parents, so there can be only one variant of resource tree,
thus every retry within the pci_assign_unassigned_root_bus_resources() will
result in the same tree, and it is enough to try just once.
In case of fai
When movable BARs are enabled, and if a bridge contains a device with fixed
(IORESOURCE_PCI_FIXED) or immovable BARs, the corresponing windows can't be
moved too far away from their original positions - they must still contain
all the fixed/immovable BARs, like that:
1) Window position before a
With enabled movable BARs, bridge windows are recalculated during each pci
rescan. Some of the BARs below the bridge may be fixed/immovable: these
areas are represented by the .immovable_range field in struct pci_bus.
If a bridge window size is equal to its immovable range, it can only be
assigned
Allow matching IORESOURCE_PCI_FIXED prefetchable BARs to non-prefetchable
windows, so they follow the same rules as immovable BARs.
Signed-off-by: Sergey Miroshnichenko
---
drivers/pci/setup-bus.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/setup
A hotplugged bridge with many hotplug-capable ports may request
reserving more IO space than the machine has. This could be overridden
with the "hpiosize=" kernel argument though.
But when BARs are movable, there are no need to reserve space anymore:
new BARs are allocated not from reserved gaps,
Assure that MPS settings are set up for bridges which are discovered during
manually triggered rescan via sysfs. This sequence of bridge init (using
pci_rescan_bus()) will be used for pciehp hot-add events when BARs are
movable.
Signed-off-by: Sergey Miroshnichenko
---
drivers/pci/probe.c | 5 ++
BAR allocation by BIOS/UEFI/bootloader/firmware may be non-optimal and
it may even clash with the kernel's BAR assignment algorithm.
For example, if no space was reserved for SR-IOV BARs, and this bridge
window is packed between immovable BARs (so it is unable to extend),
and if this window can't
Reassign resources during rescan in two steps: first the fixed/immovable
BARs and bridge windows that have fixed areas, so the movable ones will not
steal these reserved areas; then the rest - so the movable BARs will divide
the rest of the space.
With this change, pci_assign_resource() is now abl
When the time comes to select a start address for the bridge window during
the root bus rescan, it should be not just a lowest possible address: this
window must cover all the underlying fixed and immovable BARs. The lowest
address that satisfies this requirement is the .realloc_range field of
stru
Add a check for the UNSET resource flag to skip the released BARs
CC: Alexey Kardashevskiy
CC: Oliver O'Halloran
CC: Sam Bobroff
Signed-off-by: Sergey Miroshnichenko
---
arch/powerpc/platforms/powernv/pci-ioda.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerp
To fetch an updated DT for the newly hotplugged device, OS must explicitly
request it from the firmware via the pnv_php driver.
If pnv_php wasn't triggered/loaded, it is still possible to discover new
devices if PCIe I/O will not stop in absence of the pci_dn structure.
Reviewed-by: Oliver O'Hall
If a struct pci_dn hasn't yet been created for the PCIe device (there was
no DT node for it), allocate this structure and fill with info read from
the device directly.
CC: Oliver O'Halloran
CC: Sam Bobroff
Signed-off-by: Sergey Miroshnichenko
---
arch/powerpc/kernel/pci_dn.c | 88 +
Reading an empty slot returns all ones, which triggers a false EEH
error event on PowerNV. A rescan is performed after all the PEs have
been unmapped, so the reserved PE index is used for unfreezing.
CC: Oliver O'Halloran
CC: Sam Bobroff
Signed-off-by: Sergey Miroshnichenko
---
arch/powerpc/pl
Add pcibios_root_bus_rescan_prepare()/_done() hooks for the powerpc, so it
can reassign the PE numbers (which depend on BAR sizes and locations) and
update the EEH address cache during a PCI rescan.
New PE numbers are assigned during pci_setup_bridges(root) after the rescan
is done.
CC: Oliver O'
When the Movable BARs feature is supported, the PCI subsystem is able to
distribute existing BARs and allocate the new ones itself, without need to
reserve gaps by BIOS.
CC: Rafael J. Wysocki
Signed-off-by: Sergey Miroshnichenko
---
drivers/pnp/system.c | 4
1 file changed, 4 insertions(+)
This is the last patch in the series which implements the essentials of the
Movable BARs feature, so it is turned by default now. Tested on:
- x86_64 with "pci=realloc,pcie_bus_peer2peer" command line argument;
- POWER8 PowerNV+PHB3 ppc64le with "pci=realloc,pcie_bus_peer2peer".
In case of prob
Switch's BARs are not used by the portdrv driver, but they are still
considered as immovable until the .rescan_prepare() and .rescan_done()
hooks are added. Add these hooks to increase chances to allocate new BARs.
Signed-off-by: Sergey Miroshnichenko
---
drivers/pci/pcie/portdrv_pci.c | 11
Hotplugged devices can affect the existing ones by moving their BARs. The
PCI subsystem will inform the NVME driver about this by invoking the
.rescan_prepare() and .rescan_done() hooks, so the BARs can by re-mapped.
Tested under the "randrw" mode of the fio tool. Before the hotplugging:
% sudo
This reverts commit db2173198b9513f7add8009f225afa1f1c79bcc6.
The root cause of this bug is fixed by the following two commits:
1. "PCI: Fix race condition in pci_enable/disable_device()"
2. "PCI: Enable bridge's I/O and MEM access for hotplugged devices"
The x86 is also affected by this bug
With movable BARs, adding a hotplugged device is not local to its bridge
anymore, but it affects the whole domain: BARs, bridge windows and bus
numbers can be substantially rearranged. So instead of trying to fit the
new devices into preallocated reserved gaps, initiate a full domain rescan.
The p
To allow hotplugging bridges, the kernel or BIOS/bootloader/firmware add
extra bus numbers per slot, but this range may be not enough for a large
bridge and/or nested bridges when hot-adding a chassis full of devices.
This patchset proposes an approach similar to movable BARs: bus numbers are
not
After hotplugging a bridge the PCI topology will be changed: buses may have
their numbers changed. In this case all the affected sysfs entries/symlinks
must be recreated, because they have BDF address in their names.
Set the freed pointers to NULL, so the !NULL checks will be satisfied when
its ti
A PCI device may be detached from /proc/bus/pci/devices not only when it is
removed, but also when its bus had changed the number - in this case the
proc entry must be recreated to reflect the new PCI topology.
Nullify freed pointers to mark them as valid for allocating again.
Signed-off-by: Serg
Move the bus_add_device() to a public API, so it can be applied to devices
which are temporarily detached from their buses without being destroyed.
This will be used after changes in PCI topology after hotplugging a bridge:
buses may get their numbers changed, so their child devices must be
reatta
When updating the /sys/devices/pci* entries affected by changes in the PCI
topology, their symlinks in /sys/bus/pci/devices/* must also be rebuilt.
Moving device_add_class_symlinks() and device_remove_class_symlinks() to a
public API allows the PCI subsystem to update the sysfs without destroying
Currently the last possible bus number of the PHB is set to the last
used bus number during the boot. So when hotplugging a bridge later,
no new buses can be allocated because they are limited by this value.
Let the host bridge contain any number of buses up to 255.
Signed-off-by: Sergey Miroshni
Add bus_disconnect_device(), which is similar to bus_remove_device(), but
it doesn't detach the device from its driver, so it can be reconnected to
the same or another bus later.
This is a yet another preparation to hotplugging large PCIe bridges, which
may entail changes in BDF addresses of worki
When hotplugging a bridge, the parent bus may not have [enough] reserved
bus numbers. So before rescanning the bus, set its subordinate number to
the maximum possible value: it is 255 when there is only one root bridge
in the domain.
During the PCI rescan, the subordinate bus number of every bus w
If the firmware indicates support of reassigning bus numbers via the PHB's
"ibm,supported-movable-bdfs" property in DT, PowerNV will not depend on PCI
topology info from DT anymore.
This makes possible to re-enumerate the fabric, assign the new bus numbers
and switch from the pnv_php module to the
Currently, hot-adding a bridge requires enough bus numbers to be reserved
on the slot. Choosing a favorable number of reserved buses per slot is
relatively simple for predictable cases, but it gets trickier when bridges
can be hot-plugged into hot-plugged bridges: there may be either not enough
bus
Changing the number of a bus (therefore changing addresses of this bus, of
its children and all the buses next in the tree) invalidates entries in
/sys/devices/pci*, /proc/bus/pci/* and symlinks in /sys/bus/pci/devices/*
for all the renamed devices and buses.
Remove the affected proc and sysfs ent
If bus numbers are distributed sparsely and there are lot of devices in the
tree, hotplugging a bridge into the end of the tree may fail even if it has
less slots then the total number of unused bus numbers.
Thus, the feature of bus renaming relies on the continuity of bus numbers,
so if a bridge
On Thu, Oct 24, 2019 at 11:47:30AM +1100, Michael Ellerman wrote:
> Some of our scripts are passed $objdump and then call it as
> "$objdump". This doesn't work if it contains spaces because we're
> using ccache, for example you get errors such as:
>
> ./arch/powerpc/tools/relocs_check.sh: line 4
On Thu, Oct 24, 2019 at 12:31:24PM +1100, Alexey Kardashevskiy wrote:
>
>
> On 23/10/2019 22:21, Segher Boessenkool wrote:
> > On Wed, Oct 23, 2019 at 12:36:35PM +1100, Oliver O'Halloran wrote:
> >> When booting under OF the zImage expects the initrd address and size to be
> >> passed to it using
On Mon, 2019-10-21 at 11:49 +0800, Ran Wang wrote:
> By default, QorIQ SoC's RCPM register block is Big Endian. But
> there are some exceptions, such as LS1088A and LS2088A, are
> Little Endian. So add this optional property to help identify
> them.
>
> Actually LS2021A and other Layerscapes won't
This is the result of a recent discussion with Michal ([1], [2]). Right
now we set all pages PG_reserved when initializing hotplugged memmaps. This
includes ZONE_DEVICE memory. In case of system memory, PG_reserved is
cleared again when onlining the memory, in case of ZONE_DEVICE memory
never.
In
Our onlining/offlining code is unnecessarily complicated. Only memory
blocks added during boot can have holes (a range that is not
IORESOURCE_SYSTEM_RAM). Hotplugged memory never has holes (e.g., see
add_memory_resource()). All boot memory is alread online.
Therefore, when we stop allowing to offl
Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.
KVM has this weird use case that you can map anything from /dev/mem
into the guest. pfn_valid() is not a reliable check whether the memmap
was initialized and can be touched. pfn_to_online_page() makes sure
that we ha
On 10/23/19 8:47 PM, Nayna Jain wrote:
Hi Nayna,
+void process_buffer_measurement(const void *buf, int size,
+ const char *eventname, enum ima_hooks func,
+ int pcr)
{
int ret = 0;
struct ima_template_entry *entry = N
On 10/23/2019 8:47 PM, Nayna Jain wrote:
This patch defines a function to detect the secure boot state of a
PowerNV system.
+bool is_ppc_secureboot_enabled(void)
+{
+ struct device_node *node;
+ bool enabled = false;
+
+ node = of_find_compatible_node(NULL, NULL, "ibm,secvar-
On 10/23/2019 8:47 PM, Nayna Jain wrote:
+/*
+ * The "secure_rules" are enabled only on "secureboot" enabled systems.
+ * These rules verify the file signatures against known good values.
+ * The "appraise_type=imasig|modsig" option allows the known good signature
+ * to be stored as an xattr or
On 10/23/2019 8:47 PM, Nayna Jain wrote:
+bool is_ppc_trustedboot_enabled(void)
+{
+ struct device_node *node;
+ bool enabled = false;
+
+ node = get_ppc_fw_sb_node();
+ enabled = of_property_read_bool(node, "trusted-enabled");
Can get_ppc_fw_sb_node return NULL?
Would
On 10/23/2019 8:47 PM, Nayna Jain wrote:
+/*
+ * The "secure_and_trusted_rules" contains rules for both the secure boot and
+ * trusted boot. The "template=ima-modsig" option includes the appended
+ * signature, when available, in the IMA measurement list.
+ */
+static const char *const secure_a
Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.
KVM has this weird use case that you can map anything from /dev/mem
into the guest. pfn_valid() is not a reliable check whether the memmap
was initialized and can be touched. pfn_to_online_page() makes sure
that we ha
Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.
KVM has this weird use case that you can map anything from /dev/mem
into the guest. pfn_valid() is not a reliable check whether the memmap
was initialized and can be touched. pfn_to_online_page() makes sure
that we ha
Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.
KVM has this weird use case that you can map anything from /dev/mem
into the guest. pfn_valid() is not a reliable check whether the memmap
was initialized and can be touched. pfn_to_online_page() makes sure
that we ha
Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.
Rewrite hash_page_do_lazy_icache() to make sure the function produces the
same result once we stop setting ZONE_DEVICE pages PG_reserved.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: "Ane
Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.
Rewrite maybe_pte_to_page() to make sure the function produces the
same result once we stop setting ZONE_DEVICE pages PG_reserved.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Christophe
Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.
Rewrite __ioremap_check_ram() to make sure the function produces the
same result once we stop setting ZONE_DEVICE pages PG_reserved.
Cc: Dave Hansen
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc:
Everything should be prepared to stop setting pages PG_reserved when
initializing the memmap on memory hotplug. Most importantly, we
stop marking ZONE_DEVICE pages PG_reserved.
a) We made sure that any code that relied on PG_reserved to detect
ZONE_DEVICE memory will no longer rely on PG_reserv
ZONE_DEVICE (a.k.a. device memory) is no longer marked PG_reserved. Update
the comment.
While at it, make it match what the code is acutally doing (reject vs.
accept).
Cc: Kees Cook
Cc: Andrew Morton
Cc: "Isaac J. Manjarres"
Cc: "Matthew Wilcox (Oracle)"
Cc: Qian Cai
Cc: Thomas Gleixner
Sig
On 23.10.19 09:26, David Hildenbrand wrote:
On 22.10.19 23:54, Dan Williams wrote:
Hi David,
Thanks for tackling this!
Thanks for having a look :)
[...]
I am probably a little bit too careful (but I don't want to break things).
In most places (besides KVM and vfio that are nuts), the
pfn_
On Thu, 24 Oct 2019, Michal Simek wrote:
> msi.h is generic for all architectures expect of x86 which has own version.
> Enabling MSI by including msi.h to architecture Kbuild is just additional
> step which doesn't need to be done.
> The patch was created based on request to enable MSI for Microb
On 10/23/2019 8:47 PM, Nayna Jain wrote:
+/*
+ * ima_check_blacklist - determine if the binary is blacklisted.
+ *
+ * Add the hash of the blacklisted binary to the measurement list, based
+ * on policy.
+ *
+ * Returns -EPERM if the hash is blacklisted.
+ */
+int ima_check_blacklist(struct inte
On Tue, Oct 22, 2019 at 9:54 PM Qiang Zhao wrote:
>
> On 22/10/2019 18:18, Rasmus Villemoes wrote:
> > -Original Message-
> > From: Rasmus Villemoes
> > Sent: 2019年10月22日 18:18
> > To: Qiang Zhao ; Leo Li
> > Cc: Timur Tabi ; Greg Kroah-Hartman
> > ; linux-ker...@vger.kernel.org;
> > li
On 25/10/2019 04:45, Segher Boessenkool wrote:
> On Thu, Oct 24, 2019 at 12:31:24PM +1100, Alexey Kardashevskiy wrote:
>>
>>
>> On 23/10/2019 22:21, Segher Boessenkool wrote:
>>> On Wed, Oct 23, 2019 at 12:36:35PM +1100, Oliver O'Halloran wrote:
When booting under OF the zImage expects the
In order to verify the OS kernel on PowerNV systems, secure boot requires
X.509 certificates trusted by the platform. These are stored in secure
variables controlled by OPAL, called OPAL secure variables. In order to
enable users to manage the keys, the secure variables need to be exposed
to usersp
The X.509 certificates trusted by the platform and required to secure boot
the OS kernel are wrapped in secure variables, which are controlled by
OPAL.
This patch adds firmware/kernel interface to read and write OPAL secure
variables based on the unique key.
This support can be enabled using CONF
PowerNV secure variables, which store the keys used for OS kernel
verification, are managed by the firmware. These secure variables need to
be accessed by the userspace for addition/deletion of the certificates.
This patch adds the sysfs interface to expose secure variables for PowerNV
secureboot.
The handlers to add the keys to the .platform keyring and blacklisted
hashes to the .blacklist keyring is common for both the uefi and powerpc
mechanisms of loading the keys/hashes from the firmware.
This patch moves the common code from load_uefi.c to keyring_handler.c
Signed-off-by: Nayna Jain
The keys used to verify the Host OS kernel are managed by firmware as
secure variables. This patch loads the verification keys into the .platform
keyring and revocation hashes into .blacklist keyring. This enables
verification and loading of the kernels signed by the boot time keys which
are truste
1 - 100 of 123 matches
Mail list logo
