| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <46EC233B.5010209@us.ibm.com> Date: Sat, 15 Sep 2007 13:23:55 -0500 From: Anthony Liguori <aliguori@...ibm.com> To: "Nakajima, Jun" <jun.nakajima@...el.com> CC: Jeremy Fitzhardinge <jeremy@...p.org>, kvm-devel@...ts.sourceforge.net, Avi Kivity <avi@...ranet.com>, linux-kernel@...r.kernel.org Subject: Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure Nakajima, Jun wrote: > Jeremy Fitzhardinge wrote: > >> Nakajima, Jun wrote: >> >>> The hypervisor detection machanism is generic, and the signature >>> returned is implentation specific. Having a list of all hypervisor >>> signatures sounds fine to me as we are detecting vendor-specific >>> processor(s) in the native. And I don't expect the list is large. >>> >>> >>> >> I'm confused about what you're proposing. I was thinking that a >> > kernel > >> looking for the generic hypervisor interface would check for a >> > specific > >> signature at some cpuid leaf, and then go about using it from there. >> > If > >> not, how does is it supposed to detect the generic hypervisor >> > interface? > >> J >> > > I'm suggesting that we use CPUID.0x4000000Y (Y: TBD, e.g. 6) for Linux > paravirtualization. The ebx, ecx and edx return the Linux > paravirtualization features available on that hypervisor. Those features > are defined architecturally (not VMM specific). > > Like CPUID.0, CPUID.0x40000000 is used to detect the hypervisor with the > vendor identification string returned in ebx, edx, and ecx (as we are > doing in Xen). The eax returns the max leaf (which is 0x40000002 on Xen > today). I don't understand the purpose of returning the max leaf. Who is that information useful for? I like Jeremy's suggesting of starting with 0x40001000 for KVM. Xen has an established hypercall interface and that isn't going to change. However, in the future, if other Operating Systems (like the BSDs) choose to implement the KVM paravirtualization interface, then that leaves open the possibility for Xen to also support this interface to get good performance for those OSes. It's necessary to be able to support both at once if you wish to support these interfaces without user interaction. There's no tangible benefit to us to use 0x40000000. Therefore I'm inclined to lean toward making things easier for others. Regards, Anthony Liguori > And like CPUID.1, CPUID.0x40000001 returns the version number in > eax, and each VMM should be able to define a number of VMM-specific > features available in ebx, ecx, and edx returned (which are reserved, > i.e. not used in Xen today). > > Suppose we knew (i.e. tested) Xen and KVM supported Linux > paravirtualization, the Linux code does: > 1. detect Xen or KVM <the list> using CPUID.0x40000000 > 2. Check the version if necessary using CPUID.0x40000001 > 3. Check the Linux paravirtualization features available using > CPUID.0x4000000Y. > > Jun > --- > Intel Open Source Technology Center > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > kvm-devel mailing list > kvm-devel@...ts.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists