[Qemu-devel] Guest SIGILL when different IO is implemented

[Qemu-devel] Guest SIGILL when different IO is implemented

[Miltiadis Hatzimihail]

I am trying to develop a simple PCI device and I am setting up 3 BARs. The
last BAR is a DDR and I ve tried 2 different implementations: one
with memory_region_init_io and one with memory_region_init_ram.

I ve got a small program that declares a buffer and does float operations
in the following fashion:

float *buffer;
buffer[index] = (float)value;

When I use QEMU with KVM, the memory_region_init_ram implementation seems
to be happy running the above code. When I use the memory_region_init_io I
get a SIGILL on the guest. I ve run this with GDB and the disassembly shows

movss %xmm0, (%rcx)

According to Intel ISA, the instruction does this

MOVSS Move Single Scalar

Opcode Cycles Instruction
F3 0F 10 MOVSS xmm reg,xmm reg/mem32
F3 0F 11 MOVSS mem32,xmm reg

MOVSS op1, op2

op1 contains 1 single precision 32-bit floating point value
op2 contains 1 single precision 32-bit floating point value

I ve looked at the KVM on the Host and hacked it to add some debug
statements to see when it fails to execute a command.

Tracing KVM during the run it fails on the movss instruction opcode: f3 0f
11:

 qemu-system-x86-1129  [000] .... 80154.583037: kvm_fpu: load
 qemu-system-x86-1129  [000] d... 80154.583037: kvm_entry: vcpu 1
 qemu-system-x86-1129  [000] .... 80154.583039: kvm_exit: reason
EPT_VIOLATION rip 0x7f2f45163c40 info 182 0
 qemu-system-x86-1129  [000] .... 80154.583039: kvm_page_fault: address
1404bc000 error_code 182
 qemu-system-x86-1129  [000] .... 80154.583042: kvm_emulate_insn:
0:7f2f45163c40:f3 0f 11 (prot64)
 qemu-system-x86-1129  [000] .N.. 80154.588339: kvm_emulate_insn:
0:7f2f45163c40:f3 0f 11 (prot64) failed
 qemu-system-x86-1129  [000] d... 80154.588342: kvm_fpu: unload
 qemu-system-x86-1129  [002] .... 80154.588523: kvm_inj_exception: #UD (0x0)
 qemu-system-x86-1129  [002] .... 80154.588525: kvm_fpu: load

The opcode is twobyte. Byte 0x11 is used to lookup flags from the twobyte
table in KVM

in arch/x86/kvm/emulate.c:4615
static const struct opcode twobyte_table[256] = {
    /* 0x00 - 0x0F */
    G(0, group6), GD(0, &group7), N, N,
    N, I(ImplicitOps | EmulateOnUD, em_syscall),
    II(ImplicitOps | Priv, em_clts, clts), N,
    DI(ImplicitOps | Priv, invd), DI(ImplicitOps | Priv, wbinvd), N, N,
    N, D(ImplicitOps | ModRM | SrcMem | NoAccess), N, N,
    /* 0x10 - 0x1F */
    N, N, N, N, N, N, N, N,
    D(ImplicitOps | ModRM | SrcMem | NoAccess),
    N, N, N, N, N, N, D(ImplicitOps | ModRM | SrcMem | NoAccess),

It looks like that the instruction is not implemented. I ve tried this on
the 3.10, 4.4 & 4.11 kernels on the host.

The interesting thing is that in the ram case the test is passing, but in
the io is failing. Also, if I try this without KVM, it passes in both cases.

So I ve done some reading and for the 2 cases above I get:

- KVM_EXIT_MMIO on memory_region_init_io  (KVM attempts and fails to
emulate MOVSS),
- KVM_EXIT_EXCEPTION on memory_region_init_ram(QEMU emulates MOVSS)

Is that right?

Now the question is, if I want to use the IO instead of a RAM, what's the
best way to solve this?

​Milton

Re: [Qemu-devel] Guest SIGILL when different IO is implemented

[Paolo Bonzini]

On 11/05/2017 09:00, Miltiadis Hatzimihail wrote:
> 
> The interesting thing is that in the ram case the test is passing, but in
> the io is failing. Also, if I try this without KVM, it passes in both cases.

Yes, in the RAM case KVM is not invoked at all.

> So I ve done some reading and for the 2 cases above I get:
> 
> - KVM_EXIT_MMIO on memory_region_init_io  (KVM attempts and fails to
> emulate MOVSS),
> - KVM_EXIT_EXCEPTION on memory_region_init_ram(QEMU emulates MOVSS)

No, you don't get any exit for memory_region_init_ram.

> Is that right?
> 
> Now the question is, if I want to use the IO instead of a RAM, what's the
> best way to solve this?

Please try this KVM patch:

diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index c25cfaf584e7..53fbd1589d2e 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -3534,6 +3534,22 @@ static int em_rdpmc(struct x86_emulate_ctxt *ctxt)
 	return X86EMUL_CONTINUE;
 }
 
