On 05/09/2019 10:26, Peter Zijlstra wrote: > On Thu, Sep 05, 2019 at 09:53:32AM +0100, Andrew Cooper wrote: >> On 05/09/2019 09:26, Peter Zijlstra wrote: >>> On Thu, Sep 05, 2019 at 08:54:17AM +0100, Andrew Cooper wrote: >>> >>>> I don't know if you've spotted, but the prefix is a ud2a instruction >>>> followed by 'xen' in ascii. >>>> >>>> The KVM version was added in c/s 6c86eedc206dd1f9d37a2796faa8e6f2278215d2 >>> While the Xen one disassebles to valid instructions, that KVM one does >>> not: >>> >>> .text >>> xen: >>> ud2; .ascii "xen" >>> kvm: >>> ud2; .ascii "kvm" >>> >>> disassembles like: >>> >>> 0000000000000000 <xen>: >>> 0: 0f 0b ud2 >>> 2: 78 65 js 69 <kvm+0x64> >>> 4: 6e outsb %ds:(%rsi),(%dx) >>> 0000000000000005 <kvm>: >>> 5: 0f 0b ud2 >>> 7: 6b .byte 0x6b >>> 8: 76 6d jbe 77 <kvm+0x72> >>> >>> Which is a bit unfortunate I suppose. At least they don't appear to >>> consume further bytes. >> It does when you give objdump one extra byte to look at. >> >> 0000000000000005 <kvm>: >> 5: 0f 0b ud2 >> 7: 6b 76 6d 00 imul $0x0,0x6d(%rsi),%esi >> >> I did try to point out that this property should have been checked >> before settling on 'kvm' as the string. > Bah you're right; when I write: > > ud2; .ascii "kvm"; cpuid > > The output is gibberish :/
KVM could possibly amend this. It is an off-by-default testing-only interface. Xen's is part of the ABI for ring-deprivielged guests, to force CPUID to be the virtualised view on hardware without CPUID Faulting. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
