port code?
Don't we need to solve the same kexec problem on *all* platforms with
an IOMMU, and won't they all need something like this?
And I think you're misusing VTD_PAGE_{SHIFT,MASK} when you should be
using the normal PAGE_{SHIFT,MASK}. And shouldn't physical addresses be
ph
gt;free the dmar_domain structure for this device, and generate a new one, so
>that the device can be assigned a new and empty page table.
What if there were RMRRs for this device? Don't we need to ensure that
those are present in the "new and empty page table" when we ta
On Mon, 2015-06-08 at 17:29 +0200, Joerg Roedel wrote:
> On Mon, Jun 08, 2015 at 03:26:23PM +0100, David Woodhouse wrote:
> > There are some interesting corner cases to handle here.
> >
> > Firstly, you don't seem to handle the case of extended root/context
> > tab
On Mon, 2015-06-08 at 17:21 +0200, Joerg Roedel wrote:
> Hi David,
>
> On Mon, Jun 08, 2015 at 03:15:35PM +0100, David Woodhouse wrote:
> > Surely this isn't specific to the Intel IOMMU? Shouldn't it live
> > elsewhere — either in generic IOMMU code or perhaps in
On Mon, 2015-06-08 at 18:13 +0200, Joerg Roedel wrote:
> On Mon, Jun 08, 2015 at 04:50:24PM +0100, David Woodhouse wrote:
> > On Mon, 2015-06-08 at 17:29 +0200, Joerg Roedel wrote:
> > > Hmm, I also limited this functionality to kdump kernels. Do we still
> > > need to p
On Wed, 2015-06-10 at 17:32 +0800, Li, ZhenHua wrote:
>
> Is PASID part of new specs? Is there any plan to upgrade the driver to
> support the latest vt-d specs?
Yes, and yes. I'm currently working on the latter — and the extended
page table support in 4.1 is the precursor to that work.
--
dwm
On Fri, 2015-04-10 at 16:42 +0800, 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:
But, in the gene
On Sat, 2016-01-09 at 17:21 -0800, Khem Raj wrote:
> loff_t is guarded with _GNU_SOURCE on some C library implementations
> e.g. musl since this type is not defined by POSIX. Define _GNU_SOURCE to
> include this define, it should help compiling on musl while nothing
> changes for glibc based system
From: David Woodhouse
We carefully avoid the realloc() API trap by *not* using the
'ptr = realloc(ptr, new_size)' idiom which can lead to leaks on
failure. Very commendable, even though all we're going to do is
exit() on failure so it wouldn't have mattered.
What *does* ma
From: David Woodhouse
Signed-off-by: David Woodhouse
---
kexec/kexec-uImage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kexec/kexec-uImage.c b/kexec/kexec-uImage.c
index 667cd93..49f266a 100644
--- a/kexec/kexec-uImage.c
+++ b/kexec/kexec-uImage.c
@@ -236,7 +236,7
From: David Woodhouse
Signed-off-by: David Woodhouse
---
include/image.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/image.h b/include/image.h
index e742aae..8e9d81e 100644
--- a/include/image.h
+++ b/include/image.h
@@ -79,6 +79,13 @@
#define IH_ARCH_BLACKFIN 16
From: David Woodhouse
Signed-off-by: David Woodhouse
---
kexec/arch/arm64/Makefile | 3 +++
kexec/arch/arm64/kexec-arm64.c| 1 +
kexec/arch/arm64/kexec-arm64.h| 4
kexec/arch/arm64/kexec-uImage-arm64.c | 34 ++
4 files changed
From: David Woodhouse
This was only ever used on PPC, where they are equivalent and we
never saw the resulting -Wpointer-sign warnings.
Signed-off-by: David Woodhouse
---
include/kexec-uImage.h| 4 ++--
kexec/arch/ppc/kexec-uImage-ppc.c | 2 +-
kexec/kexec-uImage.c
From: David Woodhouse
... and friends. Again, PPC never cared about the difference, while
ARM had to add an explicit cast to work around it, which we can remove
now.
Signed-off-by: David Woodhouse
---
include/kexec-uImage.h| 6 +++---
kexec/arch/arm/kexec-uImage-arm.c | 3
defined
Signed-off-by: Khem Raj
Signed-off-by: David Woodhouse
---
vmcore-dmesg/vmcore-dmesg.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/vmcore-dmesg/vmcore-dmesg.c b/vmcore-dmesg/vmcore-dmesg.c
index 0364636..a8f56df 100644
--- a/vmcore-dmesg/vmcore-dmesg.c
+++ b/vmcore-dmesg/vmcore
On Fri, 2017-03-10 at 10:12 +0100, Simon Horman wrote:
>
> For some reason it did not hit my inbox :(
>
> Shall I pick up the version you reposted as PATCH 7/7 ?
That works. There's a github PR too if that's easier to consume. Which
wasn't *intended* to include this patch as it was for the uImag
On Wed, 2017-03-15 at 18:56 +0900, AKASHI Takahiro wrote:
> This patch series adds kdump support on arm64.
>
> To load a crash-dump kernel to the systems, a series of patches to
> kexec-tools[1] are also needed. Please use the latest one, v6 [2].
> For your convinience, you can pick them up from:
On Thu, 2017-03-16 at 09:23 +0900, AKASHI Takahiro wrote:
>
> I double-checked but saw no warnings like these neither for v32 nor v33.
> I'm afraid that you might have done something wrong in backporting,
> particularly patch#5.
Then I apologise for the noise. Thanks for checking.
smime.p7s
Desc
On Wed, 2017-03-15 at 18:59 +0900, AKASHI Takahiro wrote:
>
> + pr_info("crashkernel reserved: 0x%016llx - 0x%016llx (%lld MB)\n",
> + crash_base, crash_base + crash_size, crash_size >> 20);
There's a typo there — it says MB but you mean MiB.
Unless you meant crash_size / 100
On Fri, 2017-03-17 at 20:31 +0900, AKASHI Takahiro wrote:
>
> Yes and no.
> This notation is consistent with other places like mem_init()
> in mm/init.c.]
Well, perhaps we should fix those too then. But we certainly shouldn't
add *more* errors.
smime.p7s
Description: S/MIME cryptographic signatu
On Wed, 2017-03-15 at 18:56 +0900, AKASHI Takahiro wrote:
> This patch series adds kdump support on arm64.
>
> To load a crash-dump kernel to the systems, a series of patches to
> kexec-tools[1] are also needed. Please use the latest one, v6 [2].
> For your convinience, you can pick them up from:
On Fri, 2017-03-17 at 11:43 +, David Woodhouse wrote:
>
> Is this one going to be be my fault too?
Looks like it isn't my fault. In ipi_cpu_crash_stop() we don't modify
the online mask. Which is reasonable enough if we want to preserve its
original contents from before the cr
On Tue, 2017-03-21 at 16:34 +0900, AKASHI Takahiro wrote:
> Yes, it is intentional. I removed 'offline' code in my v14 (2016/3/4).
> As you assumed, I'd expect 'online' status of all CPUs to be kept
> unchanged in the core dump.
I wonder if it would be better to take a *copy* of it and put it back
On Fri, 2017-03-17 at 15:33 +, Mark Rutland wrote:
>
> We can certainly log a better message, e.g.
>
> bool kdump = (image == kexec_crash_image);
> bool stuck_cpus = cpus_are_stuck_in_kernel() ||
> num_online_cpus() > 1;
>
> BUG_ON(st
On Fri, 2017-03-17 at 17:10 +, Marc Zyngier wrote:
>
> > > >
> > > > FWIW if I trigger a crash on CPU 1 my kdump (still 4.9.8+v32) doesn't
> > > > work.
> > > > I end up booting the kdump kernel on CPU#1 and then it gets distinctly
> > > > unhappy...
> > > >
> > > > [0.00] Booting
On Mon, 2017-04-03 at 11:24 +0900, AKASHI Takahiro wrote:
>
> +static void ipi_cpu_crash_stop(unsigned int cpu, struct pt_regs
> *regs)
> +{
> +#ifdef CONFIG_KEXEC_CORE
> + crash_save_cpu(regs, cpu);
> +
> + atomic_dec(&waiting_for_crash_ipi);
> +
> + local_irq_disable();
Should
On Tue, 2017-03-28 at 15:51 +0900, AKASHI Takahiro wrote:
>
> + if (crash_base == 0) {
> + /* Current arm64 boot protocol requires 2MB alignment */
> + crash_base = memblock_find_in_range(0, ARCH_LOW_ADDRESS_LIMIT,
> + crash_size, SZ_
> On Mon, Apr 03, 2017 at 09:18:12AM +0100, David Woodhouse wrote:
>>
>> You still have typos here.
>
> I'd like to defer to the maintainers whether we prefer MiB over MB.
It is not really a matter of preference. One is correct; the other is not.
While simple errors ca
On Tue, 2017-04-04 at 16:35 +0900, AKASHI Takahiro wrote:
>
> Because I think that people sometimes use those two interchangeably.
> So I said I would defer to the maintainers.
Sometimes they do, yes. Just as sometimes people use "their",
"they're", and "there" interchangeably.
Rarely in a profe
Less important than in user-visible messages, but still good practice as
there's still no excuse for ARM64 code to look like it was written before
1996.
Signed-off-by: David Woodhouse
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 2 +-
.../boot/dts/arm/vexpress-v2f-1xv7-ca53x
On Tue, 2017-04-04 at 10:26 +0100, Will Deacon wrote:
> A
> patch making arm64 consistent could be discussed separately, otherwise kdump
> becomes the pedantic ISO guy trying to lead by example, but really everybody
> ignores him because it's completely inconsequential and they also know he
> went
ng at the existing errors and
actually claiming that they want their *new* code to be deliberately
wrong in order to be "consistent" with what's there.
So let's fix the user-visible messages in all of arch/arm64 and nip
*that* particular stupidity in the bud...
Signed-off
ce, on arm64, we want
> to count up "System RAM" entries, but need to skip "reserved" entries.
s/exntend/extend/ and s/incovenient/inconvenient/ but other than that,
all ten patches
Tested-by: David Woodhouse
Simon, any chance of a 2.0.15 release once these are merged please
oing* DMA, seems wrong.
You'll even end up resetting devices just because they have an RMRR,
won't you? (Although I wouldn't lose any sleep over that, I suppose. In
fact it might be a *feature*... :)
--
David WoodhouseOpen Source Technology Centre
david.wood
On Tue, 2013-09-10 at 14:43 +0900, Takao Indoh wrote:
> (2013/09/09 18:07), David Woodhouse wrote:
> > If the driver is so broken that it cannot get the device working again
> > after a fault, surely the driver needs to be fixed?
>
> Yes,this problem may be solved by fi
On Tue, 2013-09-24 at 15:16 +0200, Joerg Roedel wrote:
>
> I am not convinced that this is the right approach. If a device wasn't
> translated by VT-d in the old kernel doesn't mean it will not be
> translated in the new kernel. How about unconditionally resetting all
> PCI busses and/or functions
me scratch page?
That way you avoid the faults, but you also avoid stray DMA to parts of
the system that you don't want to get corrupted.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
sm
al scratch page.
That way, we allow the "rogue" DMA to continue to the same virtual bus
addresses, but it can only ever affect one piece of physical memory and
can't have detrimental effects elsewhere.
Was that option considered and discounted for some reason? It
On Thu, 2010-07-29 at 21:41 -0700, Eric W. Biederman wrote:
> There isn't a bus master shut off at the core level.
Effectively, there is if you have an IOMMU.
--
dwmw2
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mail
On Fri, 30 Jul 2010, Vivek Goyal wrote:
On Fri, Jul 30, 2010 at 11:21:42AM -0700, Eric W. Biederman wrote:
David Woodhouse writes:
On Thu, 2010-07-29 at 21:41 -0700, Eric W. Biederman wrote:
There isn't a bus master shut off at the core level.
Effectively, there is if you have an
On Fri, 30 Jul 2010, Vivek Goyal wrote:
So what happens if we tear down the mapping while DMA is on.
The DMA gets blocked, and you don't have to worry about whether the device
was shut down cleanly or not. The device may be unhappy, but when the new
kernel's driver loads and reinitialises it
On Fri, 30 Jul 2010, Eric W. Biederman wrote:
David Woodhouse writes:
The DMA gets blocked, and you don't have to worry about whether the device was
shut down cleanly or not. The device may be unhappy, but when the new kernel's
driver loads and reinitialises it, all should b
On Fri, 2010-07-30 at 13:08 -0700, Eric W. Biederman wrote:
> The issue is what happens if you take an IOMMU page fault during
> between shutdown and restart. I seem to remember an IOMMU page fault
> triggering a machine check on AMD cpus. So maybe it works but my gut
> impression is simply leavi
On Tue, 2011-11-01 at 17:19 +0800, Dave Young wrote:
> kdump kernel sometimes will get DMAR faults which
> is caused by random in-flight dma from 1st kernel
>
> Here make the identity_mapping as default for this case
So you want to *allow* the random in-flight DMA? And with an identity
mapping it
've occasionally spoken about working around such a
problem by setting a bit to make subsequent faults *silent*. Would that
work?
> What we have to do is stopping DMA transaction
> before DMA-remapping is disabled in 2nd kernel.
The IOMMU is there to stop DMA transactions. That is its *job*. :
On Thu, 2013-04-04 at 14:48 +0900, Takao Indoh wrote:
>
> - DMAR fault messages floods and second kernel does not boot. Recently I
> saw similar report. https://lkml.org/lkml/2013/3/8/120
Right. So the fix for that is to make the subsequent errors silent,
until/unless we actually get a request
On Thu, 2018-07-05 at 11:19 +0100, Marc Zyngier wrote:
> >> The criteria is "this irqchip requires a reset to be safely used in the
> >> secondary kernel". This is a judgement call from the person writing the
> >> driver.
> >
> > This doesn't tell me anything more than "do it if you need it."
>
I've been looking at kexec into Xen, and from Xen.
Kexec-tools doesn't support Multiboot v2, and doesn't treat the Xen
image as relocatable. So it loads it at address zero, which causes lots
of amusement:
Firstly, head.S trusts the low memory limit found in the BDA, which has
been scribbled on. H
On Sat, 2019-04-27 at 08:15 +0200, David Woodhouse wrote:
> I've been looking at kexec into Xen, and from Xen.
>
> Kexec-tools doesn't support Multiboot v2, and doesn't treat the Xen
> image as relocatable. So it loads it at address zero, which causes lots
> of a
> On 27/04/2019 07:15, David Woodhouse wrote:
>> I've been looking at kexec into Xen, and from Xen.
>>
>> Kexec-tools doesn't support Multiboot v2, and doesn't treat the Xen
>> image as relocatable. So it loads it at address zero, which causes lots
>&g
From: David Woodhouse
Unlike Linux which creates a full identity mapping, Xen only maps those
segments which are explicitly requested. Therefore, xen_kexec_load()
silently adds in a segment from zero to 1MiB to ensure that VGA memory
and other things are accessible.
However, this doesn't
When I kexec either Xen or Linux in real mode, from either Xen or
Linux, it fails.
The last thing I see looks like SeaBIOS trying to use SMM for call32:
IN:
0x000f70ec: mov%eax,%esi
0x000f70ef: mov$0xb5,%eax
0x000f70f5: mov$0x1234,%ecx
0x00
On Tue, 2019-04-30 at 22:56 -0400, Kevin O'Connor wrote:
> Hi David,
>
> That call trace certainly looks odd. The SeaBIOS debugging info would
> help - try compiling SeaBIOS with debug level 8 and grab the log (as
> described at: https://www.seabios.org/Debugging#Diagnostic_information
> ).
Choo
On Tue, 2019-07-02 at 13:09 +0200, Simon Horman wrote:
> > diff --git a/include/x86/multiboot2.h b/include/x86/multiboot2.h
> > new file mode 100644
> > index 000..5693923
> > --- /dev/null
> > +++ b/include/x86/multiboot2.h
> > @@ -0,0 +1,416 @@
> > +/* multiboot2.h - Multiboot 2 header file.
On Tue, 2019-07-02 at 13:09 +0200, Simon Horman wrote:
> As per my comment on your previous posting of this patch:
>
> multiboot2.h does not appear to be licenced as GPLv2.
> This seems incompatible with inclusion in kexec-tools.
> Can we discuss this?
Ah, last time it was the documentation in mu
On Wed, 2019-07-03 at 10:00 +0200, Simon Horman wrote:
> On Tue, Jul 02, 2019 at 02:29:56PM +0100, David Woodhouse wrote:
> > On Tue, 2019-07-02 at 13:09 +0200, Simon Horman wrote:
> > > As per my comment on your previous posting of this patch:
> > >
> > >
On Thu, 2020-03-05 at 19:14 -0300, Guilherme G. Piccoli wrote:
> Hi Bhupesh, I re-tested again using 5.6-rc4 with "retain_initrd" and
> "swiotlb=noforce" and got a quite interesting discrepancy. First run got
> me 99 kexecs with no issue (the public IP of my AWS instance was
> 3.215.x.y). After thi
The machine hosting lists.infradead.org and git.infradead.org suffered
a complete disk failure over the weekend; sadly the last backup of the
mailman config was fairly old (May 2018) so the subscriber lists and
archives have been reset to that date, but the lists should be running
again.
I've recr
On Tue, 2020-11-17 at 10:53 +0100, Thomas Gleixner wrote:
> But that does not solve the problem either simply because then the IOMMU
> will catch the rogue MSIs and you get an interrupt storm on the IOMMU
> error interrupt.
Not if you can tell the IOMMU to stop reporting those errors.
We can easi
On Tue, 2023-02-14 at 02:48 +0300, Kirill A. Shutemov wrote:
> The patch brings basic enabling of kexec in TDX guests.
>
> By "basic enabling" I mean, kexec in the guests with a single CPU.
> TDX guests use ACPI MADT MPWK to bring up secondary CPUs. The mechanism
> doesn't allow to put a CPU back
On Thu, 2007-06-07 at 10:13 -0700, Geoff Levand wrote:
> 64 bit: OK
> 32 bit: purgatory build fails
Hm, what'd you do to it? Fedora is shipping this (ugly as it is) and
it's working. Well, it would if the PS3 kernel would :)
--
dwmw2
___
kexec maili
On Sat, 2010-04-03 at 19:41 +0200, Joerg Roedel wrote:
> Another problem: This also breaks if the kdump kernel has no
> iommu-support.
The kdump kernel has to support the hardware it's running on.
Film at 11.
--
David WoodhouseOpen Source Techno
62 matches
Mail list logo
