[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-ia64-devel] pv_ops polish: remove fsys.S changes


  • To: "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx>
  • From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
  • Date: Mon, 17 Mar 2008 16:15:49 +0800
  • Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 17 Mar 2008 01:21:19 -0700
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AciH/tDJztmzemU1Rb6Hmu/HnqOsTAABfwIQ
  • Thread-topic: [Xen-ia64-devel] pv_ops polish: remove fsys.S changes

>> Commit a07b265c618c279a84bac8f75f5acba1c1646200 is quit intrusive,
>> it removed code from entry.S to a new file switch_entry.S and create
>> 1000 lines of patch. 
>> 
>> At least we stay in original file, not?
> 
> At least xen/ia64 needs to paravirtualize ia64_swtich_to,

I did a scan on Alex's tree and find the diff between entry.S
& xenentry.S is very small, see the attachment, probably KR set
need to by modified.
For rest, what I saw is just a sensitive instruction replacement, 
we can do using indirect function call, or leave to future.


> ia64_leave_syscall and ia64_leave_kernel.
> The discussion for hand written assembly code indicates that single
> source and multiple compile.

This is easy for IVT & gate page, but for those normal APIs, I am
conservative
except indirect function call can't solve the problem.

> I think the clean way to do for those three functions is to split out
> them from entry.S. Cluttering out entry.S by ifdef would be uglry.
> Do you have better idea?

Maybe my above finding is wrong, otherwise leave it for now is fine.

Eddie

Attachment: entry_s_diff.patch
Description: entry_s_diff.patch

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.