On 8/15/21 2:13 AM, Gavin Shan wrote:
> This supports SDEI_{PRIVATE, SHARED}_RESET. They are used by the
> guest to purge the private or shared SDEI events, which are registered
to reset all private SDEI event registrations of the calling PE (resp.
PRIVATE or SHARED)
> previously.
>
> Signed-of
Hi Gavin,
On 8/15/21 2:13 AM, Gavin Shan wrote:
> This supports SDEI_PE_{MASK, UNMASK} hypercall. They are used by
> the guest to stop the specific vCPU from receiving SDEI events.
>
> Signed-off-by: Gavin Shan
> ---
> arch/arm64/kvm/sdei.c | 35 +++
> 1 file cha
Hi Gavin,
On 8/15/21 2:13 AM, Gavin Shan wrote:
> This supports SDEI_EVENT_ROUTING_SET hypercall. It's used by the
> guest to set route mode and affinity for the registered KVM event.
> It's only valid for the shared events. It's not allowed to do so
> when the corresponding event has been raised t
On 09.11.2021 02:34, Sean Christopherson wrote:
On Tue, Nov 09, 2021, Maciej S. Szmigiero wrote:
On 04.11.2021 01:25, Sean Christopherson wrote:
From: Maciej S. Szmigiero
There is no point in recalculating from scratch the total number of pages
in all memslots each time a memslot is created o
Hi Gavin,
On 8/15/21 2:13 AM, Gavin Shan wrote:
> This supports SDEI_EVENT_GET_INFO hypercall. It's used by the guest
> to retrieve various information about the supported (exported) events,
> including type, signaled, route mode and affinity for the shared
> events.
>
> Signed-off-by: Gavin Shan
On 8/15/21 2:13 AM, Gavin Shan wrote:
> This supports SDEI_EVENT_STATUS hypercall. It's used by the guest
> to retrieve a bitmap to indicate the SDEI event states, including
> registration, enablement and delivery state.
>
> Signed-off-by: Gavin Shan
> ---
> arch/arm64/kvm/sdei.c | 50 +++
On 8/15/21 2:13 AM, Gavin Shan wrote:
> This supports SDEI_EVENT_UNREGISTER hypercall. It's used by the
> guest to unregister SDEI event. The SDEI event won't be raised to
> the guest or specific vCPU after it's unregistered successfully.
> It's notable the SDEI event is disabled automatically o
Hi Gavin,
On 8/15/21 2:13 AM, Gavin Shan wrote:
> This supports SDEI_EVENT_{ENABLE, DISABLE} hypercall. After SDEI
> event is registered by guest, it won't be delivered to the guest
> until it's enabled. On the other hand, the SDEI event won't be
> raised to the guest or specific vCPU if it's has
Hi Gavin,
On 8/15/21 2:13 AM, Gavin Shan wrote:
> This supports SDEI_EVENT_REGISTER hypercall, which is used by guest
> to register SDEI events. The SDEI event won't be raised to the guest
> or specific vCPU until it's registered and enabled explicitly.
>
> Only those events that have been exporte
Hi Gavin,
On 8/15/21 2:13 AM, Gavin Shan wrote:
> Software Delegated Exception Interface (SDEI) provides a mechanism for
> registering and servicing system events. Those system events are high
> priority events, which must be serviced immediately. It's going to be
> used by Asynchronous Page Fault
Hi Gavin
On 8/15/21 2:13 AM, Gavin Shan wrote:
> This supports SDEI_VERSION hypercall by returning v1.0.0 simply
s/This supports/Add Support. I think this is the prefered way to start
the commit msg. Here and elsewhere.
> when the functionality is supported on the VM and vCPU.
Can you explain when
Hi Gavin,
On 8/15/21 2:13 AM, Gavin Shan wrote:
> The inline functions used to get the SMCCC parameters have same
> layout. It means these functions can be presented by a template,
> to make the code simplified. Besides, this adds more similar inline
> functions like smccc_get_arg{4,5,6,7,8}() to
On 04.11.2021 01:25, Sean Christopherson wrote:
This series is an iteration of Maciej's scalable memslots work. It
addresses most, but not all, of my feedback from v5, hence the "5.5"
moniker. Specifically, I did not touch the iteration over gfn and hva
ranges as I would likely do more harm tha
On 04.11.2021 01:25, Sean Christopherson wrote:
From: Maciej S. Szmigiero
There is no point in recalculating from scratch the total number of pages
in all memslots each time a memslot is created or deleted. Use KVM's
cached nr_memslot_pages to compute the default max number of MMU pages.
Sign
On 04.11.2021 01:25, Sean Christopherson wrote:
Stop making a full copy of the old memslot in __kvm_set_memory_region()
now that metadata updates are handled by kvm_set_memslot(), i.e. now that
the old memslot's dirty bitmap doesn't need to be referenced after the
memslot and its pointer is modif
On 04.11.2021 01:25, Sean Christopherson wrote:
Handle the generic memslot metadata, a.k.a. dirty bitmap, updates at the
same time that arch handles it's own metadata updates, i.e. at memslot
prepare and commit. This will simplify converting @new to a dynamically
allocated object, and more close
On 04.11.2021 01:25, Sean Christopherson wrote:
Get the number of pages directly from the new memslot instead of
computing the same from the userspace memory region when allocating
memslot metadata. This will allow a future patch to drop @mem.
No functional change intended.
Signed-off-by: Sean
On 04.11.2021 01:25, Sean Christopherson wrote:
Play nice with a NULL @old or @new when handling memslot updates so that
common KVM can pass NULL for one or the other in CREATE and DELETE cases
instead of having to synthesize a dummy memslot.
No functional change intended.
Signed-off-by: Sean C
On 04.11.2021 01:25, Sean Christopherson wrote:
Now that the address space ID is stored in every slot, including fake
slots used for deletion, use the slot's as_id instead of passing in the
redundant information as a param to kvm_set_memslot(). This will greatly
simplify future memslot work by a
On 04.11.2021 01:25, Sean Christopherson wrote:
Drop the @mem param from kvm_arch_{prepare,commit}_memory_region() now
that its use has been removed in all architectures.
No functional change intended.
Signed-off-by: Sean Christopherson
Reviewed-by: Maciej S. Szmigiero
_
On 04.11.2021 01:25, Sean Christopherson wrote:
Pass the "old" slot to kvm_arch_prepare_memory_region() and force arch
code to handle propagating arch specific data from "new" to "old" when
necessary. This is a baby step towards dynamically allocating "new" from
the get go, and is a (very) minor
On 04.11.2021 01:25, Sean Christopherson wrote:
From: Maciej S. Szmigiero
There is no need to copy the whole memslot data after releasing
slots_arch_lock for a moment to install temporary memslots copy in
kvm_set_memslot() since this lock only protects the arch field of each
memslot.
Just resy
On 04.11.2021 01:25, Sean Christopherson wrote:
Fold kvm_delete_memslot() into __kvm_set_memory_region() to free up the
"kvm_delete_memslot()" name for use in a future helper. The delete logic
isn't so complex/long that it truly needs a helper, and it will be
simplified a wee bit further in upco
On 04.11.2021 01:25, Sean Christopherson wrote:
Explicitly disallow creating more memslot pages than can fit in an
unsigned long, KVM doesn't correctly handle a total number of memslot
pages that doesn't fit in an unsigned long and remedying that would be a
waste of time.
For a 64-bit kernel, th
On 04.11.2021 01:25, Sean Christopherson wrote:
Reject userspace memslots whose size exceeds the storage capacity of an
"unsigned long". KVM's uAPI takes the size as u64 to support large slots
on 64-bit hosts, but does not account for the size being truncated on
32-bit hosts in various flows. T
On 04.11.2021 01:25, Sean Christopherson wrote:
When modifying memslots, snapshot the "old" memslot and copy it to the
"new" memslot's arch data after (re)acquiring slots_arch_lock. x86 can
change a memslot's arch data while memslot updates are in-progress so
long as it holds slots_arch_lock, th
26 matches
Mail list logo
