From: Mike Rapoport
Hi,
Following the discussion on [1] this is the fix for memblock freeing APIs
mismatch.
The first patch is a cleanup of numa_distance allocation in arch_numa I've
spotted during the conversion.
The second patch is a fix for Xen memory freeing on some of the error
paths.
From: Mike Rapoport
free_p2m_page() wrongly passes a virtual pointer to memblock_free() that
treats it as a physical address.
Call memblock_free_ptr() instead that gets a virtual address to free the
memory.
Signed-off-by: Mike Rapoport
---
arch/x86/xen/p2m.c | 2 +-
1 file changed, 1
From: Mike Rapoport
Memory allocation of numa_distance uses memblock_phys_alloc_range() without
actual range limits, converts the returned physical address to virtual and
then only uses the virtual address for further initialization.
Simplify this by replacing memblock_phys_alloc_range() with
Le 23/09/2021 à 09:43, Mike Rapoport a écrit :
From: Mike Rapoport
For ages memblock_free() interface dealt with physical addresses even
despite the existence of memblock_alloc_xx() functions that return a
virtual pointer.
Introduce memblock_phys_free() for freeing physical ranges and
On Thu, Sep 23, 2021 at 11:47:48AM +0200, Christophe Leroy wrote:
>
>
> Le 23/09/2021 à 09:43, Mike Rapoport a écrit :
> > From: Mike Rapoport
> >
> > For ages memblock_free() interface dealt with physical addresses even
> > despite the existence of memblock_alloc_xx() functions that return a
From: Mike Rapoport
For ages memblock_free() interface dealt with physical addresses even
despite the existence of memblock_alloc_xx() functions that return a
virtual pointer.
Introduce memblock_phys_free() for freeing physical ranges and repurpose
memblock_free() to free virtual pointers to
Hi!
Something went wrong with this series. I only see first 7 patches. I
thought it might be local problem, but I only see 7 patches on lore...
https://lore.kernel.org/lkml/20210923033839.1421034-1-sas...@kernel.org/
Best regards,
Nathan Lynch writes:
> Srikar Dronamraju writes:
>
>> * Nathan Lynch [2021-09-22 11:01:12]:
>>
>>> Srikar Dronamraju writes:
>>> > * Nathan Lynch [2021-09-20 22:12:13]:
>>> >
>>> >> vcpu_is_preempted() can be used outside of preempt-disabled critical
>>> >> sections, yielding warnings such
Srikar Dronamraju writes:
> * Michael Ellerman [2021-08-26 23:36:53]:
>
>> Srikar Dronamraju writes:
>> > Scheduler expects unique number of node distances to be available at
>> > boot.
...
>
>> > Fake the offline node's distance_lookup_table entries so that all
>> > possible node distances are
Le 23/09/2021 à 14:01, Mike Rapoport a écrit :
On Thu, Sep 23, 2021 at 11:47:48AM +0200, Christophe Leroy wrote:
Le 23/09/2021 à 09:43, Mike Rapoport a écrit :
From: Mike Rapoport
For ages memblock_free() interface dealt with physical addresses even
despite the existence of
https://bugzilla.kernel.org/show_bug.cgi?id=213837
--- Comment #8 from m...@ellerman.id.au ---
bugzilla-dae...@bugzilla.kernel.org writes:
> https://bugzilla.kernel.org/show_bug.cgi?id=213837
>
> --- Comment #7 from Erhard F. (erhar...@mailbox.org) ---
> Created attachment 298919
> -->
bugzilla-dae...@bugzilla.kernel.org writes:
> https://bugzilla.kernel.org/show_bug.cgi?id=213837
>
> --- Comment #7 from Erhard F. (erhar...@mailbox.org) ---
> Created attachment 298919
> --> https://bugzilla.kernel.org/attachment.cgi?id=298919=edit
> dmesg (5.15-rc2 + patch, PowerMac G5 11,2)
>
On 23.09.21 09:43, Mike Rapoport wrote:
From: Mike Rapoport
free_p2m_page() wrongly passes a virtual pointer to memblock_free() that
treats it as a physical address.
Call memblock_free_ptr() instead that gets a virtual address to free the
memory.
Signed-off-by: Mike Rapoport
Reviewed-by:
kvmppc_h_set_dabr(), and kvmppc_h_set_xdabr() which jumps into
it, need to use _GLOBAL_TOC to setup the kernel TOC pointer, because
kvmppc_h_set_dabr() uses LOAD_REG_ADDR() to load dawr_force_enable.
When called from hcall_try_real_mode() we have the kernel TOC in r2,
established near the start
Krzysztof Kozlowski writes:
> g5_phy_disable_cpu1() is used outside of platforms/powermac/feature.c,
> so it should have a declaration to fix W=1 warning:
>
> arch/powerpc/platforms/powermac/feature.c:1533:6:
> error: no previous prototype for ‘g5_phy_disable_cpu1’
>
On Thu, Sep 23, 2021 at 12:43 AM Mike Rapoport wrote:
>
> The core change is in the third patch that makes memblock_free() a
> counterpart of memblock_alloc() and adds memblock_phys_alloc() to be a
^^^
> counterpart of memblock_phys_alloc().
That should be 'memblock_phys_free()'
https://bugzilla.kernel.org/show_bug.cgi?id=213837
--- Comment #9 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 298933
--> https://bugzilla.kernel.org/attachment.cgi?id=298933=edit
System.map (5.15-rc2 + patch, PowerMac G5 11,2)
(In reply to mpe from comment #8)
> So it looks
On 23/09/2021 15:21, Michael Ellerman wrote:
> Krzysztof Kozlowski writes:
>> g5_phy_disable_cpu1() is used outside of platforms/powermac/feature.c,
>> so it should have a declaration to fix W=1 warning:
>>
>> arch/powerpc/platforms/powermac/feature.c:1533:6:
>> error: no previous prototype
On 13/09/21 15:57, Juergen Gross wrote:
Revert commit 76b4f357d0e7d8f6f00 which was based on wrong reasoning
and rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS in order to avoid the
same issue in future.
Juergen Gross (2):
x86/kvm: revert commit 76b4f357d0e7d8f6f00
kvm: rename KVM_MAX_VCPU_ID
On 23.09.21 09:43, Mike Rapoport wrote:
From: Mike Rapoport
For ages memblock_free() interface dealt with physical addresses even
despite the existence of memblock_alloc_xx() functions that return a
virtual pointer.
Introduce memblock_phys_free() for freeing physical ranges and repurpose
On 07.09.21 12:10, Jan Beulich wrote:
xenboot_write_console() is dealing with these quite fine so I don't see
why xenboot_console_setup() would return -ENOENT in this case.
Adjust documentation accordingly.
Signed-off-by: Jan Beulich
Reviewed-by: Juergen Gross
Juergen
On Thu, Sep 23, 2021 at 12:05:58AM +0300, Kirill A. Shutemov wrote:
> Unless we find other way to guarantee RIP-relative access, we must use
> fixup_pointer() to access any global variables.
Yah, I've asked compiler folks about any guarantees we have wrt
rip-relative addresses but it doesn't look
Changes since v1 [3]:
- get_max_afu_index() updated to new interface (Dan)
- siov_find_pci_dvsec updated to new interface (Dan)
- remove unnecessary pci request/release regions with refactor (Dan)
- move @base into cxl_register_map (Dan)
- Expanded the Cc list to include other users of PCIe DVSEC.
In preparation for passing around the Register Block Indicator (RBI) as
a parameter, it is desirable to convert the type to an enum so that the
interface can use a well defined type checked parameter.
As a result of this change, should future versions of the spec add
sparsely defined identifiers,
* Michael Ellerman [2021-09-23 21:17:25]:
> Srikar Dronamraju writes:
> > * Michael Ellerman [2021-08-26 23:36:53]:
> >
> >> Srikar Dronamraju writes:
> >> > Scheduler expects unique number of node distances to be available at
> >> > boot.
> ...
> >
> >> > Fake the offline node's
In preparation for moving parts of register mapping to cxl_core, the
cxl_pci driver is refactored to utilize a new helper to find register
blocks by type.
cxl_pci scanned through all register blocks and mapping the ones that
the driver will use. This logic is inverted so that the driver
While interesting to driver developers, the dev_dbg message doesn't do
much except clutter up logs. This information should be attainable
through sysfs, and someday lspci like utilities. This change
additionally helps reduce the LOC in a subsequent patch to refactor some
of cxl_pci register
Quoting Dan, "... the request + release regions should probably just be
dropped. It's not like any of the register enumeration would collide
with someone else who already has the registers mapped. The collision
only comes when the registers are mapped for their final usage, and that
will have more
Reduce maintenance burden of DVSEC query implementation by using the
centralized PCI core implementation.
Cc: io...@lists.linux-foundation.org
Cc: David Woodhouse
Cc: Lu Baolu
Signed-off-by: Ben Widawsky
---
drivers/iommu/intel/iommu.c | 15 +--
1 file changed, 1 insertion(+), 14
On Wed, Sep 15, 2021 at 10:59 PM Paul Moore wrote:
>
> On Mon, Sep 13, 2021 at 5:05 PM Paul Moore wrote:
> >
> > On Mon, Sep 13, 2021 at 10:02 AM Ondrej Mosnacek
> > wrote:
> > >
> > > Commit 59438b46471a ("security,lockdown,selinux: implement SELinux
> > > lockdown") added an implementation
Add pci_find_dvsec_capability to locate a Designated Vendor-Specific
Extended Capability with the specified DVSEC ID.
The Designated Vendor-Specific Extended Capability (DVSEC) allows one or
more vendor specific capabilities that aren't tied to the vendor ID of
the PCI component.
DVSEC is
The structure exists to pass around information about register mapping.
Using it more extensively cleans up many existing functions.
Signed-off-by: Ben Widawsky
---
drivers/cxl/cxl.h | 1 +
drivers/cxl/pci.c | 36 +---
2 files changed, 18 insertions(+), 19
Hi Linus,
On Thu, Sep 23, 2021 at 09:01:46AM -0700, Linus Torvalds wrote:
> On Thu, Sep 23, 2021 at 12:43 AM Mike Rapoport wrote:
> >
> You need to be a LOT more careful.
>
> From a trivial check - exactly because I looked at doing it with a
> script, and decided it's not so easy - I found
Reduce maintenance burden of DVSEC query implementation by using the
centralized PCI core implementation.
There are two obvious places to simply drop in the new core
implementation. There remains find_dvsec_from_pos() which would benefit
from using a core implementation. As that change is less
Reduce maintenance burden of DVSEC query implementation by using the
centralized PCI core implementation.
Signed-off-by: Ben Widawsky
---
drivers/cxl/pci.c | 20 +---
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git a/drivers/cxl/pci.c b/drivers/cxl/pci.c
index
On 07.09.21 12:09, Jan Beulich wrote:
The xen_hvm_early_write() path better wouldn't be taken in this case;
while port 0xE9 can be used, the hypercall path is quite a bit more
efficient. Put that first, as it may also work for DomU-s (see also
xen_raw_console_write()).
While there also bail
* Michael Ellerman [2021-09-23 17:29:32]:
> Nathan Lynch writes:
> > Srikar Dronamraju writes:
> >
> >> * Nathan Lynch [2021-09-22 11:01:12]:
> >>
> >>> Srikar Dronamraju writes:
> >>> > * Nathan Lynch [2021-09-20 22:12:13]:
> >>> >
> >>> >> vcpu_is_preempted() can be used outside of
On Thu, Sep 23, 2021 at 03:54:46PM +0200, Christophe Leroy wrote:
>
> Le 23/09/2021 à 14:01, Mike Rapoport a écrit :
> > On Thu, Sep 23, 2021 at 11:47:48AM +0200, Christophe Leroy wrote:
> > >
> > >
> > > Le 23/09/2021 à 09:43, Mike Rapoport a écrit :
> > > > From: Mike Rapoport
> > > >
> > >
Srikar Dronamraju writes:
> * Michael Ellerman [2021-09-23 17:29:32]:
>
>> Nathan Lynch writes:
>> > Srikar Dronamraju writes:
>> >
>> >> * Nathan Lynch [2021-09-22 11:01:12]:
>> >>
>> >>> Srikar Dronamraju writes:
...
>> >> Or can I understand how debug_smp_processor_id() is useful if
>> >>
On 9/23/21 9:43 AM, Mike Rapoport wrote:
> From: Mike Rapoport
>
> For ages memblock_free() interface dealt with physical addresses even
> despite the existence of memblock_alloc_xx() functions that return a
> virtual pointer.
>
> Introduce memblock_phys_free() for freeing physical ranges and
On 9/23/2021 1:26 PM, Ben Widawsky wrote:
Add pci_find_dvsec_capability to locate a Designated Vendor-Specific
Extended Capability with the specified DVSEC ID.
The Designated Vendor-Specific Extended Capability (DVSEC) allows one or
more vendor specific capabilities that aren't tied to the
On 9/22/21 7:32 AM, Nicholas Piggin wrote:
The machine check handler is not considered NMI on 64s. The early
handler is the true NMI handler, and then it schedules the
machine_check_exception handler to run when interrupts are enabled.
This works fine except the case of an unrecoverable MCE,
42 matches
Mail list logo
