On 01/26/2011 05:45 PM, Glauber Costa wrote:
On Wed, 2011-01-26 at 17:17 +0200, Avi Kivity wrote: > On 01/26/2011 02:20 PM, Glauber Costa wrote: > > On Wed, 2011-01-26 at 13:13 +0200, Avi Kivity wrote: > > > On 01/24/2011 08:06 PM, Glauber Costa wrote: > > > > As a proof of concept to KVM - Kernel Virtual Memory, this patch > > > > implements wallclock grabbing on top of it. At first, it may seem > > > > as a waste of work to just redo it, since it is working well. But over the > > > > time, other MSRs were added - think ASYNC_PF - and more will probably come. > > > > After this patch, we won't need to ever add another virtual MSR to KVM. > > > > > > > > > > So instead of adding MSRs, we're adding area identifiers. What did we gain? > > > > * No risk of namespace clashes of any kind, > > * less need for userspace coordination for feature enablement, > > That's a bug, not a feature. I don't see why. I's about feature enablement, not feature discovery.
Well, "zero userspace coordination" would be a bug, since it would remove userspace-controlled discovery. Since the userspace patches for these types of features are usually very small, "less coordination" doesn't buy us much.
> > > * size information goes together with base, allowing for extending > > structures (well, maybe I should add versioning explicitly?) > > > > We could do that as well with wrmsr, by having the size as the first > field of the structure. Usually the size isn't really interesting, > though, since you need to discover/enable the new features independently. Which structure? For msrs, we're usually going for just an u64, but of course we could change that when needed.
It's usually a physical address of a structure (together with an enable bit).
-- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
