Xen devel - Nov 2005 - Calling __va() in a x86_64 Dom0 module

I am trying to get a module working under x86_64 Dom0. The module is
used to communicate between the Linux OS running on the ES7000 and the
external service processor. The module as part of its setup parses the
OEM table to reference some information present there. It gets the
address of the OEM table using acpi_get_firmware_table(). Then the
address is converted to a virtual address using __va() before it is
referenced.

When building the module against 2.6.12-dom0, the __va() function that
is called the x86_64 one. When I try accessing the VA of the OEM table,
I am getting a page fault. The PA is 0x26e0400.  So I patched the module
to use Xen''s __va() function. Now the page fault does not happen but
when the table is parsed the information I am looking for is not
present. 

Am I doing anything wrong here? Am I not supposed to touch this region
of memory from Dom0? Or is there a hypercall that I should be using?

BTW, this module works perfectly under plain vanilla x86_64 Linux.

Thanks,
Aravindh

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

Puthiyaparambil, Aravindh wrote:
> I am trying to get a module working under x86_64 Dom0. The module is
> used to communicate between the Linux OS running on the ES7000 and the
> external service processor. The module as part of its setup parses the
> OEM table to reference some information present there. It gets the
> address of the OEM table using acpi_get_firmware_table(). Then the
> address is converted to a virtual address using __va() before it is
> referenced.
> 
> When building the module against 2.6.12-dom0, the __va() function that
> is called the x86_64 one. When I try accessing the VA of the OEM
> table, I am getting a page fault. The PA is 0x26e0400.  So I patched
> the module to use Xen''s __va() function. Now the page fault does
not
> happen but when the table is parsed the information I am looking for
> is not present.
XenLinux runs on _guest_ (or pseudo) physical. You need to map machine
physical. 
> 
> Am I doing anything wrong here? Am I not supposed to touch this region
> of memory from Dom0? Or is there a hypercall that I should be using?
You should be able to use ioremap() unless you need to touch the table
very early at initialization time. 
> 
> BTW, this module works perfectly under plain vanilla x86_64 Linux.
> 
> Thanks,
> Aravindh
> 
Jun
---
Intel Open Source Technology Center

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

Jun,

The ioremap() function did the trick. 

Thanks,
Aravindh
> -----Original Message-----
> From: Nakajima, Jun [mailto:jun.nakajima@intel.com]
> Sent: Wednesday, November 02, 2005 2:17 AM
> To: Puthiyaparambil, Aravindh; xen-devel
> Cc: Forsgren, Garry
> Subject: RE: [Xen-devel] Calling __va() in a x86_64 Dom0 module
> 
> Puthiyaparambil, Aravindh wrote:
> > I am trying to get a module working under x86_64 Dom0. The module is
> > used to communicate between the Linux OS running on the ES7000 and
the
> > external service processor. The module as part of its setup parses
the
> > OEM table to reference some information present there. It gets the
> > address of the OEM table using acpi_get_firmware_table(). Then the
> > address is converted to a virtual address using __va() before it is
> > referenced.
> >
> > When building the module against 2.6.12-dom0, the __va() function
that
> > is called the x86_64 one. When I try accessing the VA of the OEM
> > table, I am getting a page fault. The PA is 0x26e0400.  So I patched
> > the module to use Xen''s __va() function. Now the page fault
does not
> > happen but when the table is parsed the information I am looking for
> > is not present.
> XenLinux runs on _guest_ (or pseudo) physical. You need to map machine
> physical.
> 
> >
> > Am I doing anything wrong here? Am I not supposed to touch this
region
> > of memory from Dom0? Or is there a hypercall that I should be using?
> You should be able to use ioremap() unless you need to touch the table
> very early at initialization time.
> 
> >
> > BTW, this module works perfectly under plain vanilla x86_64 Linux.
> >
> > Thanks,
> > Aravindh
> >
> 
> Jun
> ---
> Intel Open Source Technology Center
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> I am trying to get a module working under x86_64 Dom0. The 
> module is used to communicate between the Linux OS running on 
> the ES7000 and the external service processor. The module as 
> part of its setup parses the OEM table to reference some 
> information present there. It gets the address of the OEM 
> table using acpi_get_firmware_table(). Then the address is 
> converted to a virtual address using __va() before it is referenced.
> 
> When building the module against 2.6.12-dom0, the __va() 
> function that is called the x86_64 one. When I try accessing 
> the VA of the OEM table, I am getting a page fault. The PA is 
> 0x26e0400.  So I patched the module to use Xen''s __va() 
> function. Now the page fault does not happen but when the 
> table is parsed the information I am looking for is not present. 
> 
> Am I doing anything wrong here? Am I not supposed to touch 
> this region of memory from Dom0? Or is there a hypercall that 
> I should be using?
dom0 only has the bottom 1MB of machine memory mapped, so if you want to
access outside of this you''ll need to map it yourself using
direct_remap_pfn_range. 

Ian
 

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

> dom0 only has the bottom 1MB of machine memory mapped, so if you want
to
> access outside of this you''ll need to map it yourself using
> direct_remap_pfn_range.
Ian,

I was able to use ioremap() to gain access to the piece of memory. Is
this a reliable method or should I be using direct_remap_pfn_range()?

Thanks,
Aravindh

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

> I was able to use ioremap() to gain access to the piece of 
> memory. Is this a reliable method or should I be using 
> direct_remap_pfn_range()?
direct_remap_pfn_range is called by ioremap -- you''re indeed correct to
be using the latter.

Best,
Ian

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