On Tue, Oct 15, 2024, Nikolas Wipper wrote:
> On 15.10.24 17:58, Sean Christopherson wrote:
> > ...
> >
> > And from a performance perspective, synchronizing on kvm->srcu is going to
> > be
> > susceptible to random slowdowns, because writers will have to wait until
> > all vCPUs
> > drop SRCU, e
On Tue, Oct 15, 2024, Nicolas Saenz Julienne wrote:
> Hi Sean,
>
> On Tue Oct 15, 2024 at 3:58 PM UTC, Sean Christopherson wrote:
> > Before we spend too much time cleaning things up, I want to first settle on
> > the
> > overall design, because it's not clear to me that punting
> > HvTranslateV
On 15.10.24 17:58, Sean Christopherson wrote:
> ...
>
> And from a performance perspective, synchronizing on kvm->srcu is going to be
> susceptible to random slowdowns, because writers will have to wait until all
> vCPUs
> drop SRCU, even if they have nothing to do with PV TLB flushes. E.g. if vC
Hi Sean,
On Tue Oct 15, 2024 at 3:58 PM UTC, Sean Christopherson wrote:
> Before we spend too much time cleaning things up, I want to first settle on
> the
> overall design, because it's not clear to me that punting
> HvTranslateVirtualAddress
> to userspace is a net positive. We agreed that VT
On Tue, Oct 15, 2024, Vitaly Kuznetsov wrote:
> Nikolas Wipper writes:
>
> > On 10.10.24 10:57, Vitaly Kuznetsov wrote:
>
> ...
>
> >>> int kvm_hv_vcpu_flush_tlb(struct kvm_vcpu *vcpu);
> >>> +
> >>> +static inline bool kvm_hv_vcpu_suspended(struct kvm_vcpu *vcpu)
> >>> +{
> >>> + return vcpu-
Nikolas Wipper writes:
> On 10.10.24 10:57, Vitaly Kuznetsov wrote:
...
>>> int kvm_hv_vcpu_flush_tlb(struct kvm_vcpu *vcpu);
>>> +
>>> +static inline bool kvm_hv_vcpu_suspended(struct kvm_vcpu *vcpu)
>>> +{
>>> + return vcpu->arch.hyperv_enabled &&
>>> + READ_ONCE(vcpu->arch.hyperv
On 10.10.24 10:57, Vitaly Kuznetsov wrote:
> Nikolas Wipper writes:
>> diff --git a/arch/x86/include/asm/kvm_host.h
>> b/arch/x86/include/asm/kvm_host.h
>> index 46e0a466d7fb..7571ac578884 100644
>> --- a/arch/x86/include/asm/kvm_host.h
>> +++ b/arch/x86/include/asm/kvm_host.h
>> @@ -695,6 +695,9
Nikolas Wipper writes:
> Introduce a suspension state for Hyper-V enlightened vCPUs. Microsoft's
> "Hypervisor Top Level Functional Specification" (TLFS) introduces this
> state as a "vCPU that is stopped on a instruction guest boundary, either
> explicitly or implicitly due to an intercept". The
Introduce a suspension state for Hyper-V enlightened vCPUs. Microsoft's
"Hypervisor Top Level Functional Specification" (TLFS) introduces this
state as a "vCPU that is stopped on a instruction guest boundary, either
explicitly or implicitly due to an intercept". The only documented
explicit suspens
