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$BG/(B 11$B7n(B6 $BF|(B 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.
> >
>
>