Xen devel - May 2007 - [PATCH 2/12] Pull necessary Linux PM files

Just borrow 5 files from Linux, for necessary cpu context
save/restore and wakeup stub. Except them, all the ACPI
related operations are still carried by dom0.

Signed-off-by Ke Yu <ke.yu@intel.com>
Signed-off-by Kevin Tian <kevin.tian@intel.com>


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

Could we not share some of this low-level code across 32 and 64 bits? A good
deal of it must be real mode asm anyway. Also it''s weird that only
x86/64
gets a new header file.

Overall, I think we should pick the cleanest one (x86/32 or x86/64) as a
starting point and then bludgeon the code so that it works for the other
sub-architecture too. This might involve a new file in the subarch
directories, but only for code that actually really is specific to that
subarch.

Or are there more fundamental differences than it first appears?

Also, I applied two of your patches now, which you will find in the staging
tree (one in xen, one in linux). It would be useful if you would resync the
remainder.

 -- Keir

On 15/5/07 15:15, "Tian, Kevin" <kevin.tian@intel.com> wrote:
> Just borrow 5 files from Linux, for necessary cpu context
> save/restore and wakeup stub. Except them, all the ACPI
> related operations are still carried by dom0.
> 
> Signed-off-by Ke Yu <ke.yu@intel.com>
> Signed-off-by Kevin Tian <kevin.tian@intel.com>
> _______________________________________________
> 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

>From: Keir Fraser [mailto:keir@xensource.com]
>Sent: 2007年6月11日 23:09
>
>Could we not share some of this low-level code across 32 and 64 bits? A
>good
>deal of it must be real mode asm anyway. Also it''s weird that only
x86/64
>gets a new header file.
Well, the reason is that we planned to use copy-and-modify style when 
borrowing logic from Linux in the start, like using "#ifdef __XEN__"
for
xen specific changes. Since too many modifications with ifdef makes 
patch difficult to read, we are conservative to change code/file logic 
from Linux side. 

If that comparison to Linux is not necessary, I agree that to cleanup 
with common logic can make patch much simpler. Actually there are 
even some dead code from Linux side.
>
>Overall, I think we should pick the cleanest one (x86/32 or x86/64) as a
>starting point and then bludgeon the code so that it works for the other
>sub-architecture too. This might involve a new file in the subarch
>directories, but only for code that actually really is specific to that
>subarch.
>
But before going this way, I have a question about to which extent we 
should consider common code instead of subarch duplication. Xen 
relocate patch merged boot assembly code between 32 and 64, 
though common lines in head.S are even less than arch differences. 
Will that make code less readable instead? Do you plan to merge 
more like entry.S? 
>Or are there more fundamental differences than it first appears?
>
Should be no, since it''s largely like a boot code to recover processor
context.

>Also, I applied two of your patches now, which you will find in the staging
>tree (one in xen, one in linux). It would be useful if you would resync the
>remainder.
>
> -- Keir
Thanks. I''ll first resync rest patches to make sure it working still,
and
then go back to cleanup the wakeup part as you suggested. This time 
I''ll discard #ifdef __XEN__ style since the final code may warp more 
from linux side which would make copy-and-change patch completely 
messed. 

Thanks,
Kevin
>
>On 15/5/07 15:15, "Tian, Kevin" <kevin.tian@intel.com>
wrote:
>
>> Just borrow 5 files from Linux, for necessary cpu context
>> save/restore and wakeup stub. Except them, all the ACPI
>> related operations are still carried by dom0.
>>
>> Signed-off-by Ke Yu <ke.yu@intel.com>
>> Signed-off-by Kevin Tian <kevin.tian@intel.com>
>> _______________________________________________
>> 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 12/6/07 05:33, "Tian, Kevin" <kevin.tian@intel.com> wrote:
>> Overall, I think we should pick the cleanest one (x86/32 or x86/64) as
a
>> starting point and then bludgeon the code so that it works for the
other
>> sub-architecture too. This might involve a new file in the subarch
>> directories, but only for code that actually really is specific to that
>> subarch.
>> 
> 
> But before going this way, I have a question about to which extent we
> should consider common code instead of subarch duplication. Xen
> relocate patch merged boot assembly code between 32 and 64,
> though common lines in head.S are even less than arch differences.
> Will that make code less readable instead? Do you plan to merge
> more like entry.S?
Well, a judgment call is required. In the example you cite, entry.S cannot
be merged because 32-bit and 64-bit assembly code is just plain different.
But for head.S at least I was able to make *most* of the real-mode and
32-bit protected mode common. I think that''s a win, even though 100%
merging
in the boot/ directory was not possible.

So the question is really how much merging is likely to be possible in the
wakeup code (both C and asm, as I see the patch introduces both). My guess
would be quite a lot, perhaps with ifdef for actual register load/save as
the 64-bit register block is bigger. But you''re best placed to say
whether
or not my guess is correct.

 -- Keir



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

>From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk]
>Sent: 2007年6月12日 15:43
>
>On 12/6/07 05:33, "Tian, Kevin" <kevin.tian@intel.com>
wrote:
>
>>> Overall, I think we should pick the cleanest one (x86/32 or x86/64)
as
>a
>>> starting point and then bludgeon the code so that it works for the
>other
>>> sub-architecture too. This might involve a new file in the subarch
>>> directories, but only for code that actually really is specific to
that
>>> subarch.
>>>
>>
>> But before going this way, I have a question about to which extent we
>> should consider common code instead of subarch duplication. Xen
>> relocate patch merged boot assembly code between 32 and 64,
>> though common lines in head.S are even less than arch differences.
>> Will that make code less readable instead? Do you plan to merge
>> more like entry.S?
>
>Well, a judgment call is required. In the example you cite, entry.S cannot
>be merged because 32-bit and 64-bit assembly code is just plain
>different.
>But for head.S at least I was able to make *most* of the real-mode and
>32-bit protected mode common. I think that''s a win, even though
100%
>merging
>in the boot/ directory was not possible.
>
>So the question is really how much merging is likely to be possible in the
>wakeup code (both C and asm, as I see the patch introduces both). My
>guess
>would be quite a lot, perhaps with ifdef for actual register load/save as
>the 64-bit register block is bigger. But you''re best placed to say
whether
>or not my guess is correct.
>
> -- Keir
I''m inclined to agree with your guess and wakeup part can be seen 
with more common stuff than boot code. Okay, without limitation to 
keep linux stuff strictly, I will start merging them into a Xen specific 
version.

Thanks,
Kevin

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

On 12/6/07 08:50, "Tian, Kevin" <kevin.tian@intel.com> wrote:
> I''m inclined to agree with your guess and wakeup part can be seen
> with more common stuff than boot code. Okay, without limitation to
> keep linux stuff strictly, I will start merging them into a Xen specific
> version.
I''m not so worried about keeping these files strictly like Linux,
I''ve
decided. How complicated can they be after all: it''s just state
save/restore. :-)

 -- Keir



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