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@xxxxxxxxxxxxxxxxxxx
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Eric Benton
Sent: 2006年11月6日
22:57
To: xen-devel@xxxxxxxxxxxxxxxxxxx
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.