+static int em_movss(struct x86_emulate_ctxt *ctxt)
+{
+	memcpy(ctxt->dst.valptr, ctxt->src.valptr, 4);
+	ctxt->op_bytes = 4;
+	ctxt->dst.bytes = 4;
+	return X86EMUL_CONTINUE;
+}
+
+static int em_movsd(struct x86_emulate_ctxt *ctxt)
+{
+	memcpy(ctxt->dst.valptr, ctxt->src.valptr, 8);
+	ctxt->op_bytes = 8;
+	ctxt->dst.bytes = 8;
+	return X86EMUL_CONTINUE;
+}
+
 static int em_mov(struct x86_emulate_ctxt *ctxt)
 {
 	memcpy(ctxt->dst.valptr, ctxt->src.valptr, sizeof(ctxt->src.valptr));
@@ -4407,6 +4423,11 @@ static int check_perm_out(struct x86_emulate_ctxt *ctxt)
 	I(Mmx, em_mov), I(Sse | Aligned, em_mov), N, I(Sse | Unaligned, em_mov),
 };
 
+static const struct gprefix pfx_0f_10_0f_11 = {
+	I(Sse | Unaligned, em_mov), I(Sse | Unaligned, em_mov),
+	I(Sse, em_movsd), I(Sse, em_movss),
+};
+
 static const struct instr_dual instr_dual_0f_2b = {
 	I(0, em_mov), N
 };
@@ -4626,6 +4647,8 @@ static int check_perm_out(struct x86_emulate_ctxt *ctxt)
 	DI(ImplicitOps | Priv, invd), DI(ImplicitOps | Priv, wbinvd), N, N,
 	N, D(ImplicitOps | ModRM | SrcMem | NoAccess), N, N,
 	/* 0x10 - 0x1F */
+	GP(SrcMem | DstReg | ModRM | Mov, &pfx_0f_10_0f_11),
+	GP(SrcReg | DstMem | ModRM | Mov, &pfx_0f_10_0f_11),
 	N, N, N, N, N, N, N, N,
 	D(ImplicitOps | ModRM | SrcMem | NoAccess),
 	N, N, N, N, N, N, D(ImplicitOps | ModRM | SrcMem | NoAccess),

Thanks,

Paolo

Re: [Qemu-devel] Guest SIGILL when different IO is implemented

[Miltiadis Hatzimihail]

Thanks Paolo that worked!

Btw, this line

​
+       GP(SrcMem | DstReg | ModRM | Mov, &pfx_0f_10_0f_11),
+       GP(SrcReg | DstMem | ModRM | Mov, &pfx_0f_10_0f_11),
-        N, N, N, N, N, N, N, N,
+       N, N, N, N, N, N,

I think it has 2 extra Ns (not removed from your change?).

Those instructions were not implemented for a reason or is it simply a
chance of never seeing this issue that I saw?

>> The interesting thing is that in the ram case the test is passing, but in
>> the io is failing. Also, if I try this without KVM, it passes in both
cases.
>
>Yes, in the RAM case KVM is not invoked at all.
So for my benefit, does this mean that any RAM transaction is emulated by
QEMU or does it go through KVM to the bare metal? (and hence, KVM is not
emulating this?)

​Milton


On Thu, May 11, 2017 at 12:51 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:

