qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] CC_DST problem
@ 2007-08-29 16:27 Alexander Graf
  2007-08-29 20:58 ` Fabrice Bellard
  0 siblings, 1 reply; 2+ messages in thread
From: Alexander Graf @ 2007-08-29 16:27 UTC (permalink / raw)
  To: qemu-devel

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

Hi,

I'm still trying to implement SVM correctly and hit a serious problem.
If I set CC_OP to EFLAGS / DYNAMIC after each instruction (so most
conditional operations are based on EFLAGS) everything works as expected.
If using CC_OP==CC_OP_EFLAGS only CC_SRC should be used and CC_DST is
supposed to be completely ignored.

So I set CC_DST to 0 (this happens when leaving and rejoining the
virtual machine, so this is the real problem) and if I do that, I get
funny segmentation faults in x86_64 guest userspace programs running in
the virtual machine (this is exactly what I see in kvm with my current
patchset as well), while 32 bit userspace programs simply hang.
So I guess this is the real problem.

Is there any logical reason CC_DST could be used with CC_OP==CC_OP_EFLAGS?

Attached to this email you will find a small patch that triggers this
problem.

Thanks for any reply that could help on this,

Alexander Graf

[-- Attachment #2: eflags.patch --]
[-- Type: text/x-patch, Size: 1001 bytes --]

Index: qemu/target-i386/op.c
===================================================================
--- qemu.orig/target-i386/op.c
+++ qemu/target-i386/op.c
@@ -1248,6 +1248,13 @@ void OPPROTO op_movl_crN_T0(void)
     helper_movl_crN_T0(PARAM1);
 }
 
+void OPPROTO op_geneflags(void)
+{
+    CC_SRC = cc_table[CC_OP].compute_all();
+    CC_DST = 0;
+    CC_OP = CC_OP_EFLAGS;
+}
+
 #if !defined(CONFIG_USER_ONLY) 
 void OPPROTO op_movtl_T0_cr8(void)
 {
Index: qemu/target-i386/translate.c
===================================================================
--- qemu.orig/target-i386/translate.c
+++ qemu/target-i386/translate.c
@@ -3154,6 +3154,12 @@ static target_ulong disas_insn(DisasCont
     target_ulong next_eip, tval;
     int rex_w, rex_r;
 
+ ////// DEBUG
+                if (s->cc_op != CC_OP_DYNAMIC)
+                    gen_op_set_cc_op(s->cc_op);
+		gen_op_geneflags();
+		s->cc_op = CC_OP_DYNAMIC;
+ ///////////////////
     s->pc = pc_start;
     prefixes = 0;
     aflag = s->code32;

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [Qemu-devel] CC_DST problem
  2007-08-29 16:27 [Qemu-devel] CC_DST problem Alexander Graf
@ 2007-08-29 20:58 ` Fabrice Bellard
  0 siblings, 0 replies; 2+ messages in thread
From: Fabrice Bellard @ 2007-08-29 20:58 UTC (permalink / raw)
  To: qemu-devel

Alexander Graf wrote:
> Hi,
> 
> I'm still trying to implement SVM correctly and hit a serious problem.
> If I set CC_OP to EFLAGS / DYNAMIC after each instruction (so most
> conditional operations are based on EFLAGS) everything works as expected.
> If using CC_OP==CC_OP_EFLAGS only CC_SRC should be used and CC_DST is
> supposed to be completely ignored.
> 
> So I set CC_DST to 0 (this happens when leaving and rejoining the
> virtual machine, so this is the real problem) and if I do that, I get
> funny segmentation faults in x86_64 guest userspace programs running in
> the virtual machine (this is exactly what I see in kvm with my current
> patchset as well), while 32 bit userspace programs simply hang.
> So I guess this is the real problem.
> 
> Is there any logical reason CC_DST could be used with CC_OP==CC_OP_EFLAGS?
> 
> Attached to this email you will find a small patch that triggers this
> problem.
> 
> Thanks for any reply that could help on this,
> 
> Alexander Graf

If you play with the CC_OP logic, it is better to disable the eflags 
optimization code in the translator (optimize_flags() function).

Regarding the implementation for SVM, you can look at how the CC are 
handled in SMM (do_smm_enter and helper_rsm). I see no particular 
problem here.

I suggest to try to suppress the additions in the static translator 
state as I feel most of the SVM intercepts can be tested in helpers 
where speed is not critical.

Regards,

Fabrice.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2007-08-29 21:00 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-08-29 16:27 [Qemu-devel] CC_DST problem Alexander Graf
2007-08-29 20:58 ` Fabrice Bellard

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