Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp2824045pxu; Mon, 7 Dec 2020 17:19:04 -0800 (PST) X-Google-Smtp-Source: ABdhPJyC10c1SKAh1Kr++mJQTbOnTSu9tdBT25x0JuSugFl76tSfCccGmZ7x6WhRKyEbigcPG3hs X-Received: by 2002:aa7:dcd0:: with SMTP id w16mr22822532edu.229.1607390344670; Mon, 07 Dec 2020 17:19:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607390344; cv=none; d=google.com; s=arc-20160816; b=kXMs6q7vuDB5KMHRyfD46lvmkuRoLIPY/nPYUFqOf6kw8ezsBrFYAYSxIht1V5THk/ Hcoe8DbTsPVM41wZu6Rjrcg/ZEXww3zdIb7k8AaCqPH+KcRgX+TGG9lo43j2jYpPf+27 ATKSF22MPrsmnkpHR7tECsWcBlcTDajuWwRCuk7hDDhvgjPE8ld+dqBqKAwmlTZ3wmFg f8cP2REhD4u6dfamH0VFp+AnIcYsTh3FqOC/ZVwwBafOzz5GqHkfXPIE66rIPoCKcvMR 3CHu9JyjZ8Qcw97Yq5FrkNIJ0KKSJyZ1TZ+EnEES0Ga7wGVDrnixcRkg623UYR/a1Tl8 4OTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=ADhDNSNt6I8G4BtstjMfXOHtK2RWSiGfFOI+5bfvv/g=; b=ISMNb9PRDV2DT70X1znzIRVPQywV3ddZv6SfClCP+L+IxOQ3mC38ipJ8ygCO8pzXJf h2IahJOjusYh2MqknWFrV7EflO6CoP5Vpv7w03QmlYOhiI7+akLgy2mYpSGiHIl9zSNX wH7krvc4CYVVFCe3yzADcv3VVzUPm/WKf7j45tZcsLT55MIU5BjtoZ/XV2aohtfb1O4+ ubyi2WKtSUIfvqdIaLAW49CwuaMBJs3KAnZq1++K4EA6Hd6PprRclNYuShHNKXDLaI0k VAq1c+UUGwERieNhaUm6YRZPIXcSxo3AoOA8DR136fTSdEfIxNVLwXgBdcTQwF2nn1Wd 27LA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=vmxkKZSv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r17si4527209ejr.115.2020.12.07.17.18.40; Mon, 07 Dec 2020 17:19:04 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=vmxkKZSv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726648AbgLHAAM (ORCPT + 99 others); Mon, 7 Dec 2020 19:00:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44560 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726114AbgLHAAM (ORCPT ); Mon, 7 Dec 2020 19:00:12 -0500 Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E2416C061793 for ; Mon, 7 Dec 2020 15:59:31 -0800 (PST) Received: by mail-ot1-x341.google.com with SMTP id b62so14303137otc.5 for ; Mon, 07 Dec 2020 15:59:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ADhDNSNt6I8G4BtstjMfXOHtK2RWSiGfFOI+5bfvv/g=; b=vmxkKZSv7VtJpr+t5DKiSVA794FYtcGFDnbYWzkb632YWPmVzxoA6KiZkk9K9ZjCmK K+afPxSRTfRy7lbRd1heu0q0NEiNVE3YQgrrL1Go5S77wRwoWFpsIUtZ9hmNddMNv7iY MRcsv7KdtV7Qkd0buVKHVyc5DEMB7XUs3Iqt08298ZrD4FB3EiRYUnc6CoPsQtha8o8V ZI/b1YN2CYP3IAvVFA0ceq/8TjMIat1YlJlCWJ6XB5+dJw+MdwXGuA8M1+43WreAokso Ek6GISInoQc8aJHQsU/FCAnweyQnfiSt4cfS6mfSFNkcA8rejc1TIf5gOeLpjjPg9XOi 8CDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ADhDNSNt6I8G4BtstjMfXOHtK2RWSiGfFOI+5bfvv/g=; b=X4R6tDF9nUBhd9k0XL/5/7X5yC4lQT33OfVfsQva2o6nYTKTvIqODQRFNPzeKJe/hQ WtCbfskj6pAIBHhyDHNDemME0mgydIBUyevRQrXJGxe2WW5RRMSfN7nfXwRwmUaV28LM A3p7M7qFfotSHktkOQLoiwIwsZ4PDui0HgtfM7UkGM8GDBhRccYG/BFHTHYPI65JmSUf xyLAooVKsj09WDVGYy93pmcyGpWLXtd283nzPuQ90OCCHv/DOmUanEXlOORr0StxtwY8 OKI5v6ePMrUeMDM2vxwtAmAn2vxpYQm8LzDWmzMtinJ26oDYUiHObP/mYZlG1jlFRLDx F3VQ== X-Gm-Message-State: AOAM5332mw91eN9X7Jr3usXqVHq/y7+VweegQQUGq0C0uLqSNvKLzCsm JdTLL3pOgd1YD3VAAtIcfbbRdO9Fzw0F427D4e5ahA== X-Received: by 2002:a9d:d01:: with SMTP id 1mr14556642oti.295.1607385571022; Mon, 07 Dec 2020 15:59:31 -0800 (PST) MIME-Version: 1.0 References: <20201007014417.29276-1-sean.j.christopherson@intel.com> <99334de1-ba3d-dfac-0730-e637d39b948f@yandex.ru> <20201008175951.GA9267@linux.intel.com> <7efe1398-24c0-139f-29fa-3d89b6013f34@yandex.ru> <20201009040453.GA10744@linux.intel.com> <5dfa55f3-ecdf-9f8d-2d45-d2e6e54f2daa@yandex.ru> <20201009153053.GA16234@linux.intel.com> In-Reply-To: From: Jim Mattson Date: Mon, 7 Dec 2020 15:59:19 -0800 Message-ID: Subject: Re: KVM_SET_CPUID doesn't check supported bits (was Re: [PATCH 0/6] KVM: x86: KVM_SET_SREGS.CR4 bug fixes and cleanup) To: stsp Cc: Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Joerg Roedel , kvm list , LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 7, 2020 at 3:47 AM stsp wrote: > > 07.12.2020 14:29, Paolo Bonzini =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > 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.