Guest SIGILL when different IO is implemented

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:


Thanks,

Paolo

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
>

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
> 
>

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
> >
> >
>

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

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
>

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
>>
>
>

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
> 
> 
>

​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
>> >     >
>> >     >
>> >     >
>> >
>> >
>>
>
>