Re: [Xen-devel] [PATCH 15/16] Infrastructure for manipulating 3-level event channel pages

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Mon, 2013-02-04 at 14:06 +0000, Jan Beulich wrote:
> >>> On 04.02.13 at 14:45, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> > On Mon, 2013-02-04 at 11:29 +0000, Jan Beulich wrote:
> >> >> 
> >> >> So this alone already is up to 16 pages per guest, and hence a
> >> >> theoretical maximum of 512k pages, i.e. 2G mapped space.
> >> > 
> >> > That's given a theoretical 32k guests? Ouch. It also ignores the need
> >> > for other global mappings.
> >> > 
> >> > on the flip side only a minority of domains are likely to be using the
> >> > extended scheme, and I expect even those which are would not be using
> >> > all 16 pages, so maybe we can fault them in on demand as we bind/unbind
> >> > evtchns.
> >> > 
> >> > Where does 16 come from? How many pages to we end up with at each level
> >> > in the new scheme?
> >> 
> >> Patch 11 defines EVTCHN_MAX_L3_PAGES to be 8, and we've
> >> got two of them (pending and mask bits).
> >> 
> >> > Some levels of the trie are per-VCPU, did you account for that already
> >> > in the 2GB?
> >> 
> >> No, I didn't, as it would only increase the number, and make
> >> the math less clear.
> >> 
> >> >>  The
> >> >> global page mapping area, however, is only 1Gb in size on x86-64
> >> >> (didn't check ARM at all)...
> >> > 
> >> > There isn't currently a global page mapping area on 32-bit ARM (I
> >> > suppose we have avoided them somehow...) but obviously 2G would be a
> >> > problem in a 4GB address space.
> >> > 
> >> > On ARM we currently have 2G for domheap mappings which I suppose we
> >> > would split if we needed a global page map
> >> > 
> >> > These need to be global so we can deliver evtchns to VCPUs which aren't
> >> > running, right? I suppose mapping on demand (other than for a running
> >> > VCPU) would be prohibitively expensive.
> >> 
> >> Likely, especially for high rate ones.
> >> 
> >> > Could we make this space per-VCPU (or per-domain) by saying that a
> >> > domain maps its own evtchn pages plus the required pages from other
> >> > domains with which an evtchn is bound? Might be tricky to arrange
> >> > though, especially with the per-VCPU pages and affinity changes?
> >> 
> >> Even without that trickiness it wouldn't work I'm afraid: In various
> >> cases we need to be able to raise the events out of context (timer,
> >> IRQs from passed through devices).
> >> 
> >> Jan
> > 
> > So I come up with following comment on the 3-level registration
> > interface (not specific to __map_l3_array() function).
> > 
> > /*
> >  * Note to 3-level event channel users:
> >  * Only enable 3-level event channel for Dom0 or driver domains, because
> >  * 3-level event channels consumes (16 + nr_vcpus pages) global mapping
> >  * area in Xen.
> >  */
> 
> So you intended to fail the request for other guests? That's fine
> with me in principle, but how do you tell a driver domain from an
> "ordinary" one?
> 

I can't at the moment. I'm investigating on adding a flag in domain
creation process.


Wei.

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel