[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-discuss] Disable, not hide cpu instructions/flags to the guest
Re: [Qemu-discuss] Disable, not hide cpu instructions/flags to the guest OS?
Wed, 26 Jul 2017 18:04:15 +0200
Peter what you said here clarify our pesent issue's background, thanks for
Truth is organization of the place, team's organization and technical work
each already take 50% of my volunteer time ;) Anyhow I'd like to go that
deep in the virtualization field, I'm missing the time to do it :/
Note that I should have written "enforce" not "check" any time I wrote the
commands above. E.g. :
$ qemu-system-i386 -cpu pentium3,enforce (...)
PS : I enjoyed reading/watching some of Linaro's public shares, on e.g.
settings for a better Desktop responsivity.
On Sun, Jul 23, 2017 at 10:26 PM, Peter Maydell <address@hidden>
> On 23 July 2017 at 18:22, tukozaki <address@hidden> wrote:
> > I tried launching the Qemu vm without kvm:
> > $ qemu-system-i386 -cpu pentium3,check <options, disk image>
> > was slow as it should, but the same applications requiring sse2 still
> > did run (with some patience).
> > So I can't find how to run a client disabling the host cpu extensions.
> > Maybe that simply is impossible with the current Qemu.
> If the CPU you selected really does not have SSE2, then
> the CPU emulation should generate the appropriate kind
> of fault on attempts to execute those instructions.
> If it doesn't, then that's a bug in the emulation.
> It's not a very surprising kind of bug though, because
> it's the kind of thing that nobody will notice in
> normal operation. If you care for validation purposes
> about this kind of thing you probably want to review
> the QEMU code and/or exhaustively test all the instructions
> you care about to be sure we don't have any lurking
> bugs here.
> (As you have discovered, you can't completely disable
> the SSE instructions when using KVM -- this is because
> the host CPU hardware does not support trapping to
> the hypervisor (or otherwise faulting) on those
> You might also like to consider a static analysis --
> disassemble the binaries and scan them for uses of
> SSE2/whatever instructions. This will obviously not
> help for guest binaries which use JITs or other
> runtime codegen, and you'll get false positives for
> clever guest binaries that do runtime selection of
> optimised routines based on CPU feature detection,
> but it may still be useful as a fast initial pass,
> and it has the advantage that it will detect SSE
> instructions even if they're in a little-used part
> of the code that your dynamic testing doesn't
> happen to exercise.
> -- PMM