From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Michael Tsirkin <mst@redhat.com>,
Julia Suvorova <jsuvorov@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>,
x86@kernel.org
Subject: Re: [PATCH RFC 4/5] KVM: x86: aggressively map PTEs in KVM_MEM_ALLONES slots
Date: Fri, 15 May 2020 06:58:45 -0700 [thread overview]
Message-ID: <20200515135845.GA17572@linux.intel.com> (raw)
In-Reply-To: <87ftc1wq64.fsf@vitty.brq.redhat.com>
On Fri, May 15, 2020 at 10:36:19AM +0200, Vitaly Kuznetsov wrote:
> Sean Christopherson <sean.j.christopherson@intel.com> writes:
> > IMO this is a waste of memory and TLB entries. Why not treat the access as
> > the MMIO it is and emulate the access with a 0xff return value? I think
> > it'd be a simple change to have __kvm_read_guest_page() stuff 0xff, i.e. a
> > kvm_allones_pg wouldn't be needed. I would even vote to never create an
> > MMIO SPTE. The guest has bigger issues if reading from a PCI hole is
> > performance sensitive.
>
> You're trying to defeat the sole purpose of the feature :-) I also saw
> the option you suggest but Michael convinced me we should go further.
>
> The idea (besides memory waste) was that the time we spend on PCI scan
> during boot is significant.
Put that in the cover letter. The impression I got from the current cover
letter is that the focus was entirely on memory consumption.
> Unfortunatelly, I don't have any numbers but we can certainly try to get
> them.
Numbers are definitely required, otherwise we'll have no idea whether doing
something like the agressive prefetch actually has a meaningful impact.
> With this feature (AFAIU) we're not aiming at 'classic' long-living VMs but
> rather at something like Kata containers/FaaS/... where boot time is crucial.
Isn't the guest kernel fully controlled by the VMM in those use cases?
Why not enlighten the guest kernel in some way so that it doesn't have to
spend time scanning PCI space in the first place?
next prev parent reply other threads:[~2020-05-15 13:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-14 18:05 [PATCH RFC 0/5] KVM: x86: KVM_MEM_ALLONES memory Vitaly Kuznetsov
2020-05-14 18:05 ` [PATCH RFC 1/5] KVM: rename labels in kvm_init() Vitaly Kuznetsov
2020-05-14 18:05 ` [PATCH RFC 2/5] KVM: x86: introduce KVM_MEM_ALLONES memory Vitaly Kuznetsov
2020-05-14 19:18 ` Sean Christopherson
2020-05-15 8:24 ` Vitaly Kuznetsov
2020-05-14 18:05 ` [PATCH RFC 3/5] KVM: x86: move kvm_vcpu_gfn_to_memslot() out of try_async_pf() Vitaly Kuznetsov
2020-05-14 18:05 ` [PATCH RFC 4/5] KVM: x86: aggressively map PTEs in KVM_MEM_ALLONES slots Vitaly Kuznetsov
2020-05-14 19:46 ` Sean Christopherson
2020-05-15 8:36 ` Vitaly Kuznetsov
2020-05-15 13:58 ` Sean Christopherson [this message]
2020-05-14 18:05 ` [PATCH RFC 5/5] KVM: selftests: add KVM_MEM_ALLONES test Vitaly Kuznetsov
2020-05-14 22:05 ` [PATCH RFC 0/5] KVM: x86: KVM_MEM_ALLONES memory Peter Xu
2020-05-14 22:56 ` Sean Christopherson
2020-05-14 23:22 ` Peter Xu
2020-05-14 23:32 ` Sean Christopherson
2020-05-15 8:42 ` Vitaly Kuznetsov
2020-05-15 1:03 ` Andy Lutomirski
2020-05-15 11:15 ` Peter Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200515135845.GA17572@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=jmattson@google.com \
--cc=jsuvorov@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).