[Crash-utility] [PATCH v2 1/3] vmware_vmss: get proper ITDR

Alexey Makhalov amakhalov at vmware.com
Wed Oct 28 23:46:33 UTC 2020


Hi Daisuke,

> On Oct 28, 2020, at 3:14 AM, d.hatayama at 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20201028/328db893/attachment.sig>


More information about the Crash-utility mailing list