Adding the bhyve guys. El 29/10/14 a les 6.19, Andy Lutomirski ha escrit: > Here's a draft CommonHV spec. It's also on github: > > https://github.com/amluto/CommonHV > > So far, this provides a two-way RNG interface, a way to detect it, and > a way to detect other hypervisor leaves. The latter is because, after > both the enormous public thread and some private discussions, it seems > that detection of existing CPUID paravirt leaves is annoying and > inefficient. If we're going to define some cross-vendor CPUID leaves, > it seems like it would be useful to offer a way to quickly enumerate > other leaves. > > I've been told the AMD intends to update their manual to match Intel's > so that hypervisors can use the entire 0x4F?????? CPUID range. I have > intentionally not fixed an MSR value for the RNG because the range of > allowed MSRs is very small in both the Intel and AMD manuals. If any > given hypervisor wants to ignore that small range and advertise a > higher-numbered MSR, it is welcome to, but I don't want to codify > something that doesn't comply with the manuals. > > Here's the draft. Comments? To the people who work on various > hypervisors: Would you implement this? Do you like it? Is there > anything, major or minor, that you'd like to see changed? Do you > think that this is a good idea at all? > > I've tried to get good coverage of various hypervisors. There are > Hyper-V, VMWare, KVM, and Xen people on the cc list. > > Thanks, > Andy > > > > CommonHV, a common hypervisor interface > ======================================= > > This is CommonHV draft 1. > > The CommonHV specification is Copyright (c) 2014 Andrew Lutomirski. > > Licensing will be determined soon. The license is expected to be extremely > liberal. I am currently leaning towards CC-BY-SA for the specification and > an explicit license permitting anyone to implement the specification > with no restrictions whatsoever. > > I have not patented, nor do I intend to patent, anything required to implement > this specification. I am not aware of any current or future intellectual > property rights that would prevent a royalty-free implementation of > this specification. > > I would like to find a stable, neutral steward of this specification > going forward. Help with this would be much appreciated. > > Scope > ----- > > CommonHV is a simple interface for communication > between hypervisors and their guests. > > CommonHV is intended to be very simple and to avoid interfering with > existing paravirtual interfaces. To that end, its scope is limited. > CommonHV does only two types of things: > > * It provides a way to enumerate other paravirtual interfaces. > * It provides a small, extensible set of paravirtual features that do not > modify or replace standard system functionality. > > For example, CommonHV does not and will not define anything related to > interrupt handling or virtual CPU management. > > For now, CommonHV is only applicable to the x86 platform. > > Discovery > --------- > > A CommonHV hypervisor MUST set the hypervisor bit (bit 31 in CPUID.1H.0H.ECX) > and provide the CPUID leaf 4F000000H, containing: > > * CPUID.4F000000H.0H.EAX = max_commonhv_leaf > * CPUID.4F000000H.0H.EBX = 0x6D6D6F43 > * CPUID.4F000000H.0H.ECX = 0x56486E6F > * CPUID.4F000000H.0H.EDX = 0x66746e49 > > EBX, ECX, and EDX form the string "CommonHVIntf" in little-endian ASCII. > > max_commonhv_leaf MUST be a number between 0x4F000000 and 0x4FFFFFFF. It > indicates the largest leaf defined in this specification that is provided. > Any leaves described in this specification with EAX values that exceed > max_commonhv_leaf MUST be handled by guests as though they contain > all zeros. > > CPUID leaf 4F000001H: hypervisor interface enumeration > ------------------------------------------------------ > > If max_commonhv_leaf >= 0x4F000001, CommonHV provides a list of tuples > (location, signature). Each tuple indicates the presence of another > paravirtual interface identified by the signature at the indicated > CPUID location. It is expected that CPUID.location.0H will have > (EBX, ECX, EDX) == signature, although whether this is required > is left to the specification associated with the given signature. > > If the list contains N tuples, then, for each 0 <= i < N: > > * CPUID.4F000001H.i.EBX, CPUID.4F000001H.i.ECX, and CPUID.4F000001H.i.EDX > are the signature. > * CPUID.4F000001H.i.EAX is the location. > > CPUID with EAX = 0x4F000001 and ECX >= N MUST return all zeros. > > To the extent that the hypervisor prefers a given interface, it should > specify that interface earlier in the list. For example, KVM might place > its "KVMKVMKVM" signature first in the list to indicate that it should be > used by guests in preference to other supported interfaces. Other hypervisors > would likely use a different order. > > The exact semantics of the ordering of the list is beyond the scope of > this specification. > > CPUID leaf 4F000002H: miscellaneous features > -------------------------------------------- > > CPUID.4F000002H.EAX is nonzero if the CommonHV RNG interface is available. > CPUID.4F000002H.EBX, CPUID.4F000002H.ECX, and CPUID.4F000002H.EDX are reserved > and must be zero in hypervisors compliant with this version of the CommonHV > specification. > > ### CommonHV RNG > > If CPUID.4F000002H.EAX is nonzero, then it contains an MSR index used to > communicate with a hypervisor random number generator. This MSR is > referred to as MSR_COMMONHV_RNG. > > rdmsr(MSR_COMMONHV_RNG) returns a 64-bit best-effort random number. If the > hypervisor is able to generate a 64-bit cryptographically secure random number, > it SHOULD return it. If not, then the hypervisor SHOULD do its best to return > a random number suitable for seeding a cryptographic RNG. > > A guest is expected to read MSR_COMMONHV_RNG several times in a row. > The hypervisor SHOULD return different values each time. > > rdmsr(MSR_COMMONHV_RNG) MUST NOT result in an exception, but guests MUST > NOT assume that its return value is indeed secure. For example, a hypervisor > is free to return zero in response to rdmsr(MSR_COMMONHV_RNG). > > wrmsr(MSR_COMMONHV_RNG) offers the hypervisor up to 64 bits of entropy. > The hypervisor MAY use it as it sees fit to improve its own random number > generator. A hypervisor SHOULD make a reasonable effort to avoid making > values written to MSR_COMMONHV_RNG visible to untrusted parties, but > guests SHOULD NOT write sensitive values to wrmsr(MSR_COMMONHV_RNG). > > A hypervisor is free to ignore wrmsr(MSR_COMMONHV_RNG), but wrmsr to > MSR_COMMONHV_RNG MUST NOT result in an exception. > > Note that the CommonHV RNG is not intended to replace stronger, asynchronous > paravirtual random number generator interfaces. It is intended primarily > for seeding guest RNGs early in boot. > > Future extension > ---------------- > > CPUID leaves beyond those defined in this version of the CommonHV specification > should be ignored by guests written for this version of the specification. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel > -- 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