>
>
> On 11/05/2017 09:00, Miltiadis Hatzimihail wrote:
> >
> > The interesting thing is that in the ram case the test is passing, but in
> > the io is failing. Also, if I try this without KVM, it passes in both
> cases.
>
> Yes, in the RAM case KVM is not invoked at all.
>
> > So I ve done some reading and for the 2 cases above I get:
> >
> > - KVM_EXIT_MMIO on memory_region_init_io  (KVM attempts and fails to
> > emulate MOVSS),
> > - KVM_EXIT_EXCEPTION on memory_region_init_ram(QEMU emulates MOVSS)
>
> No, you don't get any exit for memory_region_init_ram.
>
> > Is that right?
> >
> > Now the question is, if I want to use the IO instead of a RAM, what's the
> > best way to solve this?
>
> Please try this KVM patch:
>
> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
> index c25cfaf584e7..53fbd1589d2e 100644
> --- a/arch/x86/kvm/emulate.c
> +++ b/arch/x86/kvm/emulate.c
> @@ -3534,6 +3534,22 @@ static int em_rdpmc(struct x86_emulate_ctxt *ctxt)
>         return X86EMUL_CONTINUE;
>  }
>
> +static int em_movss(struct x86_emulate_ctxt *ctxt)
> +{
> +       memcpy(ctxt->dst.valptr, ctxt->src.valptr, 4);
> +       ctxt->op_bytes = 4;
> +       ctxt->dst.bytes = 4;
> +       return X86EMUL_CONTINUE;
> +}
> +
> +static int em_movsd(struct x86_emulate_ctxt *ctxt)
> +{
> +       memcpy(ctxt->dst.valptr, ctxt->src.valptr, 8);
> +       ctxt->op_bytes = 8;
> +       ctxt->dst.bytes = 8;
> +       return X86EMUL_CONTINUE;
> +}
> +
>  static int em_mov(struct x86_emulate_ctxt *ctxt)
>  {
>         memcpy(ctxt->dst.valptr, ctxt->src.valptr,
> sizeof(ctxt->src.valptr));
> @@ -4407,6 +4423,11 @@ static int check_perm_out(struct x86_emulate_ctxt
> *ctxt)
>         I(Mmx, em_mov), I(Sse | Aligned, em_mov), N, I(Sse | Unaligned,
> em_mov),
>  };
>
> +static const struct gprefix pfx_0f_10_0f_11 = {
> +       I(Sse | Unaligned, em_mov), I(Sse | Unaligned, em_mov),
> +       I(Sse, em_movsd), I(Sse, em_movss),
> +};
> +
>  static const struct instr_dual instr_dual_0f_2b = {
>         I(0, em_mov), N
>  };
> @@ -4626,6 +4647,8 @@ static int check_perm_out(struct x86_emulate_ctxt
> *ctxt)
>         DI(ImplicitOps | Priv, invd), DI(ImplicitOps | Priv, wbinvd), N, N,
>         N, D(ImplicitOps | ModRM | SrcMem | NoAccess), N, N,
>         /* 0x10 - 0x1F */
> ​​
> +       GP(SrcMem | DstReg | ModRM | Mov, &pfx_0f_10_0f_11),
> +       GP(SrcReg | DstMem | ModRM | Mov, &pfx_0f_10_0f_11),
>         N, N, N, N, N, N, N, N,
>         D(ImplicitOps | ModRM | SrcMem | NoAccess),
>         N, N, N, N, N, N, D(ImplicitOps | ModRM | SrcMem | NoAccess),
>
> Thanks,
>
> Paolo
>

Re: [Qemu-devel] Guest SIGILL when different IO is implemented

[Paolo Bonzini]

On 11/05/2017 14:40, Miltiadis Hatzimihail wrote:
> Thanks Paolo that worked!
> 
> Btw, this line
> 
> ​
> +       GP(SrcMem | DstReg | ModRM | Mov, &pfx_0f_10_0f_11),
> +       GP(SrcReg | DstMem | ModRM | Mov, &pfx_0f_10_0f_11),
> -        N, N, N, N, N, N, N, N,
> +       N, N, N, N, N, N,
> 
> I think it has 2 extra Ns (not removed from your change?).

