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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 073B6C3A5A2 for ; Fri, 23 Aug 2019 22:07:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D13A42089E for ; Fri, 23 Aug 2019 22:07:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2393460AbfHWWGA (ORCPT ); Fri, 23 Aug 2019 18:06:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39022 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2393376AbfHWWGA (ORCPT ); Fri, 23 Aug 2019 18:06:00 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 37E50300CB28; Fri, 23 Aug 2019 22:06:00 +0000 (UTC) Received: from x1.home (ovpn-116-99.phx2.redhat.com [10.3.116.99]) by smtp.corp.redhat.com (Postfix) with ESMTP id C8CD460F86; Fri, 23 Aug 2019 22:05:58 +0000 (UTC) Date: Fri, 23 Aug 2019 16:05:58 -0600 From: Alex Williamson To: Sean Christopherson Cc: Paolo Bonzini , Radim =?UTF-8?B?S3LEjW3DocWZ?= , kvm@vger.kernel.org, Xiao Guangrong Subject: Re: [PATCH v2 11/27] KVM: x86/mmu: Zap only the relevant pages when removing a memslot Message-ID: <20190823160558.0a3394d3@x1.home> In-Reply-To: <20190823022502.GA4525@linux.intel.com> References: <20190813133316.6fc6f257@x1.home> <20190813201914.GI13991@linux.intel.com> <20190815092324.46bb3ac1@x1.home> <20190820200318.GA15808@linux.intel.com> <20190820144204.161f49e0@x1.home> <20190820210245.GC15808@linux.intel.com> <20190821130859.4330bcf4@x1.home> <20190821133504.79b87767@x1.home> <20190821203041.GJ29345@linux.intel.com> <20190823022502.GA4525@linux.intel.com> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Fri, 23 Aug 2019 22:06:00 +0000 (UTC) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Thu, 22 Aug 2019 19:25:02 -0700 Sean Christopherson wrote: > On Wed, Aug 21, 2019 at 01:30:41PM -0700, Sean Christopherson wrote: > > On Wed, Aug 21, 2019 at 01:35:04PM -0600, Alex Williamson wrote: > > > On Wed, 21 Aug 2019 13:08:59 -0600 > > > Alex Williamson wrote: > > > > Does this suggests something is still fundamentally wrong with the > > > > premise of this change or have I done something stupid? > > > > > > Seems the latter, particularly your comment that we're looking for > > > pages pointing to the gfn range to be removed, not just those in the > > > range. Slot gfn ranges like ffe00-ffe1f are getting reduced to 0-0 or > > > c0000-c0000, zapping zero or c0000, and I think one of the ones you > > > were looking for c1080-c1083 is reduce to c1000-c1000 and therefore > > > zaps sp->gfn c1000. I'll keep looking. Thanks, > > > > Ya. As far as where to look, at this point I don't think it's an issue of > > incorrect zapping. Not because I'm 100% confident the zapping logic is > > correct, but because many of the tests, e.g. removing 'sp->gfn != gfn' and > > not being able to exclude APIC/IOAPIC ranges, suggest that the badness is > > 'fixed' by zapping seemingly unrelated sps. > > > > In other words, it may be fundamentally wrong to zap only the memslot > > being removed, but I really want to know why. History isn't helpful as > > KVM has always zapped all pages when removing a memslot (on x86), and the > > introduction of the per-memslot flush hook in commit > > > > 2df72e9bc4c5 ("KVM: split kvm_arch_flush_shadow") > > > > was all about refactoring generic code, and doesn't have any information > > on whether per-memslot flushing was actually tried for x86. > > One semi-random idea would be to zap mmio pages, i.e. don't skip pages > for which sp->mmio_cached is true, regardless of their gfn or level. I > don't expect it to make a difference, but it would shrink the haystack on > the off change it does "fix" the issues. You're right, it doesn't fix it. All of the logging I've been staring at suggests your patch does exactly what it's intended to do, but it still breaks GPU assignment in weird ways. I have no idea why. Thanks, Alex