On x86_64, strace expects CS == 0x33 for 64bit applications and CS =0x23 for
32bit applications, or it will complain.
This patch makes strace happy with xeno64.
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/06/09 01:40:43-07:00 xin@los-vmm64.sc.intel.com
# Make strace happy with xeno64.
# Signed-off-by: Li B Xin <li.b.xin@intel.com>
# Signed-off-by: Jun Nakajima <jun.nakajima@intel.com>
#
# linux-2.6.11-xen-sparse/arch/xen/x86_64/kernel/entry.S
# 2005/06/09 01:40:42-07:00 xin@los-vmm64.sc.intel.com +1 -0
# On x86_64, strace expects CS == 0x33 for 64bit applications and CS
== 0x23 for 32bit applications, or it will complain.
# We just make strace happy here.
#
diff -Nru a/linux-2.6.11-xen-sparse/arch/xen/x86_64/kernel/entry.S
b/linux-2.6.11-xen-sparse/arch/xen/x86_64/kernel/entry.S
--- a/linux-2.6.11-xen-sparse/arch/xen/x86_64/kernel/entry.S
2005-06-09 01:41:08 -07:00
+++ b/linux-2.6.11-xen-sparse/arch/xen/x86_64/kernel/entry.S
2005-06-09 01:41:08 -07:00
@@ -311,6 +311,7 @@
tracesys:
SAVE_REST
movq $-ENOSYS,RAX(%rsp)
+ andl $0xff,CS(%rsp)
movq %rsp,%rdi
call syscall_trace_enter
LOAD_ARGS ARGOFFSET /* reload args from stack in case ptrace
changed it */
-Xin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Hi Keir, do you have time to take a look at this patch? -Xin Li, Xin B wrote:> On x86_64, strace expects CS == 0x33 for 64bit > applications and CS == 0x23 for 32bit applications, or it > will complain. > This patch makes strace happy with xeno64. > > # This is a BitKeeper generated diff -Nru style patch. > # > # ChangeSet > # 2005/06/09 01:40:43-07:00 xin@los-vmm64.sc.intel.com > # Make strace happy with xeno64. > # Signed-off-by: Li B Xin <li.b.xin@intel.com> > # Signed-off-by: Jun Nakajima <jun.nakajima@intel.com> > # > # linux-2.6.11-xen-sparse/arch/xen/x86_64/kernel/entry.S > # 2005/06/09 01:40:42-07:00 xin@los-vmm64.sc.intel.com > +1 -0 # On x86_64, strace expects CS == 0x33 for 64bit > applications and CS == 0x23 for 32bit applications, or it > will complain. # We just make strace happy here. > # > diff -Nru > a/linux-2.6.11-xen-sparse/arch/xen/x86_64/kernel/entry.S > b/linux-2.6.11-xen-sparse/arch/xen/x86_64/kernel/entry.S > --- > a/linux-2.6.11-xen-sparse/arch/xen/x86_64/kernel/entry.S > 2005-06-09 01:41:08 -07:00 +++ > b/linux-2.6.11-xen-sparse/arch/xen/x86_64/kernel/entry.S > 2005-06-09 01:41:08 -07:00 @@ -311,6 +311,7 @@ tracesys: > SAVE_REST > movq $-ENOSYS,RAX(%rsp) > + andl $0xff,CS(%rsp) > movq %rsp,%rdi > call syscall_trace_enter > LOAD_ARGS ARGOFFSET /* reload args from stack in > case ptrace changed it */ > > > -Xin > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 10 Jun 2005, at 09:00, Li, Xin B wrote:> Hi Keir, do you have time to take a look at this patch? > -Xin > > Li, Xin B wrote: >> On x86_64, strace expects CS == 0x33 for 64bit >> applications and CS == 0x23 for 32bit applications, or it >> will complain. >> This patch makes strace happy with xeno64.The CS should be 0x23/0x33 -- no need for masking? Or is the fact that the upcall saved mask appears in bits 16-23 of the ''4-byte'' CS value a problem? We can move the saved mask if so: I think that would be neater. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 10 Jun 2005, at 09:06, Keir Fraser wrote:>> Hi Keir, do you have time to take a look at this patch? >> -Xin >> >> Li, Xin B wrote: >>> On x86_64, strace expects CS == 0x33 for 64bit >>> applications and CS == 0x23 for 32bit applications, or it >>> will complain. >>> This patch makes strace happy with xeno64. > > The CS should be 0x23/0x33 -- no need for masking? Or is the fact that > the upcall saved mask appears in bits 16-23 of the ''4-byte'' CS value a > problem? We can move the saved mask if so: I think that would be > neater.I see that xenlinux places its own save mask at CS+4 anyway (not CS+2 as Xen does). So I''ve moved the Xen mask to CS+4 too. A very simple patch and you probably now will not need to patch the strace path. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote:> On 10 Jun 2005, at 09:00, Li, Xin B wrote: > >> Hi Keir, do you have time to take a look at this patch? >> -Xin >> >> Li, Xin B wrote: >>> On x86_64, strace expects CS == 0x33 for 64bit >>> applications and CS == 0x23 for 32bit applications, or >>> it will complain. This patch makes strace happy with >>> xeno64. > > The CS should be 0x23/0x33 -- no need for masking? Or is > the fact that the upcall saved mask appears in bits 16-23 > of the ''4-byte'' CS value a problem? We can move the saved > mask if so: I think that would be neater.CS is 0xE033 for 64bit apps on xeno64.> > -- Keir_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 10 Jun 2005, at 09:33, Li, Xin B wrote:>> The CS should be 0x23/0x33 -- no need for masking? Or is >> the fact that the upcall saved mask appears in bits 16-23 >> of the ''4-byte'' CS value a problem? We can move the saved >> mask if so: I think that would be neater. > > CS is 0xE033 for 64bit apps on xeno64.Xenolinux should be installing its own GDT with selectors at 0x23/0x33 and be using those. I think it already installs a suitable GDT, so probably simply a matter of modifying a few USER_CS macros somewhere. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 10 Jun 2005, at 09:37, Li, Xin B wrote:> I will test itIf xenlinux really is using selector E033 then it won;t fix the problem. You need to fix the USER_CS macros to use the selectors in xenlinux''s GDT. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I will test it Keir Fraser wrote:> On 10 Jun 2005, at 09:06, Keir Fraser wrote: > >>> Hi Keir, do you have time to take a look at this patch? >>> -Xin >>> >>> Li, Xin B wrote: >>>> On x86_64, strace expects CS == 0x33 for 64bit >>>> applications and CS == 0x23 for 32bit applications, or >>>> it will complain. This patch makes strace happy with >>>> xeno64. >> >> The CS should be 0x23/0x33 -- no need for masking? Or is >> the fact that the upcall saved mask appears in bits >> 16-23 of the ''4-byte'' CS value a problem? We can move >> the saved mask if so: I think that would be neater. > > I see that xenlinux places its own save mask at CS+4 > anyway (not CS+2 as Xen does). So I''ve moved the Xen mask > to CS+4 too. A very simple patch and you probably now > will not need to patch the strace path. > > -- Keir_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 10 Jun 2005, at 09:35, Keir Fraser wrote:>> I will test it > > If xenlinux really is using selector E033 then it won;t fix the > problem. You need to fix the USER_CS macros to use the selectors in > xenlinux''s GDT.Ah, I now understand the problem. When the application executes SYSCALL we lose the value of CS, and Xen recreates it as 0xE033. The best fix to is bring back the macro FIXUP_TOP_OF_STACK in arch/xen/x86_64/kernel/entry.S, and call it everywhere that the original arch/x86_64/kernel/entry.S calls it. I''ve checked this fix in -- if you test now then hopefully the strace problem is gone. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel