On Friday 10 April 2009 04:13:26 Liu Yu-B13201 wrote: > > > > > But there is one thing I haven't thought through. > > > That is how should we handle guest kernel mapping (tid=0) > > after apply this trick? > > > As it's supposed to share by all PIDs. > > > Any suggestion? > > > > Hmm, that's a good question. > > > > On e500, you could use the PID1 register, but that doesn't appear in > > 440, and won't be available in future implementations anyways. > > > > In general, I don't know... I'm reluctant to sacrifice the other PID > > hack we use, which allows us to flip between guest user and > > guest kernel > > without flushing the TLB. Since that's probably way more frequent than > > context switches, maybe it's worth suffering the TLB flush on context > > switch. > > > > It would be OK to map gPID 0 to another arbitrary host PID, except we > > need copy_to_user() to work in the guest. To elaborate, if we had this > > address space: > > > > 0 0xc 0xf > > | gTID 3 | gTID 0 | gPID=3 > > > > we could implement it like this: > > > > 0 0xc 0xf > > | sTID 27 | sTID 9 | > > > > and switch sPID between 9 and 27 when jumping between guest user and > > guest kernel. However, if we're in the guest kernel (sTID=9 mappings) > > with sPID=9, copy_to_user() will fault because sTID=27 mappings aren't > > visible. > > > > When those faults occur, we could create a new userspace mapping with > > sTID 9, aliasing the sTID 27 mappings. Would that work? Odds are we > > won't get more than 1 or 2 of these at a time, but we'd need to track > > these mappings so that guest updates to the sTID=27 mappings > > also modify > > or flush our extra sTID=9 mappings. > > > > That might be the only complexity, and might not be that bad. I don't > > know, what do you think? If e500 can selectively flush by PID, maybe > > that's better, but 440 can't so we'd want some scheme like I > > described. > > > > E500 cannot selectively flush by PID either... Seems e500mc could. > It's a good idea that use PID1 to map guest kernel's stid for e500, > but there is another problem that how to handle guest mapping access > privilege. > > I think we should apart this problem into two to make it clear. > 1). how to handle guest share mapping(tid=0). > 2). how to handle guest mapping without user access privilege. > What I mean is there may be non-zero tid mapping without user access > privilege, > Although this seems don't exist in Linux. Yeah, I can't think of how this would be used. Maybe some microkernel? I don't think I want to worry about this case right now... > I have two different ways in mind to solve it. > > 1. utilize e500 PID1 as you mentioned > We can set PID1 when enter guest kernel and clear PID1 when enter guest > userspace. > > Pro. > this method can minimize TLB flush. > Con. > it's based on the assumption that all guest access limited mappings > always have tid=0, > or non-zero mappings always have user access bits. > It's fine for Linux but not sure for other OSes. Con: - Only works on e500v1/v2. :) But that's where the immediate need is, and I don't see a better general-purpose solution, so I think it's OK. That reminds me... Rahul, how does NetBSD handle copy_to_user() from AS=0, since userspace TLB mappings have TS=1? (I tried to find source myself, but it looks like the only port was done by Wasabi Systems, which apparently abruptly closed down recently.) Does it just fault in a new TLB entry as needed? -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
