Hi
>
> On Wed, Oct 23, 2019 at 03:29:49PM +0800, Shengjiu Wang wrote:
> > xrun may happen at the end of stream, the
> > trigger->fsl_esai_trigger_stop maybe called in the middle of
> > fsl_esai_hw_reset, this may cause esai in wrong state after stop, and
> > there may be endless xrun interrupt.
> On Oct 24, 2019, at 11:45 PM, Anshuman Khandual
> wrote:
>
> Nothing specific. But just tested this with x86 defconfig with relevant
> configs
> which are required for this test. Not sure if it involved W=1.
No, it will not. It needs to run like,
make W=1 -j 64 2>/tmp/warns
Hi
>
> On Wed, Oct 23, 2019 at 06:25:20AM +, S.j. Wang wrote:
> > > On Thu, Oct 17, 2019 at 02:21:08PM +0800, Shengjiu Wang wrote:
> > > > For P2P output, the output divider should align with the output
> > > > sample
> > >
> > > I think we should avoid "P2P" (or "M2M") keyword in the
Commit 4ac85de9977e ("ASoC: fsl: fsl_dma: remove snd_pcm_ops") removed
fsl_dma_ops but left a usage, leading to a build error for some
configs, eg. mpc85xx_defconfig:
sound/soc/fsl/fsl_dma.c: In function ‘fsl_soc_dma_probe’:
sound/soc/fsl/fsl_dma.c:905:18: error: ‘fsl_dma_ops’ undeclared
From: Alastair D'Silva
This patch allows the user to bind OpenCAPI SCM devices to the generic OCXL
driver.
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/Kconfig | 7 +++
drivers/misc/ocxl/pci.c | 3 +++
2 files changed, 10 insertions(+)
diff --git a/drivers/misc/ocxl/Kconfig
From: Alastair D'Silva
Enable OpenCAPI Storage Class Memory driver on bare metal
Signed-off-by: Alastair D'Silva
---
arch/powerpc/configs/powernv_defconfig | 4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/configs/powernv_defconfig
b/arch/powerpc/configs/powernv_defconfig
From: Alastair D'Silva
This driver exposes LPC memory on OpenCAPI SCM cards
as an NVDIMM, allowing the existing nvram infrastructure
to be used.
Signed-off-by: Alastair D'Silva
---
drivers/nvdimm/Kconfig | 17 +
drivers/nvdimm/Makefile|3 +
From: Alastair D'Silva
This patch retrieves the serial number of the card and makes it available
to consumers of the ocxl driver via the ocxl_fn struct.
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/config.c | 46 ++
include/misc/ocxl.h| 1
From: Alastair D'Silva
Add functions to map/unmap LPC memory
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/config.c| 4 +++
drivers/misc/ocxl/core.c | 50 +++
drivers/misc/ocxl/ocxl_internal.h | 3 ++
include/misc/ocxl.h |
From: Alastair D'Silva
Tally up the LPC memory on an OpenCAPI link & allow it to be mapped
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/core.c | 10 ++
drivers/misc/ocxl/link.c | 60 +++
drivers/misc/ocxl/ocxl_internal.h | 33
From: Alastair D'Silva
This patch adds platform support to map & release LPC memory.
Signed-off-by: Alastair D'Silva
---
arch/powerpc/include/asm/pnv-ocxl.h | 2 ++
arch/powerpc/platforms/powernv/ocxl.c | 41 +++
include/linux/memory_hotplug.h| 5
From: Alastair D'Silva
Add OPAL calls for LPC memory alloc/release
Signed-off-by: Alastair D'Silva
Acked-by: Andrew Donnellan
---
arch/powerpc/include/asm/opal-api.h| 2 ++
arch/powerpc/include/asm/opal.h| 3 +++
arch/powerpc/platforms/powernv/opal-call.c | 2 ++
3 files
From: Alastair D'Silva
These functions don't exist, so remove the prototypes for them.
Signed-off-by: Alastair D'Silva
---
drivers/nvdimm/nd-core.h | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/nvdimm/nd-core.h b/drivers/nvdimm/nd-core.h
index 25fa121104d0..9f121a6aeb02
From: Alastair D'Silva
On PowerPC, the address ranges allocated to OpenCAPI LPC memory
are allocated from firmware. These address ranges may be higher
than what older kernels permit, as we increased the maximum
permissable address in commit 4ffe713b7587
("powerpc/mm: Increase the max addressable
From: Alastair D'Silva
This series adds support for OpenCAPI SCM devices, exposing
them as nvdimms so that we can make use of the existing
infrastructure.
The first patch (in memory_hotplug) has reviews/acks, but has
not yet made it upstream.
Alastair D'Silva (10):
memory_hotplug: Add a
On 10/24/2019 10:21 PM, Qian Cai wrote:
>
>
>> 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
Hi Scott,
On Friday, October 25, 2019 02:34, Scott Wood wrote
>
> 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
On 25/10/2019 04:12, Sergey Miroshnichenko wrote:
> Add a check for the UNSET resource flag to skip the released BARs
Where/why does it crash exactly? It is not extremely clear from the code.
Thanks,
>
> CC: Alexey Kardashevskiy
> CC: Oliver O'Halloran
> CC: Sam Bobroff
> Signed-off-by:
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
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
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
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
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
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
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;
> >
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
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
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
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
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
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:
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 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:
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
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
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
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
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_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
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,
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 =
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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:
%
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
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
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
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
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
---
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
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
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
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
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
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
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
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,
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
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
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 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
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.
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
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
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
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:
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
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
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
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
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
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
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
>
> 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
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
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
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
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
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
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
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,
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
1 - 100 of 119 matches
Mail list logo
