Hi,
[snip]
> 2) Reuse the SWIOTLB from the previous boot on kexec/kdump
We should only care about kdump
>
> I see little direct relation to SEV here. The only reason SEV makes it more
> relevant, is that you need to have an SWIOTLB region available with SEV
> while without you could live with
On 03/30/20 at 09:40am, Konrad Rzeszutek Wilk wrote:
> On Mon, Mar 30, 2020 at 02:06:01PM +0800, Kairui Song wrote:
> > On Sat, Mar 28, 2020 at 7:57 PM Dave Young wrote:
> > >
> > > On 03/26/20 at 05:29pm, Alexander Graf wrote:
> > > > The swiotlb
On 03/26/20 at 05:29pm, Alexander Graf wrote:
> The swiotlb is a very convenient fallback mechanism for bounce buffering of
> DMAable data. It is usually used for the compatibility case where devices
> can only DMA to a "low region".
>
> However, in some scenarios this "low region" may be bound
On 08/13/19 at 10:46am, Dave Young wrote:
> Add more cc.
> On 08/13/19 at 10:43am, Dave Young wrote:
> > Hi,
> >
> > On 08/12/19 at 11:50am, Michal Hocko wrote:
> > > On Mon 12-08-19 11:42:33, Paul Menzel wrote:
> > > > Dear Linux folks,
> &
Add more cc.
On 08/13/19 at 10:43am, Dave Young wrote:
> Hi,
>
> On 08/12/19 at 11:50am, Michal Hocko wrote:
> > On Mon 12-08-19 11:42:33, Paul Menzel wrote:
> > > Dear Linux folks,
> > >
> > >
> > > On a Dell PowerEdge R7425 with two A
Hi,
On 08/12/19 at 11:50am, Michal Hocko wrote:
> On Mon 12-08-19 11:42:33, Paul Menzel wrote:
> > Dear Linux folks,
> >
> >
> > On a Dell PowerEdge R7425 with two AMD EPYC 7601 (total 128 threads) and
> > 1 TB RAM, the crash kernel with 256 MB of space reserved crashes.
> >
> > Please find
Hi Pingfan,
Thanks for the effort,
On 03/01/19 at 11:19am, Pingfan Liu wrote:
> On Fri, Mar 1, 2019 at 11:04 AM Pingfan Liu wrote:
> >
> > Hi Borislav,
> >
> > Do you think the following patch is good at present?
> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > index
On 02/25/19 at 12:00pm, Joerg Roedel wrote:
> On Fri, Feb 22, 2019 at 02:00:26PM +0100, Borislav Petkov wrote:
> > On Fri, Feb 22, 2019 at 09:42:41AM +0100, Joerg Roedel wrote:
> > > The current default of 256MB was found by experiments on a bigger
> > > number of machines, to create a reasonable
On 02/24/19 at 09:25pm, Pingfan Liu wrote:
> On Fri, Feb 22, 2019 at 9:00 PM Borislav Petkov wrote:
> >
> > On Fri, Feb 22, 2019 at 09:42:41AM +0100, Joerg Roedel wrote:
> > > The current default of 256MB was found by experiments on a bigger
> > > number of machines, to create a reasonable
On 02/21/19 at 06:13pm, Borislav Petkov wrote:
> On Wed, Feb 20, 2019 at 05:41:46PM +0800, Dave Young wrote:
> > Previously Joerg posted below patch, maybe he has some idea. Joerg?
>
> Isn't it clear from the commit message?
Then, does it answered your question?
256M is set as
On 02/20/19 at 09:32am, Borislav Petkov wrote:
> On Mon, Feb 18, 2019 at 09:48:20AM +0800, Dave Young wrote:
> > It is ideal if kernel can do it automatically, but I'm not sure if
> > kernel can predict the swiotlb reserved size automatically.
>
> Do you see how even
On 02/15/19 at 11:24am, Borislav Petkov wrote:
> On Tue, Feb 12, 2019 at 04:48:16AM +0800, Dave Young wrote:
> > Even we make it automatic in kernel, but we have to have some default
> > value for swiotlb in case crashkernel can not find a free region under 4G.
> > So t
[snip]
>
> As previously mentioned, there are also many differences between kexec and
> kdump. In general,
> kexec needs to look at all of available physical memory, but kdump doesn't
> need.
>
> For kexec, kexec-tools will read /sys/firmware/memmap and recreate the e820
> ranges for the 2nd
On 09/04/18 at 09:29am, Dave Young wrote:
> On 09/04/18 at 08:44am, Dave Young wrote:
> > On 09/03/18 at 10:06pm, lijiang wrote:
> > > 在 2018年09月03日 10:45, Dave Young 写道:
> > > > On 08/31/18 at 04:19pm, Lianbo Jiang wrote:
> > > >> For kdump kernel
On 09/04/18 at 08:44am, Dave Young wrote:
> On 09/03/18 at 10:06pm, lijiang wrote:
> > 在 2018年09月03日 10:45, Dave Young 写道:
> > > On 08/31/18 at 04:19pm, Lianbo Jiang wrote:
> > >> For kdump kernel, when SME is enabled, the acpi table and dmi table will
> > &
On 09/03/18 at 10:06pm, lijiang wrote:
> 在 2018年09月03日 10:45, Dave Young 写道:
> > On 08/31/18 at 04:19pm, Lianbo Jiang wrote:
> >> For kdump kernel, when SME is enabled, the acpi table and dmi table will
> >> need
> >> to be remapped without the memory encry
On 08/31/18 at 04:19pm, Lianbo Jiang wrote:
> For kdump kernel, when SME is enabled, the acpi table and dmi table will need
> to be remapped without the memory encryption mask. So we have to strengthen
> the logic in early_memremap_pgprot_adjust(), which makes us have an
> opportunity
> to adjust
On 07/20/18 at 01:06pm, lijiang wrote:
> 在 2018年07月14日 01:08, Borislav Petkov 写道:
> > On Mon, Jul 09, 2018 at 09:55:35PM +0800, lijiang wrote:
> >> About this issue, i want to use an example to describe it.
> >> /* drivers/iommu/amd_iommu_init.c */
> >> static u8 __iomem * __init
On 06/16/18 at 04:27pm, Lianbo Jiang wrote:
> In kdump mode, we need to dump the old memory into vmcore file,
> if SME is enabled in the first kernel, we must remap the old
> memory in encrypted manner, which will be automatically decrypted
> when we read from DRAM. It helps to parse the vmcore
Ccing Xunlei he is reading the patches see what need to be done for
kdump. There should still be several places to handle to make kdump work.
On 05/18/17 at 07:01pm, Borislav Petkov wrote:
> On Tue, Apr 18, 2017 at 04:22:12PM -0500, Tom Lendacky wrote:
> > Add sysfs support for SME so that
On 04/27/17 at 08:52am, Dave Hansen wrote:
> On 04/27/2017 12:25 AM, Dave Young wrote:
> > On 04/21/17 at 02:55pm, Dave Hansen wrote:
> >> On 04/18/2017 02:22 PM, Tom Lendacky wrote:
> >>> Add sysfs support for SME so that user-space utilities (kdump, etc.) can
&g
On 04/21/17 at 02:55pm, Dave Hansen wrote:
> On 04/18/2017 02:22 PM, Tom Lendacky wrote:
> > Add sysfs support for SME so that user-space utilities (kdump, etc.) can
> > determine if SME is active.
> >
> > A new directory will be created:
> > /sys/kernel/mm/sme/
> >
> > And two entries within
et;
> }
>
> @@ -250,13 +251,13 @@ static int __init get_setup_data_total_num(u64 pa_data,
> int *nr)
> *nr = 0;
> while (pa_data) {
> *nr += 1;
> - data = ioremap_cache(pa_data, sizeof(*data));
> + data = memremap(pa_data, sizeof(*dat
On 02/16/17 at 09:47am, Tom Lendacky wrote:
> Use memremap() to map the setup data. This simplifies the code and will
> make the appropriate decision as to whether a RAM remapping can be done
> or if a fallback to ioremap_cache() is needed (which includes checking
> PageHighMem).
>
>
On 02/16/17 at 09:45am, Tom Lendacky wrote:
[snip]
> + * This function determines if an address should be mapped encrypted.
> + * Boot setup data, EFI data and E820 areas are checked in making this
> + * determination.
> + */
> +static bool memremap_should_map_encrypted(resource_size_t phys_addr,
Add kexec list..
On 03/01/17 at 05:25pm, Dave Young wrote:
> Hi Tom,
>
> On 02/17/17 at 10:43am, Tom Lendacky wrote:
> > On 2/17/2017 9:57 AM, Konrad Rzeszutek Wilk wrote:
> > > On Thu, Feb 16, 2017 at 09:47:55AM -0600, Tom Lendacky wrote:
> > > > Provi
Hi Tom,
On 02/17/17 at 10:43am, Tom Lendacky wrote:
> On 2/17/2017 9:57 AM, Konrad Rzeszutek Wilk wrote:
> > On Thu, Feb 16, 2017 at 09:47:55AM -0600, Tom Lendacky wrote:
> > > Provide support so that kexec can be used to boot a kernel when SME is
> > > enabled.
> >
> > Is the point of kexec and
Hi,
On 05/18/15 at 06:05pm, Li, ZhenHua wrote:
Hi Joerg,
Testing from HP: passed.
Testing from He Baoquan(Redhat): passed
The problem that dmar fault came again when running v10 with latest
kernel is fixed.
And I think there is no need to update the code to a new version now.
So
On 05/13/15 at 09:47am, Li, ZhenHua wrote:
On 05/12/2015 04:37 PM, Dave Young wrote:
Seems the subject was truncated? Maybe re means root entry? Then please
fix it
On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote:
Add functions to load root entry table from old kernel, and to save updated
root
On 05/13/15 at 09:45am, Li, ZhenHua wrote:
On 05/12/2015 04:17 PM, Dave Young wrote:
On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote:
Add context entry functions needed for kdump.
+/*
+ * Fix Crashdump failure caused by leftover DMA through a hardware IOMMU
+ *
+ * Fixes the crashdump kernel
Seems the subject was truncated? Maybe re means root entry? Then please fix it
On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote:
Add functions to load root entry table from old kernel, and to save updated
root entry table.
Add two member in struct intel_iommu, to store the RTA in old kernel, and
On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote:
Add context entry functions needed for kdump.
Bill Sumner:
Original version;
Li, Zhenhua:
Changed the name of new functions, make them consistent with current
context get/set functions.
Remove the structure dve which is not
On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote:
Add some functions to copy the data from old kernel.
These functions are used to copy context tables and page tables.
To avoid calling iounmap between spin_lock_irqsave and spin_unlock_irqrestore,
use a link here, store the pointers , and then use
The patch subject is bad, previous patch you use Items for kdump, this
patch you use datatypes and functions used for kdump then what's the
difference between these two patches?
Please think about a better one for these patches..
On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote:
Populate it with
On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote:
Modify the operation of the following functions when called during crash dump:
iommu_context_addr
free_context_table
get_domain_for_dev
init_dmars
intel_iommu_init
Bill Sumner:
Original version.
Zhenhua:
The name
On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote:
This patchset is an update of Bill Sumner's patchset, implements a fix for:
If a kernel boots with intel_iommu=on on a system that supports intel vt-d,
when a panic happens, the kdump kernel will boot with these faults:
dmar: DRHD: handling
On 05/11/15 at 12:11pm, Joerg Roedel wrote:
On Thu, May 07, 2015 at 09:56:00PM +0800, Dave Young wrote:
Joreg, I can not find the last reply from you, so just reply here about
my worries here.
I said that the patchset will cause more problems, let me explain about
it more here
On 04/07/15 at 10:12am, Don Dutile wrote:
On 04/06/2015 11:46 PM, Dave Young wrote:
On 04/05/15 at 09:54am, Baoquan He wrote:
On 04/03/15 at 05:21pm, Dave Young wrote:
On 04/03/15 at 05:01pm, Li, ZhenHua wrote:
Hi Dave,
There may be some possibilities that the old iommu data is corrupted
On 05/06/15 at 10:16am, Joerg Roedel wrote:
On Wed, May 06, 2015 at 09:46:49AM +0800, Dave Young wrote:
For the original problem, the key issue is dmar faults cause kdump kernel
hang so that vmcore can not be saved. I do not know the reason why it hangs
I think it is acceptable if kdump
On 05/04/15 at 01:05pm, Joerg Roedel wrote:
On Fri, Apr 03, 2015 at 04:40:31PM +0800, Dave Young wrote:
Have not read all the patches, but I have a question, not sure this
has been answered before. Old memory is not reliable, what if the old
memory get corrupted before panic? Is it safe
On 05/05/15 at 05:31pm, Joerg Roedel wrote:
On Tue, May 05, 2015 at 02:14:23PM +0800, Dave Young wrote:
The failure is nothing different, but as I said in another reply the
difference is we could use corrupted data to possiblly cause more failure.
I still fail to see how things can get
On 05/05/15 at 05:23pm, Joerg Roedel wrote:
On Tue, May 05, 2015 at 02:09:31PM +0800, Dave Young wrote:
I agree that we can do nothing with the old corrupted data, but I worry
about the future corruption after using the old corrupted data. I wonder
if we can mark all the oldmem as readonly
On 05/04/15 at 06:23pm, Joerg Roedel wrote:
On Fri, Apr 24, 2015 at 04:49:57PM +0800, Dave Young wrote:
I'm more than happy to see this issue can be fixed in the patchset, I
do not agree to add the code there with such problems. OTOH, for now
seems there's no way to fix it.
And that's
On 05/04/15 at 01:05pm, Joerg Roedel wrote:
On Fri, Apr 03, 2015 at 04:40:31PM +0800, Dave Young wrote:
Have not read all the patches, but I have a question, not sure this
has been answered before. Old memory is not reliable, what if the old
memory get corrupted before panic? Is it safe
On 04/24/15 at 04:35pm, Baoquan He wrote:
On 04/24/15 at 04:25pm, Dave Young wrote:
Hi, Baoquan
I support this patchset.
We should not fear oldmem since reserved crashkernel region is similar.
No one can guarantee that any crazy code won't step into crashkernel
region just
to avoid the problem.
But IMHO we should avoid it or we will have problems in the future, if we
really cannot avoid it I would say switching to pci reset way is better.
Please check this and you will find the discussion.
Regards
Zhenhua
On 04/15/2015 02:48 PM, Dave Young wrote:
On 04/15/15
On 04/15/15 at 01:47pm, Li, ZhenHua wrote:
On 04/15/2015 08:57 AM, Dave Young wrote:
Again, I think it is bad to use old page table, below issues need consider:
1) make sure old page table are reliable across crash
2) do not allow writing oldmem after crash
Please correct me if I'm wrong
On 04/10/15 at 04:42pm, Li, Zhen-Hua wrote:
This patchset is an update of Bill Sumner's patchset, implements a fix for:
If a kernel boots with intel_iommu=on on a system that supports intel vt-d,
when a panic happens, the kdump kernel will boot with these faults:
dmar: DRHD: handling
On 04/07/15 at 11:46am, Dave Young wrote:
On 04/05/15 at 09:54am, Baoquan He wrote:
On 04/03/15 at 05:21pm, Dave Young wrote:
On 04/03/15 at 05:01pm, Li, ZhenHua wrote:
Hi Dave,
There may be some possibilities that the old iommu data is corrupted by
some other modules
On 04/07/15 at 05:55pm, Li, ZhenHua wrote:
On 04/07/2015 05:08 PM, Dave Young wrote:
On 04/07/15 at 11:46am, Dave Young wrote:
On 04/05/15 at 09:54am, Baoquan He wrote:
On 04/03/15 at 05:21pm, Dave Young wrote:
On 04/03/15 at 05:01pm, Li, ZhenHua wrote:
Hi Dave,
There may be some
On 04/05/15 at 09:54am, Baoquan He wrote:
On 04/03/15 at 05:21pm, Dave Young wrote:
On 04/03/15 at 05:01pm, Li, ZhenHua wrote:
Hi Dave,
There may be some possibilities that the old iommu data is corrupted by
some other modules. Currently we do not have a better solution
On 04/03/15 at 02:05pm, Li, Zhen-Hua wrote:
The hardware will do some verification, but not completely. If people think
the OS should also do this, then it should be another patchset, I think.
If there is chance to corrupt more memory I think it is not a right way.
We should think about a
of oldmem because
of using old iommu tables then it will cause more problems.
So I think the tables at least need some verifycation before being used.
Thanks
Zhenhua
On 04/03/2015 04:40 PM, Dave Young wrote:
To fix this problem, we modifies the behaviors of the intel vt-d
On 03/19/15 at 01:36pm, Li, Zhen-Hua wrote:
This patchset is an update of Bill Sumner's patchset, implements a fix for:
If a kernel boots with intel_iommu=on on a system that supports intel vt-d,
when a panic happens, the kdump kernel will boot with these faults:
dmar: DRHD: handling
On Fri, Jun 14, 2013 at 10:11 AM, Takao Indoh indou.ta...@jp.fujitsu.comwrote:
(2013/06/13 12:41), Bjorn Helgaas wrote:
On Wed, Jun 12, 2013 at 8:44 PM, Takao Indoh indou.ta...@jp.fujitsu.com
wrote:
(2013/06/12 13:45), Bjorn Helgaas wrote:
[+cc Vivek, Haren; sorry I didn't think to add
55 matches
Mail list logo
