linux-kernel - Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <46EED256.40801@goop.org>
Date:	Mon, 17 Sep 2007 12:15:34 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Anthony Liguori <aliguori@...ibm.com>
CC:	"Nakajima, Jun" <jun.nakajima@...el.com>,
	kvm-devel@...ts.sourceforge.net, Avi Kivity <avi@...ranet.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure

Anthony Liguori wrote:
> Nakajima, Jun wrote:
>>> I don't understand the purpose of returning the max leaf.  Who is that
>>> information useful for?
>>>     
>>
>> Well, this is the key info to the user of CPUID. It tells which leaves
>> are valid to use. Otherwise, the user cannot tell whether the results of
>> CPUID.0x4000000N are valid or not (i.e. junk). BTW, this is what we are
>> doing on the native (for the leaf 0, 0x80000000, for example). The fact
>> that Xen returns 0x40000002 means it only uses 3 leaves today.   
>
> Then it's just a version ID.  You pretty much have to treat it as a
> version id because if it returns 0x4000 0003 and you only know what
> 0002 is, then you can't actually use it.

Yeah.  It's the way all the other cpuid leaf/level stuff works, so it's
reasonable to do the same thing here.  The question it helps answer is
"I understand leaf 33, does the [v]CPU?".

> I much prefer the current use of CPUID in KVM.  If 1000 returns the
> KVM signature, then 1001 *must* be valid and contain a set of feature
> bits.  If we wish to use additional CPUID leaves in the future, then
> we can just use a feature bit.  The real benefit to us is that we can
> use a discontiguous set of leaves whereas the Xen approach is forced
> to use a linear set (at least for the result to be meaningful).

Well, its also what the CPU itself does.  The feature bits tend to
relate to specific CPU features rather than CPUID instruction leaves. 
The features themselves may also have corresponding leaves, but that's
secondary.  IOW, if feature bit X is set, it may use leaf 0x4000101f,
but that doesn't mean leaves 0x40001001-1f are necessarily defined.

> I'm starting to lean toward just using 0000.  If for no other reason
> than the hypercall space is unsharable.

Well, it could be, but it would take affirmative action on the guest's
part.  If there's feature bits for each supported hypercall interface,
then you could have a magic MSR to select which interface you want to
use now.  That would allow a generic-interface-using guest to probe for
the generic interface at cpuid leaf 0x40001000, use 40001001 to
determine whether the hypercall interface is available, 4000100x to find
the base of the magic msrs, and write appropriate msr to set the desired
hypercall style (and all this can be done without using vmcall, so it
doesn't matter that hypercall interface is initially established).

    J
-
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/