Hi, I saw that all the I/O regions which are marked as E820_RAM are being mapped to dom_io as writeable pages, I don''t know the architecture exactly but I was wondering about these things. 1. How share_xen_page_with_guest() works? does it maps those pages the same pseudo physical addresses or the virtual ones? would you mind to explain like what kind of addresses the e820 contains? are they real machine addresses? 2. What pieces of code are running in the dom_io context? or else, why would we want to map those addresses?? Thanks, Eric. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
It’s the opposite that all the regions not marked as E820_RAM fallen into dom_io’s case. :-) For share_xen_page_with_guest, it simply transfers the ownership to target domain, and there’s nothing to do with pseudo physical or virtual address within it. Later the machine frame of shared xen pages are placed into some shared area or requested by guest to be mapped into guest’s virtual address space. For the e820 table, it definitely contains machine address if you mean the real one provided by BIOS. Normally IO regions under max memory page are also bound with a page info struct, and then those page_info structures are tracked/counted by dom_io. This is a neat way to manage these IO regions like a normal memory frame, since IO regions may be also granted to driver domains. Thanks, Kevin ________________________________ From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Eric Benton Sent: 2006年11月6日 22:57 To: xen-devel@lists.xensource.com Subject: [Xen-devel] Dom I/O Mappings Hi, I saw that all the I/O regions which are marked as E820_RAM are being mapped to dom_io as writeable pages, I don''t know the architecture exactly but I was wondering about these things. 1. How share_xen_page_with_guest() works? does it maps those pages the same pseudo physical addresses or the virtual ones? would you mind to explain like what kind of addresses the e820 contains? are they real machine addresses? 2. What pieces of code are running in the dom_io context? or else, why would we want to map those addresses?? Thanks, Eric. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi Kevin,
Actually it's the regions which are marked E820_RAM that are being mapped to
dom_io, you can see the code at arch_init_memory()...
...
for ( i = 0, pfn = 0; i < e820.nr_map; i++ )
{
if ( e820.map[i].type != E820_RAM )
continue;
/* Every page from cursor to start of next RAM region is I/O. */
rstart_pfn = PFN_UP(e820.map[i].addr);
rend_pfn = PFN_DOWN(e820.map[i].addr + e820.map[i].size);
for ( ; pfn < rstart_pfn; pfn++ )
{
BUG_ON(!mfn_valid(pfn));
share_xen_page_with_guest(
mfn_to_page(pfn), dom_io, XENSHARE_writable);
...
...
...mfn_to_page(pfn)
Can you please explain what do you mean by "transfer ownership"? does
this
related to the grant tables?
And what do you mean by "normal memory frames?" and does the page_info
struct represents an actual memor page (4kb, 2mb)? so why is the distinction
between pages and mfns?
The things are confusing me the most when I'm trying to comprehand the
source are those like this: "mfn_to_page(pfn)" , the functions is
being
called mfn_to_page, but the variable name is "pfn" (I know it's a
mfn
actually :) because the e820 contains machine addresses)
Thanks,
Eric.
On 11/6/06, Tian, Kevin <kevin.tian@intel.com>
wrote:>
> It's the opposite that all the regions not marked as E820_RAM fallen
into
> dom_io's case. J For share_xen_page_with_guest, it simply transfers the
> ownership to target domain, and there's nothing to do with pseudo
physical
> or virtual address within it. Later the machine frame of shared xen pages
> are placed into some shared area or requested by guest to be mapped into
> guest's virtual address space.
>
>
>
> For the e820 table, it definitely contains machine address if you mean the
> real one provided by BIOS.
>
>
>
> Normally IO regions under max memory page are also bound with a page info
> struct, and then those page_info structures are tracked/counted by dom_io.
> This is a neat way to manage these IO regions like a normal memory frame,
> since IO regions may be also granted to driver domains.
>
>
>
> Thanks,
>
> Kevin
>
>
> ------------------------------
>
> *From:* xen-devel-bounces@lists.xensource.com [mailto:
> xen-devel-bounces@lists.xensource.com] *On Behalf Of *Eric Benton
> *Sent:* 2006年11月6日 22:57
> *To:* xen-devel@lists.xensource.com
> *Subject:* [Xen-devel] Dom I/O Mappings
>
>
>
> Hi,
>
> I saw that all the I/O regions which are marked as E820_RAM are being
> mapped to dom_io as writeable pages, I don't know the architecture
exactly
> but I was wondering about these things.
>
> 1. How share_xen_page_with_guest() works? does it maps those pages the
> same pseudo physical addresses or the virtual ones? would you mind to
> explain like what kind of addresses the e820 contains? are they real
machine
> addresses?
>
> 2. What pieces of code are running in the dom_io context? or else, why
> would we want to map those addresses??
>
> Thanks,
> Eric.
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Ok, I see it now.... On 11/7/06, Eric Benton <benton71@gmail.com> wrote:> > Hi Kevin, > > Actually it''s the regions which are marked E820_RAM that are being mapped > to dom_io, you can see the code at arch_init_memory()... > > ... > for ( i = 0, pfn = 0; i < e820.nr_map; i++ ) > { > if ( e820.map[i].type != E820_RAM ) > continue; > /* Every page from cursor to start of next RAM region is I/O. */ > rstart_pfn = PFN_UP(e820.map[i].addr); > rend_pfn = PFN_DOWN(e820.map[i].addr + e820.map[i].size); > for ( ; pfn < rstart_pfn; pfn++ ) > { > BUG_ON(!mfn_valid(pfn)); > share_xen_page_with_guest( > mfn_to_page(pfn), dom_io, XENSHARE_writable); > ... > ... > ...mfn_to_page(pfn) > > Can you please explain what do you mean by "transfer ownership"? does this > related to the grant tables? > And what do you mean by "normal memory frames?" and does the page_info > struct represents an actual memor page (4kb, 2mb)? so why is the distinction > between pages and mfns? > > The things are confusing me the most when I''m trying to comprehand the > source are those like this: "mfn_to_page(pfn)" , the functions is being > called mfn_to_page, but the variable name is "pfn" (I know it''s a mfn > actually :) because the e820 contains machine addresses) > > Thanks, > Eric. > > On 11/6/06, Tian, Kevin <kevin.tian@intel.com> wrote: > > > > It''s the opposite that all the regions not marked as E820_RAM fallen > > into dom_io''s case. J For share_xen_page_with_guest, it simply transfers > > the ownership to target domain, and there''s nothing to do with pseudo > > physical or virtual address within it. Later the machine frame of shared xen > > pages are placed into some shared area or requested by guest to be mapped > > into guest''s virtual address space. > > > > > > > > For the e820 table, it definitely contains machine address if you mean > > the real one provided by BIOS. > > > > > > > > Normally IO regions under max memory page are also bound with a page > > info struct, and then those page_info structures are tracked/counted by > > dom_io. This is a neat way to manage these IO regions like a normal memory > > frame, since IO regions may be also granted to driver domains. > > > > > > > > Thanks, > > > > Kevin > > > > > > ------------------------------ > > > > *From:* xen-devel-bounces@lists.xensource.com [mailto: > > xen-devel-bounces@lists.xensource.com] *On Behalf Of *Eric Benton > > *Sent:* 2006年 11月6 日 22:57 > > *To:* xen-devel@lists.xensource.com > > *Subject:* [Xen-devel] Dom I/O Mappings > > > > > > > > Hi, > > > > I saw that all the I/O regions which are marked as E820_RAM are being > > mapped to dom_io as writeable pages, I don''t know the architecture exactly > > but I was wondering about these things. > > > > 1. How share_xen_page_with_guest() works? does it maps those pages the > > same pseudo physical addresses or the virtual ones? would you mind to > > explain like what kind of addresses the e820 contains? are they real machine > > addresses? > > > > 2. What pieces of code are running in the dom_io context? or else, why > > would we want to map those addresses?? > > > > Thanks, > > Eric. > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel