From: "Dong Wei" <dong_wei@hp.com>
To: linux-ia64@vger.kernel.org
Subject: RE: [Linux-ia64] settings AR.k0 to ia64_iobase is wrong?
Date: Tue, 31 Jul 2001 18:57:09 +0000 [thread overview]
Message-ID: <marc-linux-ia64-105590693005970@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590693005964@msgid-missing>
AR.k0 contains the virtual address that SAL uses for the IO Port Base.
The SAL spec asks the OSes not to change this value until the IVAs are
taken over. The reason for this is that some implementation of SAL
contains the x86 BIOS code.
The AR.k0 value reported by SAL is of no use to the OSes because it is a
virtual address used by SAL only, not by the OSes. OSes get the physical
IO Port Base from the EFI GetMemoryMap call.
After the OS gets the physical IO Port base, it should apply the OS
PA-VA mapping.
Regards,
Dong Wei
Systems Architecture
Hewlett Packard
dong_wei@hp.com
(916)748-2461
> -----Original Message-----
> From: linux-ia64-admin@linuxia64.org
> [mailto:linux-ia64-admin@linuxia64.org] On Behalf Of David Mosberger
> Sent: Tuesday, July 31, 2001 11:06 AM
> To: nomura@hpc.bs1.fc.nec.co.jp
> Cc: linux-ia64@linuxia64.org
> Subject: Re: [Linux-ia64] settings AR.k0 to ia64_iobase is wrong?
>
>
> >>>>> On Tue, 31 Jul 2001 19:06:28 +0900,
> nomura@hpc.bs1.fc.nec.co.jp said:
>
> >> This isn't right. There is no way a VA->PA translation can set
> >> bit 63 so address 0x80000ffffc000000 could only be generated in
> >> physical mode, which Linux (almost) never uses. The address
> >> 0xffffc000000 is correct since Linux will access the memory range
> >> only through uncached space (region 6).
>
> Nomura> I didn't talk about VA-PA translation nor I/O memory range
> Nomura> access by linux. 'mapping' was the wrong word, I'm afraid.
>
> What I'm saying is that an address with bit 63 set is not a proper
> physical address (it's nothing that will ever show up on the physical
> address bus) and therefore cannot be addressed using virtual
> addressing. Thus, such an address is useless for Linux.
>
> Nomura> I mean ar.k0 seems to be used by SAL in physical mode and
> Nomura> setting ar.k0 to cached attribute is problematic.
>
> I don't know about SAL internals, but if SAL uses it in physical mode,
> it needs to make sure that it's accessing it in uncached mode. This
> seems to work just fine on all existing Intel and HP systems so it
> certainly seems possible.
>
> Nomura> I think setting bit63 to 1 (i.e. physical mode uncached) is
> Nomura> better and safer solution than just putting cached attribute
> Nomura> physical address in ar.k0, unless anyone or any part of code
> Nomura> suffers from the bit.
>
> No, setting bit 63 is not a solution. k0 must contain the physical
> base address of the legacy I/O space, no more, no less.
>
> --david
>
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
>
next prev parent reply other threads:[~2001-07-31 18:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-31 6:36 [Linux-ia64] settings AR.k0 to ia64_iobase is wrong? nomura
2001-07-31 8:17 ` David Mosberger
2001-07-31 10:06 ` nomura
2001-07-31 18:06 ` David Mosberger
2001-07-31 18:57 ` Dong Wei [this message]
2001-07-31 19:22 ` David Mosberger
2001-08-01 20:02 ` Mallick, Asit K
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-linux-ia64-105590693005970@msgid-missing \
--to=dong_wei@hp.com \
--cc=linux-ia64@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox