On 30/08/2023 2:41 pm, Jan Beulich wrote:
> On 24.08.2023 17:25, Jinoh Kang wrote:
>> Prepare for an upcoming patch that overloads the 'cr2' field for #DB.
> Seeing the subsequent change and the fact that earlier on Andrew didn't
> need such an adjustment, I'm afraid I can't see the need for this change,
> and the one sentence above also doesn't answer the "Why?", but only the
> "What?"
I agree WRT the commit message.
I don't see why, but I also didn't spot this specific bug so I can't
rule out a bug in my original series.
That said, my original series was RFC because of the Monitor breakage
and didn't get much testing.
>
> Jan
>
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -503,9 +503,14 @@ void hvm_migrate_pirqs(struct vcpu *v)
>>
>> static bool hvm_get_pending_event(struct vcpu *v, struct x86_event *info)
>> {
>> - info->cr2 = v->arch.hvm.guest_cr[2];
>> + if ( !alternative_call(hvm_funcs.get_pending_event, v, info) )
>> + return false;
>> +
>> + if ( info->type == X86_EVENTTYPE_HW_EXCEPTION &&
>> + info->vector == X86_EXC_PF )
>> + info->cr2 = v->arch.hvm.guest_cr[2];
For the change itself, this needs pushing down into the vmx/svm hooks,
because guest_cr[2] has different liveness between Intel and AMD, and
this callpath needs to work for both scheduled-in and scheduled-out guests.
On AMD, I think you need to pull it straight out of the VMCB, rather
than relying on this being correct for a scheduled-in guest.
~Andrew
