On Wed, Dec 16, 2020, Peter Gonda wrote: > > The IN and OUT immediate instructions only use an 8-bit immediate. The > current VC handler uses the entire 32-bit immediate value. These > instructions only set the first bytes. > > Tested with a loop back port with "outb %0,$0xe0". Before the port seen > by KVM was 0xffffffffffffffe0 instead of 0xe0. After the correct port > was seen by KVM and the guests loop back OUT then IN were equal. > > > Signed-off-by: Peter Gonda <pgo...@google.com> > Acked-by: David Rientjes <rient...@google.com> > > > --- > arch/x86/kernel/sev-es-shared.c | 8 ++++++-- > drivers/Makefile | 1 + > 2 files changed, 7 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/kernel/sev-es-shared.c b/arch/x86/kernel/sev-es-shared.c > index 7d04b356d44d..6c790377c55c 100644 > --- a/arch/x86/kernel/sev-es-shared.c > +++ b/arch/x86/kernel/sev-es-shared.c > @@ -305,14 +305,14 @@ static enum es_result vc_ioio_exitinfo(struct > es_em_ctxt *ctxt, u64 *exitinfo) > case 0xe4: > case 0xe5: > *exitinfo |= IOIO_TYPE_IN; > - *exitinfo |= (u64)insn->immediate.value << 16; > + *exitinfo |= insn->immediate.bytes[0] << 16;
Can't we just drop the explicit cast to u64? Or explicitly cast to u8? Doesn't really matter, but poking into the backing bytes feels a bit backwards. > break; > > /* OUT immediate opcodes */ > case 0xe6: > case 0xe7: > *exitinfo |= IOIO_TYPE_OUT; > - *exitinfo |= (u64)insn->immediate.value << 16; > + *exitinfo |= insn->immediate.bytes[0] << 16; > break;
