Alok Kataria wrote:
Nice idea. Problem with that is that approach is that we don't have
full control here. It probably isn't that a hard to have vmware, xen
and kvm agree here, given vmware proposes this and for xen+kvm one can
send patches. But even that you can't take for granted, see the
discussion of the "tsc-may-change-on-migration" problem.
The real big problem are other closed-source hypervisors (VirtualPC /
Hyper-V / Parallels / ...). How can we be sure they don't define that
leaf to something different?
> Also one thing to remember is, that a hypervisor can decide to not
The fudamental issue outlined above aside: Even the "ignore 0" part
isn't in the patch right now.
>> Right now both kvm and xen use the first one or two leafes (after info),
Yes.
> btw, i could only find the semantics for 0x40000001 leaf in KVM's header
pv drivers in hvm guests use that (and query very xen-specific stuff
which wouldn't make much sense in other hypervisors). It isn't in the
kernel source tree, look here instead:
http://xenbits.xensource.com/xen-3.3-testing.hg?file/19201eebab16/unmodi...
cheers,
Gerd
--
| Tony Lindgren | [PATCH 26/90] ARM: OMAP: abstract debug card setup (smc, leds) |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| Vladislav Bolkhovitin | Re: Integration of SCST in the mainstream Linux kernel |
| Jesper Juhl | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Frans Pop | svc: failed to register lockdv1 RPC service (errno 97). |
