Received: by 10.223.176.46 with SMTP id f43csp122686wra; Thu, 25 Jan 2018 18:42:55 -0800 (PST) X-Google-Smtp-Source: AH8x224Zmpx7FrwTLnHyomG6Tb0inqHrLvSa8xCGZCYVjQQA5juzughfqBQJl4LwPLh94FgUXgpq X-Received: by 10.101.100.132 with SMTP id e4mr12539478pgv.398.1516934574948; Thu, 25 Jan 2018 18:42:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516934574; cv=none; d=google.com; s=arc-20160816; b=sWP630XglvjxB6309cCgV7VGCb9WDp96/XpkT6GzF6cshvv8CtCR+MBy09M+LN4zCE vq+2iWP+Y1atRFlnGZwIm0edu1jHuYKTvPrrHaJfz1fy6jPsUBTJMrEor97ORd9cleRq 5qpMMIZNhV5lojafnrqdqT4nkrbNfTESSbu0lzyHF0ix3QDQliQH3OAvdn5h+aKZA51j alqaiwxpMxzxDDstTkBnIYznK1xiXF5phpPdP2ueYPPLbFJAFh0a4bjmJ7o4Hp4BNqfY HrzguwwCR3m4gQ7Lh4+rw58oeG6Z6BXovDCvquRacLpfP9kITTQORNGd219LnaOPBsqS Oong== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=q9p6AR7HqxwPyJcEOx7O4Pcbt4BhpqOAoPwNxhtcNJ0=; b=cxXFh+QU5gJIMrotbJ1xb+49bWj1NZxYwtDxFVF3MdLRwDADAEVFpOiJzG48QXR73T Y7ahBgfdrr9vZIMZFnrrNKIaMHDgudlG8IjZ+JScP5ubPt4Y/MLCROwk0qUe1IvR/guH D139n5zoaTKO7m2y3u03FIgo4JHUS1ZW604FVYmj+PYkefyP9U4NKSXVC/lwBOYFHmet fFeDRyJjOojQrJ0nTphPIG29EuZkmXs6P+MwnYa4yWKoJcqKofG6j/yhv9nZZ7nOz4K8 xMCX3uBISeV7Qv+/p0aw3iv0Wm43bHogCr4kHMCONXjrdGr9qrGXRqY5cBmLaJhxJnIy WBMw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u16si5560978pfl.262.2018.01.25.18.42.41; Thu, 25 Jan 2018 18:42:54 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751803AbeAZCmK (ORCPT + 99 others); Thu, 25 Jan 2018 21:42:10 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37350 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751578AbeAZCmJ (ORCPT ); Thu, 25 Jan 2018 21:42:09 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E4C31C0567A2; Fri, 26 Jan 2018 02:42:08 +0000 (UTC) Received: from [10.72.12.129] (ovpn-12-129.pek2.redhat.com [10.72.12.129]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 518E15D72D; Fri, 26 Jan 2018 02:42:02 +0000 (UTC) Subject: Re: [PATCH] x86/kvm: disable fast MMIO when running nested To: "Michael S. Tsirkin" , Paolo Bonzini Cc: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Liran Alon , vkuznets@redhat.com, x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org References: <6690c53c-fc99-44ea-9090-6e7438c1bc98@default> <20180125141620.GA7663@flask> <2039380511.2539348.1516891762406.JavaMail.zimbra@redhat.com> <20180125185431-mutt-send-email-mst@kernel.org> From: Jason Wang Message-ID: Date: Fri, 26 Jan 2018 10:41:58 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20180125185431-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Fri, 26 Jan 2018 02:42:08 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018年01月26日 01:11, Michael S. Tsirkin wrote: > On Thu, Jan 25, 2018 at 09:49:22AM -0500, Paolo Bonzini wrote: >>>> Michael and Jason, any progress on implementing a fast virtio mechanism >>>> that doesn't rely on undefined behavior? >>>> >>>> (Encode writing instruction length into last 4 bits of MMIO address, >>>> side-channel say that accesses to the MMIO area always use certain >>>> instruction length, use hypercall, ...) >>>> >>>> Thanks. >>> No progress from my side. But we can use PIO for virtio 1.0 and it's >>> faster than fast MMIO (qemu supports modern pio notification bar, we can >>> make it as default). It looks to me that neither encoding nor hypercall >>> will work for real hardware virtio device. >> Encoding the instruction length would work, the h/w virtio devices would >> just ignore it. But... it is really ugly. >> >> Using PIO would be a small step backwards for PCIe. As long as the device >> only needs *one* notification register (either MMIO or PIO) to initialize >> successfully, it's okay. Then if there is no PIO space you'd just fall back >> to the slower MMIO notification. >> >> Paolo > A bigger issue for PIO is it's causing exits for hw devices. > > Just to make sure I understand. For exits you mean vmexit? I believe MMIO will cause vmexit too. Thanks