From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A457EC433F5 for ; Wed, 9 Feb 2022 22:13:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235029AbiBIWNb (ORCPT ); Wed, 9 Feb 2022 17:13:31 -0500 Received: from gmail-smtp-in.l.google.com ([23.128.96.19]:35498 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230482AbiBIWNa (ORCPT ); Wed, 9 Feb 2022 17:13:30 -0500 Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 99F1DC0F8699 for ; Wed, 9 Feb 2022 14:13:32 -0800 (PST) Received: by mail-pl1-x62a.google.com with SMTP id y18so141623plb.11 for ; Wed, 09 Feb 2022 14:13:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Fx5b1qQwMlFVs21l/OX+krSp/uyB0q/jyfgtOYhq7dE=; b=gBEeF6BpUfDehwTkVhoxki42M0jD+d2SYRr6MRurSmkaOqBYNiYhFzzkd6FV5TcBZu 3tBHQnb/hoBUkZh3ETyhokeD1Stsny6DlY/sSqk6MM8Ezr8zG4856oxqpBSfDvRMbQDj d6YE+VRTxybzzUiiVaDavG6L263fQJxSgDpymFr9AdVDZdPzBhqY18G7T5MtUxVf4n8n ObxuUFKf0kK/0FQki1M8PYWLtA3x55wE+f1+8EqVErr/3Edt2aTNqeoYAtdffwgvvZzQ DdYeS/sMNmmFgdi+iWsuO0Ny1daPsfjQ5OTabfQSCVsI8YiSTWJBC277nrTYnChiyJaY d1wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Fx5b1qQwMlFVs21l/OX+krSp/uyB0q/jyfgtOYhq7dE=; b=BmCP9T4xTMHyBChNvxCj8Bhbm1LPNoS572ozdwsJiEi/gT8Yo5BMM7WAWdoP2izlCj lK+VATR6e3avX0DxWGHg046XOCWsjh2kvVbXPXcYJgH4wWt9XBTr08ss9HVcKJ6qeOIc WcWIwMEGuhAqY+t3rbN6ox1tBzrHBc0RYRqHwq/WchgR2CB+BuRnFRIU2nXlGzaTfCRQ eaQ9r6E0TeKngNwTOcXiG8Uer45jAX2MvPHZZDWhunrFT8FtM0qRw5ez1e5E8DX18YRC YI+uducs5Vy1ZaxP0txO3ONKedtN68/EosN/VSWJASDpJ0zbviPsivPrutKesAL1wOkV xyTA== X-Gm-Message-State: AOAM5334vGmP2krc/owcikhwgT3AslfQgCH1noxZEv8x+l969blBKKCm s2b8a6yx0kpNmtbgJNE2m5Jcgg== X-Google-Smtp-Source: ABdhPJyVWs179jhP3AmLib7RzOT6sQbU88hEXWZ2jFNwsTrIFheQfrVrkfxWLnT5HErIbA2UNXcT0Q== X-Received: by 2002:a17:902:8204:: with SMTP id x4mr4334931pln.18.1644444811938; Wed, 09 Feb 2022 14:13:31 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id h25sm19265617pfn.208.2022.02.09.14.13.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 14:13:31 -0800 (PST) Date: Wed, 9 Feb 2022 22:13:27 +0000 From: Sean Christopherson To: Hou Wenlong Cc: kvm@vger.kernel.org, Paolo Bonzini Subject: Re: [kvm-unit-tests PATCH v2 2/2] x86/emulator: Add some tests for ljmp instruction emulation Message-ID: References: <4d8a505095cc6106371462db2513fbbe000d8b4d.1644311445.git.houwenlong.hwl@antgroup.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4d8a505095cc6106371462db2513fbbe000d8b4d.1644311445.git.houwenlong.hwl@antgroup.com> Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Tue, Feb 08, 2022, Hou Wenlong wrote: > Per Intel's SDM on the "Instruction Set Reference", when > loading segment descriptor for ljmp, not-present segment > check should be after all type and privilege checks. However, > __load_segment_descriptor() in x86's emulator does not-present > segment check first, so it would trigger #NP instead of #GP > if type or privilege checks fail and the segment is not present. > > So add some tests for ljmp instruction, and it will test > those tests in hardware and emulator. Enable > kvm.force_emulation_prefix when try to test them in emulator. Many of the same comments from patch 01 apply here. A few more below. > @@ -1007,6 +1034,27 @@ static void test_far_xfer(bool force_emulation, struct far_xfer_test *test) > handle_exception(NP_VECTOR, 0); > } > > +static void test_ljmp(uint64_t *mem) test_far_jmp(), the existing code is wrong ;-) > +{ > + unsigned char *m = (unsigned char *)mem; > + volatile int res = 1; > + > + *(unsigned long**)m = &&jmpf; > + asm volatile ("data16 mov %%cs, %0":"=m"(*(m + sizeof(unsigned long)))); > + asm volatile ("rex64 ljmp *%0"::"m"(*m)); > + res = 0; > +jmpf: > + report(res, "ljmp"); It'd be helfup to explain what this is doing (took me a while to decipher...), e.g. report(res, "far jmp, via emulated MMIO"); And as a delta patch... --- x86/emulator.c | 55 ++++++++++++++++++++++++-------------------------- 1 file changed, 26 insertions(+), 29 deletions(-) diff --git a/x86/emulator.c b/x86/emulator.c index 4e7c6d1..110d10d 100644 --- a/x86/emulator.c +++ b/x86/emulator.c @@ -66,16 +66,17 @@ static struct far_xfer_test far_ret_test = { }; static struct far_xfer_test_case far_jmp_testcases[] = { - {0, DS_TYPE, 0, 0, false, GP_VECTOR, FIRST_SPARE_SEL, "ljmp desc.type!=code && desc.p=0"}, - {0, NON_CONFORM_CS_TYPE, 3, 0, false, GP_VECTOR, FIRST_SPARE_SEL, "jmp non-conforming && dpl!=cpl && desc.p=0"}, - {3, NON_CONFORM_CS_TYPE, 0, 0, false, GP_VECTOR, FIRST_SPARE_SEL, "ljmp conforming && rpl>cpl && desc.p=0"}, - {0, CONFORM_CS_TYPE, 3, 0, false, GP_VECTOR, FIRST_SPARE_SEL, "ljmp conforming && dpl>cpl && desc.p=0"}, - {0, NON_CONFORM_CS_TYPE, 0, 0, false, NP_VECTOR, FIRST_SPARE_SEL, "ljmp desc.p=0"}, - {3, CONFORM_CS_TYPE, 0, 1, true, -1, -1, "ljmp dplcpl && desc.p=0"}, + {0, CONFORM_CS_TYPE, 3, 0, false, GP_VECTOR, "conforming && dpl>cpl && desc.p=0"}, + {0, NON_CONFORM_CS_TYPE, 0, 0, false, NP_VECTOR, "desc.p=0"}, + {3, CONFORM_CS_TYPE, 0, 1, true, -1, "dpl