Mailing List Archive

[Xen-merge] questions (resend)
Since they remained un-answered so far, I'm resending the questions I
had embedded in the proposal for i386's include file merges. Without
answers I cannot properly deal with the respective files.

include/asm-i386/mach-xen/asm/fixmap.h
- Can any of the fixmaps actually live at machine addresses beyond 4G?
- Can't FIX_ACPI_RSDP_PAGE be replaced by use of FIX_ISAMAP + n?

include/asm-i386/mach-xen/asm/io.h
- whether merging is appropriate needs to be discussed; an alternative
would be to break out the *_to_* translations (into a new
include/asm-i386/mach-*/mach_xlat.h)
- What is __UNSAFE_IO__?

include/asm-i386/mach-xen/asm/pgtable-3level.h
- BUG()/panic() in pfn_pmd() needs attention from whoever put it there

include/asm-i386/mach-xen/asm/pgtable-?level-defs.h
- possibly replace HAVE_SHARED_KERNEL_PMD by
CONFIG_XEN/CONFIG_X86_XEN?

include/asm-i386/mach-xen/asm/setup.h
- What is the 'unsigned long long' override for PFN_PHYS good for (and
if for anything, why isn't standard Linux in need of this in PAE
mode)?

include/asm-i386/mach-xen/asm/synch_bitops.h
- don't use ; to separate lock prefix (only / or blank are proper
syntax)
- replace "q" constraint on word/long/quad cmpxchg with "r" (mainline
change)
- include/asm-i386/mach-xen/asm/synch_bitops.h ->
include/asm-x86_64/mach-xen/asm/ (copy, minor cleanup to remove
32-bit conditional, maybe use 64-bit ops where useful)
- include/asm-i386/mach-xen/asm/synch_bitops.h ->
include/asm-i386/synch_bitops.h (minor cleanup to remove 64-bit
conditional)

Thanks, Jan

_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge
Re: [Xen-merge] questions (resend) [ In reply to ]
On 20 Dec 2005, at 16:57, Jan Beulich wrote:

> - Can't FIX_ACPI_RSDP_PAGE be replaced by use of FIX_ISAMAP + n?

Yes, it probably can. The RSDP is always below 1MB, right?

> include/asm-i386/mach-xen/asm/io.h
> - whether merging is appropriate needs to be discussed; an alternative
> would be to break out the *_to_* translations (into a new
> include/asm-i386/mach-*/mach_xlat.h)

Sounds okay.

> - What is __UNSAFE_IO__?

That is obsolete code -- Xen does the same thing automatically now by
emulating I/O-port instructions. I'll delete the code from the
xen-unstable repository and from there it'll trickle down to the merge
trees.

> include/asm-i386/mach-xen/asm/setup.h
> - What is the 'unsigned long long' override for PFN_PHYS good for (and
> if for anything, why isn't standard Linux in need of this in PAE
> mode)?

It must have got added at some point to fix a problem on >4GB boxes,
but now I can't see any use of PFN_PHYS where the result can reasonably
be larger than 4GB. Perhaps the offending usage got removed. I think
this modification to PFN_PHYS shouldn't get merged.

-- Keir


_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge
Re: [Xen-merge] questions (resend) [ In reply to ]
>> include/asm-i386/mach-xen/asm/setup.h
>> - What is the 'unsigned long long' override for PFN_PHYS good for
(and
>> if for anything, why isn't standard Linux in need of this in PAE
>> mode)?
>
>It must have got added at some point to fix a problem on >4GB boxes,
>but now I can't see any use of PFN_PHYS where the result can
reasonably
>be larger than 4GB. Perhaps the offending usage got removed. I think
>this modification to PFN_PHYS shouldn't get merged.

I actually disagree after a second inspection: At least the use in the
call to add_memory_region() (in
include/asm-i386/mach-xen/setup_arch_post.h) doesn't work right without
that cast. I will, however, remove the cast in the header anyway and
rather add one in that place.

Jan

_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge
Re: [Xen-merge] questions (resend) [ In reply to ]
On 22 Dec 2005, at 10:28, Jan Beulich wrote:

> I actually disagree after a second inspection: At least the use in the
> call to add_memory_region() (in
> include/asm-i386/mach-xen/setup_arch_post.h) doesn't work right without
> that cast. I will, however, remove the cast in the header anyway and
> rather add one in that place.

Duh, I missed that one (only looked at the ones in setup.c). Yeah,
that's exactly the one that caused the cast to get added. Moving the
cast in-place for that one usage sounds a good idea.

-- Keir


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