Hi Daisuke,
> On Oct 28, 2020, at 3:14 AM, d.hatay...@fujitsu.com wrote:
>
>> diff --git a/vmware_vmss.c b/vmware_vmss.c
>> index b168f29..8aa0de0 100644
>> --- a/vmware_vmss.c
>> +++ b/vmware_vmss.c
>> @@ -881,6 +881,27 @@ vmware_vmss_get_cr3_idtr(ulong *cr3, ulong *idtr)
>> *cr3 = vmss.regs64[0]->cr[3];
>> *idtr = vmss.regs64[0]->idtr;
>>
>> + /*
>> + * debug.guest is generated on guest triple fault. One of the
>> possible
>> + * ways to triple fault is: zeroing IDTR and int3.
>> + * This is used in linux to reboot machine using triple fault:
>> + * "reboot=t" cmdline.
>> + * In that case CPU which triggered triple fault will have zeroed
>> + * IDTR. IDTR and CR3 are used to calculate kaslr offset and phys
>> + * base.
>> + * If IDTR on CPU0 is zeroed and we have several CPUs, return IDTR
>> from
>> + * another CPU.
>> + */
>> + if (vmss.num_vcpus > 1 && *idtr == 0) {
>> + int i;
>> + for (i = 0; i < vmss.num_vcpus; i++) {
>> + if (vmss.vcpu_regs[i] == REGS_PRESENT_ALL) {
>> + *idtr = vmss.regs64[i]->idtr;
>> + break;
>> + }
>> + }
>> + }
>> +
>> return TRUE;
>> }
>
> Considering again, this is similar to the commit
> 8b50d94ada21f403665a5e562f40191f111e0313,
> but where I restricted its target only on sadump format to avoid regression
> on other
> formats. If it is needed by other formats, how about generalize it for other
> formats?
> Current code is a bit hacky but could be cleaned up by removing the
> limitation on
> sadump.
>
Sure! What was the issue with sadump?
In vmware guest dump, IDTR on one of CPUs is zeroed, if it is CPU #0 - then use
IDTR from another CPU.
I see, kaslr_helper has retry logic for sadump case. Can you provide more info
about it.
And I will try to generalize it.Thanks, —Alexey
signature.asc
Description: Message signed with OpenPGP
-- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility
