[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 2/2] x86/cpuid: support LFENCE always serializing CPUID bit
On 14.04.2021 13:04, Roger Pau Monne wrote: > @@ -264,6 +265,38 @@ struct cpuid_policy > }; > uint32_t nc:8, :4, apic_id_size:4, :16; > uint32_t /* d */:32; > + > + uint64_t :64, :64; /* Leaf 0x80000009. */ > + uint64_t :64, :64; /* Leaf 0x8000000a - SVM rev and features. */ > + uint64_t :64, :64; /* Leaf 0x8000000b. */ > + uint64_t :64, :64; /* Leaf 0x8000000c. */ > + uint64_t :64, :64; /* Leaf 0x8000000d. */ > + uint64_t :64, :64; /* Leaf 0x8000000e. */ > + uint64_t :64, :64; /* Leaf 0x8000000f. */ > + uint64_t :64, :64; /* Leaf 0x80000010. */ > + uint64_t :64, :64; /* Leaf 0x80000011. */ > + uint64_t :64, :64; /* Leaf 0x80000012. */ > + uint64_t :64, :64; /* Leaf 0x80000013. */ > + uint64_t :64, :64; /* Leaf 0x80000014. */ > + uint64_t :64, :64; /* Leaf 0x80000015. */ > + uint64_t :64, :64; /* Leaf 0x80000016. */ > + uint64_t :64, :64; /* Leaf 0x80000017. */ > + uint64_t :64, :64; /* Leaf 0x80000018. */ > + uint64_t :64, :64; /* Leaf 0x80000019 - TLB 1GB Identifiers. */ > + uint64_t :64, :64; /* Leaf 0x8000001a - Performance related > info. */ > + uint64_t :64, :64; /* Leaf 0x8000001b - IBS feature information. > */ > + uint64_t :64, :64; /* Leaf 0x8000001c. */ > + uint64_t :64, :64; /* Leaf 0x8000001d - Cache properties. */ > + uint64_t :64, :64; /* Leaf 0x8000001e - Extd APIC/Core/Node IDs. > */ > + uint64_t :64, :64; /* Leaf 0x8000001f - AMD Secure Encryption. */ > + uint64_t :64, :64; /* Leaf 0x80000020 - Platform QoS. */ > + > + /* Leaf 0x80000021 - Extended Feature 2 */ > + union { > + uint32_t e21a; > + struct { DECL_BITFIELD(e21a); }; > + }; > + uint32_t /* b */:32, /* c */:32, /* d */:32; > }; > } extd; Due to the effect of this on what guests get to see, I think this wants to take my "x86/CPUID: shrink max_{,sub}leaf fields according to actual leaf contents" as a prereq, which in turn may better remain on top of "x86/CPUID: adjust extended leaves out of range clearing" (both are neighbors in that over 4 months old series, fair parts of which could imo go in irrespective of the unsettled dispute on xvmalloc() - unfortunately I had made that patch 2 of the series, not expecting it to be blocked for so long, and then presumably signaling to others that the rest of the series is also blocked). Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |