On Mon, Dec 7, 2020 at 3:47 AM stsp <stsp2@xxxxxxxxx> wrote: > > 07.12.2020 14:29, Paolo Bonzini пишет: > > On 07/12/20 12:24, stsp wrote: > >> It tries to enable VME among other things. > >> qemu appears to disable VME by default, > >> unless you do "-cpu host". So we have a situation where > >> the host (which is qemu) doesn't have VME, > >> and guest (dosemu) is trying to enable it. > >> Now obviously KVM_SET_CPUID doesn't check anyting > >> at all and returns success. That later turns > >> into an invalid guest state. > >> > >> > >> Question: should KVM_SET_CPUID check for > >> supported bits, end return error if not everything > >> is supported? > > > > No, it is intentional. Most bits of CPUID are not ever checked by > > KVM, so userspace is supposed to set values that makes sense > By "that makes sense" you probably > meant to say "bits_that_makes_sense masked > with the ones returned by KVM_GET_SUPPORTED_CPUID"? > > So am I right that KVM_SET_CPUID only "lowers" > the supported bits? In which case I don't need to > call it at all, but instead just call KVM_GET_SUPPORTED_CPUID > and see if the needed bits are supported, and > exit otherwise, right? "Lowers" is a tricky concept for CPUID information. Some feature bits report 0 for "present" and 1 for "not-present." Some multi-bit fields are interpreted as numbers, which may be signed or unsigned. Some multi-bit fields are strings. Some fields have dependencies on other fields. Etc.
