| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ia64-devel
RE: [Xen-ia64-devel] vTLB support
Hi Eddie --
You may already understand this but I will explain it
for others on the list. This describes the current
implementation...
The shared page is at a fixed virtual address in the
Xen virtual address space (0xf200000000000000).
The page is persistent for each domain; there is a
different physical page backing this virtual address
for each domain. The mapping is switched at domain
switch time. Currently the mapping is placed in a
physical TR; this need not be the case as long as it
is guaranteed that Xen never delivers/injects a TLB
miss to the guest for this address.
The shared page contains the virtual privileged state
for the domain (e.g. virtual cr.ifa). Some of this
state may be written by the domain and some may not.
(Both writable and non-writable are currently on the
same page so the read-only is not enforced; I need
to fix this at some point. The two parts are separated
in the current code only by a comment.)
The TR_ENTRY itr/dtr's are software constructs only;
they can only be written by a privileged (and therefore
trapped and emulated) itr instruction. The value
must be validated by Xen. These TR_ENTRYs are never
placed in a physical TR so (I think) no overlap need
be checked. (If a mapping in a TR overlaps with a
mapping in the TLB, a machine check occurs so Xen
needs to ensure this doesn't happen.)
---
I do think it is a good idea to share code where possible,
but expect that some things will have to be different as well.
Dan
> -----Original Message-----
> From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf
> Of Dong, Eddie
> Sent: Monday, May 02, 2005 11:02 PM
> To: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-ia64-devel] vTLB support
>
> Dan:
> I am worring about the vTLB support base on current
> implementation.
> The current implementation as you mentioned use:
> TR_ENTRY itrs[NITRS];
> TR_ENTRY dtrs[NDTRS];
> TR_ENTRY itlb;
> TR_ENTRY dtlb;
> and you mentioned to use machine TR for hypercall shared page.
>
> I am thinking the way to support foreignmap and mmio shared page
> base on current implementation. The foreignmap is probably per domain
> 16GB memory space map. If you want to add another variable like
> "TR_ENTRY foreignmap[MAX_DOMAINS]" and "TR_ENTRY
> mmio_shared_page[MAX_DOMAINS], I think the guest TLB walk will be too
> expansive. Same situation for TC insert and purge. (BTW,
> current code is
> not checking for the overlap of guest TLB at time of insert.)
> If you are willing, my implementation can be one solution. I
> mainly use a HASH+collision chain for vTLB and VHPT. vTLB and VHPT use
> same code but different instance. If you want to use global VHPT, you
> can just create one instance for that. We don't need to worry
> about how
> to support both.
> Eddie
>
> _______________________________________________
> Xen-ia64-devel mailing list
> Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-ia64-devel
>
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
|
|
| |
|
Home