Oops, you're right.

> Those instructions were not implemented for a reason or is it simply a
> chance of never seeing this issue that I saw?

Never seeing this issue.

>>> The interesting thing is that in the ram case the test is passing, but in
>>> the io is failing. Also, if I try this without KVM, it passes in both cases.
>>
>>Yes, in the RAM case KVM is not invoked at all.
> So for my benefit, does this mean that any RAM transaction is emulated
> by QEMU or does it go through KVM to the bare metal? (and hence, KVM is
> not emulating this?)

The latter.  The don't get any emulation.

Paolo

> 
> ​Milton
> 
> 
> On Thu, May 11, 2017 at 12:51 PM, Paolo Bonzini <pbonzini@redhat.com
> <mailto:pbonzini@redhat.com>> wrote:
> 
> 
> 
>     On 11/05/2017 09:00, Miltiadis Hatzimihail wrote:
>     >
>     > The interesting thing is that in the ram case the test is passing, but in
>     > the io is failing. Also, if I try this without KVM, it passes in both cases.
> 
>     Yes, in the RAM case KVM is not invoked at all.
> 
>     > So I ve done some reading and for the 2 cases above I get:
>     >
>     > - KVM_EXIT_MMIO on memory_region_init_io  (KVM attempts and fails to
>     > emulate MOVSS),
>     > - KVM_EXIT_EXCEPTION on memory_region_init_ram(QEMU emulates MOVSS)
> 
>     No, you don't get any exit for memory_region_init_ram.
> 
>     > Is that right?
>     >
>     > Now the question is, if I want to use the IO instead of a RAM, what's the
>     > best way to solve this?
> 
>     Please try this KVM patch:
> 
>     diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
>     index c25cfaf584e7..53fbd1589d2e 100644
>     --- a/arch/x86/kvm/emulate.c
>     +++ b/arch/x86/kvm/emulate.c
>     @@ -3534,6 +3534,22 @@ static int em_rdpmc(struct x86_emulate_ctxt
>     *ctxt)
>             return X86EMUL_CONTINUE;
>      }
> 
>     +static int em_movss(struct x86_emulate_ctxt *ctxt)
>     +{
>     +       memcpy(ctxt->dst.valptr, ctxt->src.valptr, 4);
>     +       ctxt->op_bytes = 4;
>     +       ctxt->dst.bytes = 4;
>     +       return X86EMUL_CONTINUE;
>     +}
>     +
>     +static int em_movsd(struct x86_emulate_ctxt *ctxt)
>     +{
>     +       memcpy(ctxt->dst.valptr, ctxt->src.valptr, 8);
>     +       ctxt->op_bytes = 8;
>     +       ctxt->dst.bytes = 8;
>     +       return X86EMUL_CONTINUE;
>     +}
>     +
>      static int em_mov(struct x86_emulate_ctxt *ctxt)
>      {
>             memcpy(ctxt->dst.valptr, ctxt->src.valptr,
>     sizeof(ctxt->src.valptr));
>     @@ -4407,6 +4423,11 @@ static int check_perm_out(struct
>     x86_emulate_ctxt *ctxt)
>             I(Mmx, em_mov), I(Sse | Aligned, em_mov), N, I(Sse |
>     Unaligned, em_mov),
>      };
> 
>     +static const struct gprefix pfx_0f_10_0f_11 = {
>     +       I(Sse | Unaligned, em_mov), I(Sse | Unaligned, em_mov),
>     +       I(Sse, em_movsd), I(Sse, em_movss),
>     +};
>     +
>      static const struct instr_dual instr_dual_0f_2b = {
>             I(0, em_mov), N
>      };
>     @@ -4626,6 +4647,8 @@ static int check_perm_out(struct
>     x86_emulate_ctxt *ctxt)
>             DI(ImplicitOps | Priv, invd), DI(ImplicitOps | Priv,
>     wbinvd), N, N,
>             N, D(ImplicitOps | ModRM | SrcMem | NoAccess), N, N,
>             /* 0x10 - 0x1F */
>     ​​
>     +       GP(SrcMem | DstReg | ModRM | Mov, &pfx_0f_10_0f_11),
>     +       GP(SrcReg | DstMem | ModRM | Mov, &pfx_0f_10_0f_11),
>             N, N, N, N, N, N, N, N,
>             D(ImplicitOps | ModRM | SrcMem | NoAccess),
>             N, N, N, N, N, N, D(ImplicitOps | ModRM | SrcMem | NoAccess),
> 
>     Thanks,
> 
>     Paolo
> 
> 

