> Am 22.04.2015 um 17:53 schrieb Eduardo Habkost <[email protected]>: > >> On Wed, Apr 22, 2015 at 12:38:11AM +0200, Alexander Graf wrote: >> The AMD Opteron family has different xlevel levels depending on the >> generation. I looked up Gen1, Gen2 and Gen3 hardware and adapted the >> levels according to real silicon. >> >> The reason this came up is that there is a sanity check in KVM making >> sure that SVM is only used when xlevel is high enough. Using real >> hardware levels, they now are. > > As noted in the reply to the previous patch: if you increase xlevel you are > now > reporting new CPUID leaves as available. I still don't see any reason to start > reporting new CPUID leaves as available if they are returning useless data > (that doesn't match real hardware). > > For reference, here are the new CPUID leaves you are introducing (and will > return all-zeroes): > > For Opteron_G[123]: > * CPUID Fn8000_0009 Reserved > * CPUID Fn8000_000A SVM Revision and Feature Identification (supported by > QEMU) > * CPUID Fn8000_00[18:0B] Reserved > > For Opteron_G3: > * CPUID Fn8000_0019_EAX TLB 1GB Page Identifiers > * CPUID Fn8000_0019_EBX TLB 1GB Page Identifiers > * CPUID Fn8000_0019_E[D,C]X Reserved > * CPUID Fn8000_001A_EAX Performance Optimization Identifiers > * CPUID Fn8000_001A_E[D,C,B]X Reserved > > The reserved bits look safe, but we can't be 100% sure unless we confirm that > real hardware is returning zeroes on all the reserved bits. If real hardware > return some data, we don't know what exactly that data means (and what > all-zeroes would mean) until AMD documents it. > > For L1 and L2 1GB page TLB info, all-zeroes means "TLB disabled". > > The Performance Optimization Identifier leaf will now be available, and will > return 0 on the following bits: > > * "MOVU: MOVU SSE (multimedia) instructions are more efficient and should be > preferred to SSE (multimedia) MOVL/MOVH. MOVUPS is more efficient than > MOVLPS/MOVHPS. MOVUPD is more efficient than MOVLPD/MOVHP"; > * "FP128: 128-bit SSE (multimedia) instructions are executed with full-width > internal operations and pipelines rather than decomposing them into internal > 64-bit suboperations. This may impact how soft- ware performs instruction > selection and scheduling." > > There's a simple way to avoid exposing additional useless information to > guests: just return 0x8000000A on xlevel. 0x8000000A is the CPUID leaf you > need > for SVM, the others are unrelated to SVM.
I don't think creating a more Frankenstein cpu definition is superior over unset bits in the new leafs. How about I add support for the new leafs and fill the bits with the same information as real hardware? Alex
