From: Sean Christopherson <seanjc@google.com>
To: Anish Moorthy <amoorthy@google.com>
Cc: oliver.upton@linux.dev, kvm@vger.kernel.org,
kvmarm@lists.linux.dev, pbonzini@redhat.com, maz@kernel.org,
robert.hoo.linux@gmail.com, jthoughton@google.com,
bgardon@google.com, dmatlack@google.com, ricarkol@google.com,
axelrasmussen@google.com, peterx@redhat.com,
nadav.amit@gmail.com, isaku.yamahata@gmail.com
Subject: Re: [PATCH v4 03/16] KVM: Add KVM_CAP_MEMORY_FAULT_INFO
Date: Thu, 24 Aug 2023 10:24:55 -0700 [thread overview]
Message-ID: <ZOeSZ5zScxM/DRf0@google.com> (raw)
In-Reply-To: <CAF7b7mpPcbxLKhPvLwVg4mwSbXRQ-zRhz8Osj-CVqhMnG6NRkw@mail.gmail.com>
On Wed, Aug 23, 2023, Anish Moorthy wrote:
> On Wed, Aug 23, 2023 at 3:20 PM Sean Christopherson <seanjc@google.com> wrote:
> >
> > I don't anticipate anything beyond the memory fault case. We essentially already
> > treat incomplete exits to userspace as KVM bugs. MMIO is the only other case I
> > can think of where KVM doesn't complete an exit to usersapce, but that one is
> > essentially getting grandfathered in because of x86's flawed MMIO handling.
> > Userspace memory faults also get grandfathered in because of paravirt ABIs, i.e.
> > KVM is effectively required to ignore some faults due to external forces.
>
> Well that's good to hear. Are you sure that we don't want to add even
> just a dedicated u8 to indicate the speculative exit reason though?
Pretty sure.
> I'm just thinking that the different structs in speculative_exit will
> be mutually exclusive,
Given that we have no idea what the next "speculative" exit might be, I don't
think it's safe to assume that the next one will be mutually exclusive with
memory_fault. I'm essentially betting that we'll never have more than 8
"speculative" exit types, which IMO is a pretty safe bet.
> whereas flags/bitfields usually indicate non-mutually exclusive conditions.
next prev parent reply other threads:[~2023-08-24 17:24 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-02 16:19 [PATCH v4 00/16] Improve scalability of KVM + userfaultfd live migration via annotated memory faults Anish Moorthy
2023-06-02 16:19 ` [PATCH v4 01/16] KVM: Allow hva_pfn_fast() to resolve read-only faults Anish Moorthy
2023-06-14 14:39 ` Sean Christopherson
2023-06-14 16:57 ` Anish Moorthy
2023-08-10 19:54 ` Anish Moorthy
2023-08-10 23:48 ` Sean Christopherson
2023-06-02 16:19 ` [PATCH v4 02/16] KVM: x86: Set vCPU exit reason to KVM_EXIT_UNKNOWN at the start of KVM_RUN Anish Moorthy
2023-06-02 20:30 ` Isaku Yamahata
2023-06-05 16:41 ` Anish Moorthy
2023-06-02 16:19 ` [PATCH v4 03/16] KVM: Add KVM_CAP_MEMORY_FAULT_INFO Anish Moorthy
2023-06-03 16:58 ` Isaku Yamahata
2023-06-05 16:37 ` Anish Moorthy
2023-06-14 14:55 ` Sean Christopherson
2023-06-05 17:46 ` Anish Moorthy
2023-06-14 17:35 ` Sean Christopherson
2023-06-20 21:13 ` Anish Moorthy
2023-07-07 11:50 ` Kautuk Consul
2023-07-10 15:00 ` Anish Moorthy
2023-07-11 3:54 ` Kautuk Consul
2023-07-11 14:25 ` Sean Christopherson
2023-08-11 22:12 ` Anish Moorthy
2023-08-14 18:01 ` Sean Christopherson
2023-08-15 0:06 ` Anish Moorthy
2023-08-15 0:43 ` Sean Christopherson
2023-08-15 17:01 ` Anish Moorthy
2023-08-16 15:58 ` Sean Christopherson
2023-08-16 21:28 ` Anish Moorthy
2023-08-17 23:58 ` Sean Christopherson
2023-08-18 17:32 ` Anish Moorthy
2023-08-23 22:20 ` Sean Christopherson
2023-08-23 23:38 ` Anish Moorthy
2023-08-24 17:24 ` Sean Christopherson [this message]
2023-08-17 22:55 ` Anish Moorthy
2023-07-05 8:21 ` Kautuk Consul
2023-06-02 16:19 ` [PATCH v4 04/16] KVM: Add docstrings to __kvm_write_guest_page() and __kvm_read_guest_page() Anish Moorthy
2023-06-15 2:41 ` Robert Hoo
2023-08-14 22:51 ` Anish Moorthy
2023-06-02 16:19 ` [PATCH v4 05/16] KVM: Annotate -EFAULTs from kvm_vcpu_write_guest_page() Anish Moorthy
2023-06-14 19:10 ` Sean Christopherson
2023-07-06 22:51 ` Anish Moorthy
2023-07-12 14:08 ` Sean Christopherson
2023-06-02 16:19 ` [PATCH v4 06/16] KVM: Annotate -EFAULTs from kvm_vcpu_read_guest_page() Anish Moorthy
2023-06-14 19:22 ` Sean Christopherson
2023-07-07 17:35 ` Anish Moorthy
2023-06-02 16:19 ` [PATCH v4 07/16] KVM: Simplify error handling in __gfn_to_pfn_memslot() Anish Moorthy
2023-06-14 19:26 ` Sean Christopherson
2023-07-07 17:33 ` Anish Moorthy
2023-07-10 17:40 ` Sean Christopherson
2023-06-02 16:19 ` [PATCH v4 08/16] KVM: x86: Annotate -EFAULTs from kvm_handle_error_pfn() Anish Moorthy
2023-06-14 20:03 ` Sean Christopherson
2023-07-07 18:05 ` Anish Moorthy
2023-06-15 2:43 ` Robert Hoo
2023-06-15 14:40 ` Sean Christopherson
2023-06-02 16:19 ` [PATCH v4 09/16] KVM: Introduce KVM_CAP_NOWAIT_ON_FAULT without implementation Anish Moorthy
2023-06-14 20:11 ` Sean Christopherson
2023-07-06 19:04 ` Anish Moorthy
2023-06-14 21:20 ` Sean Christopherson
2023-06-14 21:23 ` Sean Christopherson
2023-08-23 21:17 ` Anish Moorthy
2023-06-15 3:55 ` Wang, Wei W
2023-06-15 14:56 ` Sean Christopherson
2023-06-16 12:08 ` Wang, Wei W
2023-07-07 18:13 ` Anish Moorthy
2023-07-07 20:07 ` Anish Moorthy
2023-07-11 15:29 ` Sean Christopherson
2023-08-25 0:15 ` Anish Moorthy
2023-08-29 22:41 ` Sean Christopherson
2023-08-30 16:21 ` Anish Moorthy
2023-09-07 21:17 ` Sean Christopherson
2023-06-02 16:19 ` [PATCH v4 10/16] KVM: x86: Implement KVM_CAP_NOWAIT_ON_FAULT Anish Moorthy
2023-06-14 20:25 ` Sean Christopherson
2023-07-07 17:41 ` Anish Moorthy
2023-06-02 16:19 ` [PATCH v4 11/16] KVM: arm64: " Anish Moorthy
2023-06-02 16:19 ` [PATCH v4 12/16] KVM: selftests: Report per-vcpu demand paging rate from demand paging test Anish Moorthy
2023-06-02 16:19 ` [PATCH v4 13/16] KVM: selftests: Allow many vCPUs and reader threads per UFFD in " Anish Moorthy
2023-06-02 16:19 ` [PATCH v4 14/16] KVM: selftests: Use EPOLL in userfaultfd_util reader threads and signal errors via TEST_ASSERT Anish Moorthy
2023-06-02 16:19 ` [PATCH v4 15/16] KVM: selftests: Add memslot_flags parameter to memstress_create_vm() Anish Moorthy
2023-06-02 16:19 ` [PATCH v4 16/16] KVM: selftests: Handle memory fault exits in demand_paging_test Anish Moorthy
2023-06-20 2:44 ` Robert Hoo
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=ZOeSZ5zScxM/DRf0@google.com \
--to=seanjc@google.com \
--cc=amoorthy@google.com \
--cc=axelrasmussen@google.com \
--cc=bgardon@google.com \
--cc=dmatlack@google.com \
--cc=isaku.yamahata@gmail.com \
--cc=jthoughton@google.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=maz@kernel.org \
--cc=nadav.amit@gmail.com \
--cc=oliver.upton@linux.dev \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=ricarkol@google.com \
--cc=robert.hoo.linux@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.