Hi, Gerd
> > +MmioExit (
> > + IN OUT EFI_SYSTEM_CONTEXT_X64 *Regs,
> > + IN TDCALL_VEINFO_RETURN_DATA *Veinfo
> > + )
> > +{
>
> > + do {
> > + OpCode = *Rip++;
> > + if (OpCode == 0x66) {
> > + OpSize = 2;
>
> Oh, wow. So the VE exit data doesn't provide the information which io/mmio
> access actually triggered the exception, so you have to go decode the
> instruction which trapped?
The VE exit data provides the information of ExitReason
(ReturnData.VeInfo.ExitReason). Based upon the ExitReason, #Ve handler knows
about which operation triggers this #Ve (EPT_VIOLATION maps to Mmio).
SystemContext.SystemContextX64 and ReturnData.VeInfo are then passed to
MmioExit as the input parameters. They have the information with which MmioExit
can emulates the MMIO instruction and then converts them to a controlled
TdVmCall(TDVMCALL_MMIO).
Actually this way of handling is similar to AMD SEV. SEV has a common function
(InitInstructionData) to initialize a data structure (InstructionData) with
Regs->Rip. In its MmioExit the instruction are decoded as well.
>
> > + switch (ReturnData.VeInfo.ExitReason) {
> > + case EXIT_REASON_CPUID:
> > + Status = CpuIdExit (Regs, &ReturnData.VeInfo);
>
> Indention is strange (switch + case should be the same).
> Otherwise looks sane to me.
Sure, this will be fixed in the next version.
Thanks
Min
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#83541): https://edk2.groups.io/g/devel/message/83541
Mute This Topic: https://groups.io/mt/86739958/21656
Mute #ve:https://edk2.groups.io/g/devel/mutehashtag/ve
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
