similar to: Hiding hypervisor cpuid bit in Qemu

Hi, all Some Latest Intel CPU models (CPUID.1.EAX >= 0x00010674) support cupid mask features. Cpuid feature mask is used to limit the feature flags reported by CPUID.1.EDX:ECX. This small patch adds CPUID feature mask support in XEN by adding boot options in Grub entry as below example: kernel /boot/xen.gz com1=115200,8n1 console=com1 cpuid_mask_ecx = 0xFFFF7FFF cpuid_mask_edx = 0xFFFFFFFC

See http://lkml.org/lkml/2008/10/1/246 for more context. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2008-10-27/xen/arch/x86/domain.c =================================================================== --- 2008-10-27.orig/xen/arch/x86/domain.c 2008-11-11 16:24:48.000000000 +0100 +++ 2008-10-27/xen/arch/x86/domain.c 2008-11-19 10:22:34.000000000 +0100 @@ -1888,6 +1888,8 @@ void

I hope I'm sending this to the correct group for resolution, if not please direct to the appropriate place for openssh problems. I complied openssh-3.5pl.tar on Solaris 8 OS system using gnu. I installed the lastest version of openssl. I did not install /www/gzip.org/zlib because I assumed that I probably have that, since I have gunzip.... Openssh compiled but I kept receiving warnings that

Author: dmick Repository: /hg/zfs-crypto/gate Revision: 4559d499327b38dfc599c113d49e339f5c0308c3 Log message: 6327969 cpuid sse3 feature bit not noted on any AMD processor Files: update: usr/src/uts/i86pc/os/cpuid.c update: usr/src/uts/intel/sys/x86_archext.h

Remove visibility of the FFXSR CPUID bit to an HVM guest. This patch allows HVM Windows x64 to install/boot on AMD-V platforms. This patches applies cleanly to xen-unstable 13743. Please apply to xen-unstable/3.0.5. If possible, pls apply to xen-3.0.4-testing. --Tom thomas.woller@amd.com AMD Corporation 5204 E. Ben White Blvd. UBC1 Austin, Texas 78741 +1-512-602-0059

Hi, this patch passes the orginal cpuid bits for X86_FEATURE_DTES64 (64-bit DS Area) and X86_FEATURE_DSCPL (CPL Qualified Debug Store) to the guest when the BTS feature is switched on. I forgot this when I did this BTS emulation. Thanks. Dietmar. Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> diff -r a6b81234b189 xen/arch/x86/hvm/vmx/vpmu_core2.c ---

Enable Px/Cx related CPUID/MSR bits for dom0 to get correct Px/Cx info. Signed-off-by: Wei Gang <gang.wei@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hi, Please find below the proposal for the generic use of cpuid space allotted for hypervisors. Apart from this cpuid space another thing worth noting would be that, Intel & AMD reserve the MSRs from 0x40000000 - 0x400000FF for software use. Though the proposal doesn't talk about MSR's right now, we should be aware of these reservations as we may want to extend the way we use CPUID to

Hi, Please find below the proposal for the generic use of cpuid space allotted for hypervisors. Apart from this cpuid space another thing worth noting would be that, Intel & AMD reserve the MSRs from 0x40000000 - 0x400000FF for software use. Though the proposal doesn't talk about MSR's right now, we should be aware of these reservations as we may want to extend the way we use CPUID to

I'd like to export the corresponding functions from the i2c core so that I can use them in fallback bit-banging in i915.ko Cc: nouveau at lists.freedesktop.org Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch> --- drivers/gpu/drm/nouveau/nouveau_i2c.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_i2c.c

In a recent conversation one of my coworkers raised a concern about memory limitations when running 32-bit guests on top of the 64-bit hypervisor. At this point the discussion is academic; I don''t know when/if we''ll ever be able to get system resources to test it, to see if the concerns that he expressed are real. So I decided to post this in hope of getting comments from the

This is a bug fixing. So it needs go into 4.1. x86: add volatile prefix for cpuid asm clauses cpuid results are possible to be changed now. For example, changing CR4.OSXSAVE bit or setting MSR XCR_XFEATURE_ENABLED_MASK may change XSAVE related cpuid leave return values. The volatile prefix is required to avoid the second cpuid calls following some possible changing operations being optimized in

Hey, Gert reported me that cpuidtest.c32 reports weird stuff. After looking at it, I found a potential bug when the cpu vendor isn't detected from an exisiting list. That will be easy to fix, that's not the purpose of this mail. When investigating why the vendor was wrong, I found that a very old commit in the 4.0 branch generates unexpected results when calling cpuid(). This commit

On 5/6/20 1:08 PM, Mike Stunes wrote: > > >> On Apr 28, 2020, at 8:17 AM, Joerg Roedel <joro at 8bytes.org> wrote: >> >> From: Mike Stunes <mstunes at vmware.com> >> >> To avoid a future VMEXIT for a subsequent CPUID function, cache the >> results returned by CPUID into an xarray. >> >> [tl: coding standard changes, register zero

Only call CPUID function 4 if cpuid_level indicates its availability. Signed-off-by: Sebastian Herbszt <herbszt at gmx.de> diff --git a/com32/gpllib/cpuid.c b/com32/gpllib/cpuid.c index fa21204..f33e895 100644 --- a/com32/gpllib/cpuid.c +++ b/com32/gpllib/cpuid.c @@ -232,8 +232,10 @@ void generic_identify(struct cpuinfo_x86 *c) } break; case X86_VENDOR_INTEL: - cpuid(0x4,

I found that FLAC__cpu_have_cpuid_x86() was removed in the commit <http://git.xiph.org/?p=flac.git;a=commitdiff;h=fa24613ad94ba8fb8e23bcb9ca80b4548bb617e6> with the message: "Remove `FLAC__cpu_have_cpuid_x86` altogether as it wasn't actually being used but that was difficult to tell because of all the #ifdef nonsense." But FLAC__cpu_have_cpuid_x86() actually WAS used

Hi Keir, For HVM guests, all cpuid Fn''s going through domain_cpuid() iterate over the loop and then return 0 for all four registers. Guests OS''s and cpuid tools in HVM which query for cpuid Fn 0000.0000 %eax and 8000.0000 %eax, see the value 0 and think, Xen emulates oldish 386/486 CPUs. This leads to strange boot failures, "your CPU does not support long mode" or

On Tue, May 19, 2020 at 10:16:37PM -0700, Sean Christopherson wrote: > The whole cache on-demand approach seems like overkill. The number of CPUID > leaves that are invoked after boot with any regularity can probably be counted > on one hand. IIRC glibc invokes CPUID to gather TLB/cache info, XCR0-based > features, and one or two other leafs. A statically sized global array

# HG changeset patch # User Jim Fehlig <jfehlig@suse.com> # Date 1360861948 -3600 # Node ID 0f9c7503650fa1b1103b769e1129d66ff614b2ad # Parent cffb489a6df37d8d114e7d2d53a7a85d14e8f968 tools/xend: Only add cpuid and cpuid_check to sexpr once When converting a XendConfig object to sexpr, cpuid and cpuid_check were being emitted twice in the resulting sexpr. The first conversion writes

Keir, In July we implemented cpuid faulting feature, and checked in xen-unstable tree as c/s 23653/23654/23655. Today we patched them to xen-4.1.0, test result shows it''s OK to work with xen-4.1.0. So how about backporting this feature to xen-4.1.0? Thanks, Jinsong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com