[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] Dom I/O Mappings
- To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
- From: "Eric Benton" <benton71@xxxxxxxxx>
- Date: Tue, 7 Nov 2006 10:41:21 +0200
- Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
- Delivery-date: Tue, 07 Nov 2006 00:41:39 -0800
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=lGOThasE3KYZlHJu86jRMvYq7zMokXHVXkN6CPF4YT3fXVDO+pDTtpMc3NI2YcMDzGIveuR8pdeCa2TrkQFxsyuuZNDVldbvdjLxE3g7OYZXPLtIXSZcFP3+YZuxpDYAUhcYokwvf4rV3I0Ukvu16GhjtyYYQMy5UVH98yIbW+s=
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
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@xxxxxxxxx> 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
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|