Re: [Qemu-devel] Guest SIGILL when different IO is implemented

[Miltiadis Hatzimihail]

That's great thanks for the clarification.

Is this patch going to make it to the mainline at some point?


Miltiadis Hatzimihail


On Thu, May 11, 2017 at 1:44 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:

>
>
> On 11/05/2017 14:40, Miltiadis Hatzimihail wrote:
> > Thanks Paolo that worked!
> >
> > Btw, this line
> >
> > ​
> > +       GP(SrcMem | DstReg | ModRM | Mov, &pfx_0f_10_0f_11),
> > +       GP(SrcReg | DstMem | ModRM | Mov, &pfx_0f_10_0f_11),
> > -        N, N, N, N, N, N, N, N,
> > +       N, N, N, N, N, N,
> >
> > I think it has 2 extra Ns (not removed from your change?).
>
> Oops, you're right.
>
> > Those instructions were not implemented for a reason or is it simply a
> > chance of never seeing this issue that I saw?
>
> Never seeing this issue.
>
> >>> The interesting thing is that in the ram case the test is passing, but
> in
> >>> the io is failing. Also, if I try this without KVM, it passes in both
> cases.
> >>
> >>Yes, in the RAM case KVM is not invoked at all.
> > So for my benefit, does this mean that any RAM transaction is emulated
> > by QEMU or does it go through KVM to the bare metal? (and hence, KVM is
> > not emulating this?)
>
> The latter.  The don't get any emulation.
>
> Paolo
>
> >
> > ​Milton
> >
> >
> > On Thu, May 11, 2017 at 12:51 PM, Paolo Bonzini <pbonzini@redhat.com
> > <mailto:pbonzini@redhat.com>> wrote:
> >
> >
> >
> >     On 11/05/2017 09:00, Miltiadis Hatzimihail wrote:
> >     >
> >     > The interesting thing is that in the ram case the test is passing,
> but in
> >     > the io is failing. Also, if I try this without KVM, it passes in
> both cases.
> >
> >     Yes, in the RAM case KVM is not invoked at all.
> >
> >     > So I ve done some reading and for the 2 cases above I get:
> >     >
> >     > - KVM_EXIT_MMIO on memory_region_init_io  (KVM attempts and fails
> to
> >     > emulate MOVSS),
> >     > - KVM_EXIT_EXCEPTION on memory_region_init_ram(QEMU emulates MOVSS)
> >
> >     No, you don't get any exit for memory_region_init_ram.
> >
> >     > Is that right?
> >     >
> >     > Now the question is, if I want to use the IO instead of a RAM,
> what's the
> >     > best way to solve this?
> >
> >     Please try this KVM patch:
> >
> >     diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
> >     index c25cfaf584e7..53fbd1589d2e 100644
> >     --- a/arch/x86/kvm/emulate.c
> >     +++ b/arch/x86/kvm/emulate.c
> >     @@ -3534,6 +3534,22 @@ static int em_rdpmc(struct x86_emulate_ctxt
> >     *ctxt)
> >             return X86EMUL_CONTINUE;
> >      }
> >
> >     +static int em_movss(struct x86_emulate_ctxt *ctxt)
> >     +{
> >     +       memcpy(ctxt->dst.valptr, ctxt->src.valptr, 4);
> >     +       ctxt->op_bytes = 4;
> >     +       ctxt->dst.bytes = 4;
> >     +       return X86EMUL_CONTINUE;
> >     +}
> >     +
> >     +static int em_movsd(struct x86_emulate_ctxt *ctxt)
> >     +{
> >     +       memcpy(ctxt->dst.valptr, ctxt->src.valptr, 8);
> >     +       ctxt->op_bytes = 8;
> >     +       ctxt->dst.bytes = 8;
> >     +       return X86EMUL_CONTINUE;
> >     +}
> >     +
> >      static int em_mov(struct x86_emulate_ctxt *ctxt)
> >      {
> >             memcpy(ctxt->dst.valptr, ctxt->src.valptr,
> >     sizeof(ctxt->src.valptr));
> >     @@ -4407,6 +4423,11 @@ static int check_perm_out(struct
> >     x86_emulate_ctxt *ctxt)
> >             I(Mmx, em_mov), I(Sse | Aligned, em_mov), N, I(Sse |
> >     Unaligned, em_mov),
> >      };
> >
> >     +static const struct gprefix pfx_0f_10_0f_11 = {
> >     +       I(Sse | Unaligned, em_mov), I(Sse | Unaligned, em_mov),
> >     +       I(Sse, em_movsd), I(Sse, em_movss),
> >     +};
> >     +
> >      static const struct instr_dual instr_dual_0f_2b = {
> >             I(0, em_mov), N
> >      };
> >     @@ -4626,6 +4647,8 @@ static int check_perm_out(struct
> >     x86_emulate_ctxt *ctxt)
> >             DI(ImplicitOps | Priv, invd), DI(ImplicitOps | Priv,
> >     wbinvd), N, N,
> >             N, D(ImplicitOps | ModRM | SrcMem | NoAccess), N, N,
> >             /* 0x10 - 0x1F */
> >     ​​
> >     +       GP(SrcMem | DstReg | ModRM | Mov, &pfx_0f_10_0f_11),
> >     +       GP(SrcReg | DstMem | ModRM | Mov, &pfx_0f_10_0f_11),
> >             N, N, N, N, N, N, N, N,
> >             D(ImplicitOps | ModRM | SrcMem | NoAccess),
> >             N, N, N, N, N, N, D(ImplicitOps | ModRM | SrcMem | NoAccess),
> >
> >     Thanks,
> >
> >     Paolo
> >
> >
>

