> > From: Alexey Suslikov <alexey.susli...@gmail.com> > > Date: Thu, 11 Dec 2014 20:51:14 +0000 (UTC) > > > > Stefan Fritsch <sf <at> sfritsch.de> writes: > > > > > --- a/sys/arch/amd64/include/specialreg.h > > > +++ b/sys/arch/amd64/include/specialreg.h > > > <at> <at> -158,6 +158,7 <at> <at> > > > #define CPUIDECX_AVX 0x10000000 /* Advanced Vector Extensions > > */ > > > #define CPUIDECX_F16C 0x20000000 /* 16bit fp conversion */ > > > #define CPUIDECX_RDRAND 0x40000000 /* RDRAND instruction */ > > > +#define CPUIDECX_HYPERV 0x80000000 /* Hypervisor present */ > > > > Is this flag standardized? Last time I have tried to push this, there > > was an objection based on "reserved for future use" status of this flag. > > > > See http://marc.info/?l=openbsd-bugs&m=136907278229145&w=2 > > Well, that thread started out with a questionable workaround for a > hypervisor bug. That may have have influenced the debate about the > flag a bit. > > You can be almost certain that Intel and AMD will not use that > reserved bit for anything else. The Linux KVM virtualization business > is too important for them. And if Microsoft Hyper-V or VMWare ESX > sets that bit as well, this becomes an absolute certainty. > > That said: > > > If it is a standard nowadays, could CPUIDECX_HYPERV be committed as a > > separate chunk? > > I prefer the CPUIDECX_HV name used in the diff you posted in: > > http://marc.info/?l=openbsd-bugs&m=136906997828078&w=2 > > We print these flags, and they're already taking up a significant part > of dmesg real estate.
Completely agree..
