Re: [RFC] KVM: x86: emulate movdqa

[Avi Kivity <avi@redhat.com>]

On 01/08/2012 06:21 PM, Stefan Hajnoczi wrote:
> On Sun, Jan 8, 2012 at 10:32 AM, Avi Kivity <avi@redhat.com> wrote:
> > On 01/07/2012 12:26 PM, Stefan Hajnoczi wrote:
> >>
> >> movdqa %xmm0,(%rdi)
> >>
> >> This patch adds movdqa to the emulator but does not implement #GP when
> >> the memory operand is unaligned to 16 bytes.  I'm not sure whether
> >> alignment checking can be implemented as an opcode .flag or if it needs
> >> to be done in em_movdqa().
> >
> > It should actually be automatic when the Sse flag is present, since it's
> > the norm for almost all SSE instructions.  There should be a .flag to
> > override it for movdqu.
>
> When writing a kvm-unit-test for movdqa I found that alignment
> checking happens before the page fault (makes sense).  That means
> misalignment is detected by the CPU while still in guest mode.  The
> emulator never sees the instruction because #GP is raised and handled
> in the guest.

Right.  The way to test this is to change the instruction while the vcpu
is processing it, see for example x86/svm.c's
corrupt_cr3_intercept_bypass().

> I also didn't see other instances of alignment checking in the
> emulator (e.g. eflags AC).  I guess the same situation applies there.

Yes.

> Can you think of a case where we need to perform alignment checking in
> the emulator?

The case that x86/svm.c is checking for is a security issue.

Guests don't normally turn eflags.AC on, so I don't expect issues
there.  I also don't see issues with SSE alignment, especially as AVX
removes it (for VEX encoded instructions).  However, it's good to stick
to the spec, there are always surprise issues when you don't.

>
> >> A more fundamental question: why do we have to emulate this guest
> >> userspace SSE instruction in the first place?  This host machine lacks
> >> EPT but can't we service the page fault and then retry execution inside
> >> the guest?
> >
> > Not when the target is mmio - there is no possible mapping.  With your
> > patch, is there a kvm_mmio trace right after the movdqa emulation?
>
> You are right.  These instructions are accessing the VGA area at 0xa0000.

> >
> > Need the Mov flag too (I see it's missing for movdqu as well); otherwise
> > the emulator will RMW the destination.
>
> The Mov is already given by the GP() group prefix.
>

Ah.  Not sure it was a good idea.  The whole trend towards em_foo() is
motivated by the idea of having everything about an instruction in one
place, and this doesn't help there.  On the other hand, I can see many
SSE instructions repeating this pattern.  We'll just have to see how it
evolves.

-- 
error compiling committee.c: too many arguments to function