Re: [Qemu-devel] Guest SIGILL when different IO is implemented

[Paolo Bonzini]

On 11/05/2017 14:47, Miltiadis Hatzimihail wrote:
> That's great thanks for the clarification.
> 
> Is this patch going to make it to the mainline at some point?

Not exactly as is, because it has a small defect (it always reads 16
bytes from memory), but something like that will.

Paolo

Re: [Qemu-devel] Guest SIGILL when different IO is implemented

[Miltiadis Hatzimihail]

Ok many thanks for your help.

​Milton

On Thu, May 11, 2017 at 2:11 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:

>
>
> On 11/05/2017 14:47, Miltiadis Hatzimihail wrote:
> > That's great thanks for the clarification.
> >
> > Is this patch going to make it to the mainline at some point?
>
> Not exactly as is, because it has a small defect (it always reads 16
> bytes from memory), but something like that will.
>
> Paolo
>

Re: [Qemu-devel] Guest SIGILL when different IO is implemented

[Miltiadis Hatzimihail]

I ve tried the same today using a 32-bit Guest OS and the illegal
instruction this time is

fstps %(ecx)

Is it a similar case to the movss one? (the previous Guest I was using was
64 bit).

Also, I had to start QEMU using the following command line options:

qemu -cpu host,-sse2

because one my programs was giving me an illegal instruction based on the
above and it worked by disabling it.

​Regards
Milton

On Thu, May 11, 2017 at 2:12 PM, Miltiadis Hatzimihail <
hatzimiltos@gmail.com> wrote:

> Ok many thanks for your help.
>
> ​Milton
>
> On Thu, May 11, 2017 at 2:11 PM, Paolo Bonzini <pbonzini@redhat.com>
> wrote:
>
>>
>>
>> On 11/05/2017 14:47, Miltiadis Hatzimihail wrote:
>> > That's great thanks for the clarification.
>> >
>> > Is this patch going to make it to the mainline at some point?
>>
>> Not exactly as is, because it has a small defect (it always reads 16
>> bytes from memory), but something like that will.
>>
>> Paolo
>>
>
>

Re: [Qemu-devel] Guest SIGILL when different IO is implemented

[Paolo Bonzini]

