From: Miltiadis Hatzimihail <hatzimiltos@gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Guest SIGILL when different IO is implemented
Date: Thu, 11 May 2017 13:47:08 +0100 [thread overview]
Message-ID: <CALUZMn3W06H83E7hr4cHQ2jACp7A2x8hNyU1YirJssd3S7ut2Q@mail.gmail.com> (raw)
In-Reply-To: <0c725626-6485-c777-46e3-99423670df89@redhat.com>
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
> >
> >
>
next prev parent reply other threads:[~2017-05-11 12:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-11 7:00 [Qemu-devel] Guest SIGILL when different IO is implemented Miltiadis Hatzimihail
2017-05-11 11:51 ` Paolo Bonzini
2017-05-11 12:40 ` Miltiadis Hatzimihail
2017-05-11 12:44 ` Paolo Bonzini
2017-05-11 12:47 ` Miltiadis Hatzimihail [this message]
2017-05-11 13:11 ` Paolo Bonzini
2017-05-11 13:12 ` Miltiadis Hatzimihail
2017-05-12 7:26 ` Miltiadis Hatzimihail
2017-05-12 12:00 ` Paolo Bonzini
[not found] ` <CALUZMn3-wWyeo3_ONHN52PEDk2Hyin7LoPfjOFtL1Rspq3WYKA@mail.gmail.com>
[not found] ` <8a18aa4b-8151-57f4-f209-6245acb6393e@redhat.com>
[not found] ` <CALUZMn0ppiDx_5jVAmCKqATH7EtDacvarOcY6gF-oh2z3C+3MQ@mail.gmail.com>
2017-05-16 8:11 ` Miltiadis Hatzimihail
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALUZMn3W06H83E7hr4cHQ2jACp7A2x8hNyU1YirJssd3S7ut2Q@mail.gmail.com \
--to=hatzimiltos@gmail.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).