On 11/15/2013 09:33 AM, Yinghai Lu wrote: > > If the system support intel IOMMU, we only need to that 72M for SWIOTLB > or AMD workaround. > If the user really care that for intel iommu enable system, they could use > "crashkernel=0,low" to have that 72M back. > > and that 72M is under 4G instead of 896M. > > so reserve 72M is not better than reserve 128M? > Those 72M are in addition to 128M, which does add up quite a bit. However, the presence of a working IOMMU in the system is something that should be possible to know at setup time. Now, this was discussed partly in the context of VMs. I want to say, as I have again and again: the right way to dump a VM is with hypervisor assistance rather than an in-image dumper which is both expensive and may be corrupted by the failure. It would be good if the various VMs with interest in Linux would agree on a mechanism for launching a dumper. This can be done either inband (on the execution of a specific hypercall, the hypervisor terminates I/O to the guest, inserts a dumper into the address space and launches it) or out-of-band (the hypervisor itself, or an assistant program, writes a dump file) or as a hybrid (a new dump guest is launched with the hypervisor-written or hypervisor-preserved crashed guest image somehow passed to it.) -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