On 12/05/2017 09:26, Miltiadis Hatzimihail wrote:
> I ve tried the same today using a 32-bit Guest OS and the illegal
> instruction this time is
> 
> fstps %(ecx)
> 
> Is it a similar case to the movss one? (the previous Guest I was using
> was 64 bit).

Yes, it is.

Paolo

> Also, I had to start QEMU using the following command line options:
> 
> qemu -cpu host,-sse2 
> 
> because one my programs was giving me an illegal instruction based on
> the above and it worked by disabling it.
> 
> ​Regards
> Milton
> 
> On Thu, May 11, 2017 at 2:12 PM, Miltiadis Hatzimihail
> <hatzimiltos@gmail.com <mailto:hatzimiltos@gmail.com>> wrote:
> 
>     Ok many thanks for your help.
> 
>     ​Milton
> 
>     On Thu, May 11, 2017 at 2:11 PM, Paolo Bonzini <pbonzini@redhat.com
>     <mailto:pbonzini@redhat.com>> wrote:
> 
> 
> 
>         On 11/05/2017 14:47, Miltiadis Hatzimihail wrote:
>         > That's great thanks for the clarification.
>         >
>         > Is this patch going to make it to the mainline at some point?
> 
>         Not exactly as is, because it has a small defect (it always reads 16
>         bytes from memory), but something like that will.
> 
>         Paolo
> 
> 
> 

Re: [Qemu-devel] Guest SIGILL when different IO is implemented

[Miltiadis Hatzimihail]

​I ve seen that I ve accidentally dropped the list from the email..

So for fstps for the 32bit - how does this patch look?

diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c

index a252081d..83b0fd2 100644

--- a/arch/x86/kvm/emulate.c

+++ b/arch/x86/kvm/emulate.c

@@ -1139,6 +1139,27 @@ static int em_fninit(struct x86_emulate_ctxt *ctxt)

               return X86EMUL_CONTINUE;

}



+static int em_fld(struct x86_emulate_ctxt *ctxt)

+{

+             ctxt->ops->get_fpu(ctxt);

+             asm volatile("fld %0": "+m"(ctxt->src.val));

+             ctxt->ops->put_fpu(ctxt);

+

+             return X86EMUL_CONTINUE;

+}

+

+static int em_fstp(struct x86_emulate_ctxt *ctxt)

+{

+             u32 fcw;

+

+             ctxt->ops->get_fpu(ctxt);

+             asm volatile("fstp %0": "+m"(fcw));

+             ctxt->ops->put_fpu(ctxt);

+

+             ctxt->dst.val = fcw;

+             return X86EMUL_CONTINUE;

+}

+

static int em_fnstcw(struct x86_emulate_ctxt *ctxt)

