Gregory Haskins wrote: > Andi Kleen wrote: > >> On Wed, Apr 01, 2009 at 08:03:49AM -0400, Gregory Haskins wrote: >> >> >>> Andi Kleen wrote: >>> >>> >>>> Gregory Haskins <ghaskins@xxxxxxxxxx> writes: >>>> >>>> What might be useful is if you could expand a bit more on what the high level >>>> use cases for this. >>>> >>>> Questions that come to mind and that would be good to answer: >>>> >>>> This seems to be aimed at having multiple VMs talk >>>> to each other, but not talk to the rest of the world, correct? >>>> Is that a common use case? >>>> >>>> >>>> >>> Actually we didn't design specifically for either type of environment. >>> >>> >> But surely you must have some specific use case in mind? Something >> that it does better than the various methods that are available >> today. Or rather there must be some problem you're trying >> to solve. I'm just not sure what that problem exactly is. >> >> > Performance. We are trying to create a high performance IO infrastructure. > Actually, I should also state that I am interested in enabling some new kinds of features based on having in-kernel devices like this. For instance (and this is still very theoretical and half-baked), I would like to try to support RT guests. [adding linux-rt-users] I think one of the things that we need in order to do that is being able to convey vcpu priority state information to the host in an efficient way. I was thinking that a shared-page per vcpu could have something like "current" and "theshold" priorties. The guest modifies "current" while the host modifies "threshold". The guest would be allowed to increase its "current" priority without a hypercall (after all, if its already running presumably it is already of sufficient priority that the scheduler). But if the guest wants to drop below "threshold", it needs to hypercall the host to give it an opportunity to schedule() a new task (vcpu or not). The host, on the other hand, could apply a mapping so that the guests priority of RT1-RT99 might map to RT20-RT30 on the host, or something like that. We would have to take other considerations as well, such as implicit boosting on IRQ injection (e.g. the guest could be in HLT/IDLE when an interrupt is injected...but by virtue of injecting that interrupt we may need to boost it to (guest-relative) RT50). Like I said, this is all half-baked right now. My primary focus is improving performance, but I did try to lay the groundwork for taking things in new directions too..rt being an example. Hope that helps! -Greg
Attachment:
signature.asc
Description: OpenPGP digital signature