{

               u16 fcw;

@@ -4438,7 +4459,7 @@ static const struct gprefix pfx_0f_e7 = {

};



 static const struct escape escape_d9 = { {

-              N, N, N, N, N, N, N, I(DstMem16 | Mov, em_fnstcw),

+             I(SrcMem | Stack, em_fld), N, N, I(DstMem | Mov | Stack,
em_fstp), N, N, N, I(DstMem16 | Mov, em_fnstcw),

}, {

               /* 0xC0 - 0xC7 */

               N, N, N, N, N, N, N, N,​


Miltiadis Hatzimihail


On Tue, May 16, 2017 at 9:09 AM, Miltiadis Hatzimihail <
hatzimiltos@gmail.com> wrote:

> How does this patch look to you?
>
> --- a/arch/x86/kvm/emulate.c
>
> +++ b/arch/x86/kvm/emulate.c
>
> @@ -1139,6 +1139,27 @@ static int em_fninit(struct x86_emulate_ctxt *ctxt)
>
>                return X86EMUL_CONTINUE;
>
> }
>
>
>
> +static int em_fld(struct x86_emulate_ctxt *ctxt)
>
> +{
>
> +             ctxt->ops->get_fpu(ctxt);
>
> +             asm volatile("fld %0": "+m"(ctxt->src.val));
>
> +             ctxt->ops->put_fpu(ctxt);
>
> +
>
> +             return X86EMUL_CONTINUE;
>
> +}
>
> +
>
> +static int em_fstp(struct x86_emulate_ctxt *ctxt)
>
> +{
>
> +             u32 fcw;
>
> +
>
> +             ctxt->ops->get_fpu(ctxt);
>
> +             asm volatile("fstp %0": "+m"(fcw));
>
> +             ctxt->ops->put_fpu(ctxt);
>
> +
>
> +             ctxt->dst.val = fcw;
>
> +             return X86EMUL_CONTINUE;
>
> +}
>
> +
>
> static int em_fnstcw(struct x86_emulate_ctxt *ctxt)
>
> {
>
>                u16 fcw;
>
> @@ -4438,7 +4459,7 @@ static const struct gprefix pfx_0f_e7 = {
>
> };
>
>
>
>  static const struct escape escape_d9 = { {
>
> -              N, N, N, N, N, N, N, I(DstMem16 | Mov, em_fnstcw),
>
> +             I(SrcMem | Stack, em_fld), N, N, I(DstMem | Mov | Stack,
> em_fstp), N, N, N, I(DstMem16 | Mov, em_fnstcw),
>
> }, {
>
>                /* 0xC0 - 0xC7 */
>
>                N, N, N, N, N, N, N, N,
>
>
> Miltiadis Hatzimihail
>
>
> On Mon, May 15, 2017 at 8:58 AM, Paolo Bonzini <pbonzini@redhat.com>
> wrote:
>
>>
>>
>> On 15/05/2017 08:42, Miltiadis Hatzimihail wrote:
>> > Thanks - is it just a matter of adjusting your old patch for this
>> > command? (I looked up the opcode and it was dd or d9 I think).
>>
>> The encoding of fstps is a bit different because it's an x87
>> instruction, but the idea is the same.
>>
>> Paolo
>> >
>> > Miltiadis Hatzimihail
>> >
>> >
>> > On Fri, May 12, 2017 at 1:00 PM, Paolo Bonzini <pbonzini@redhat.com
>> > <mailto:pbonzini@redhat.com>> wrote:
>> >
>> >
>> >
>> >     On 12/05/2017 09:26, Miltiadis Hatzimihail wrote:
>> >     > I ve tried the same today using a 32-bit Guest OS and the illegal
>> >     > instruction this time is
>> >     >
>> >     > fstps %(ecx)
>> >     >
>> >     > Is it a similar case to the movss one? (the previous Guest I was
>> using
>> >     > was 64 bit).
>> >
>> >     Yes, it is.
>> >
>> >     Paolo
>> >
>> >     > Also, I had to start QEMU using the following command line
>> options:
>> >     >
>> >     > qemu -cpu host,-sse2
>> >     >
>> >     > because one my programs was giving me an illegal instruction
>> based on
>> >     > the above and it worked by disabling it.
>> >     >
>> >     > ​Regards
>> >     > Milton
>> >     >
>> >     > On Thu, May 11, 2017 at 2:12 PM, Miltiadis Hatzimihail
>> >     > <hatzimiltos@gmail.com <mailto:hatzimiltos@gmail.com>
>> >     <mailto:hatzimiltos@gmail.com <mailto:hatzimiltos@gmail.com>>>
>> wrote:
>> >     >
>> >     >     Ok many thanks for your help.
>> >     >
>> >     >     ​Milton
>> >     >
>> >     >     On Thu, May 11, 2017 at 2:11 PM, Paolo Bonzini <
>> pbonzini@redhat.com <mailto:pbonzini@redhat.com>
>> >     >     <mailto:pbonzini@redhat.com <mailto:pbonzini@redhat.com>>>
>> wrote:
>> >     >
>> >     >
>> >     >
>> >     >         On 11/05/2017 14:47, Miltiadis Hatzimihail wrote:
>> >     >         > That's great thanks for the clarification.
>> >     >         >
>> >     >         > Is this patch going to make it to the mainline at some
>> >     point?
>> >     >
>> >     >         Not exactly as is, because it has a small defect (it
>> >     always reads 16
>> >     >         bytes from memory), but something like that will.
>> >     >
>> >     >         Paolo
>> >     >
>> >     >
>> >     >
>> >
>> >
>>
>
>