> -----Original Message----- > From: Sean Christopherson <seanjc@xxxxxxxxxx> > Sent: Friday, March 17, 2023 1:01 AM > To: Li,Rongqing <lirongqing@xxxxxxxxx> > Cc: kvm@xxxxxxxxxxxxxxx; x86@xxxxxxxxxx; Paolo Bonzini > <pbonzini@xxxxxxxxxx>; Wanpeng Li <wanpengli@xxxxxxxxxxx>; Vitaly > Kuznetsov <vkuznets@xxxxxxxxxx> > Subject: Re: [PATCH] x86/kvm: refine condition for checking vCPU preempted > > On Thu, Mar 16, 2023, Li,Rongqing wrote: > > > From: Sean Christopherson <seanjc@xxxxxxxxxx> On Wed, Mar 15, 2023, > > > Li,Rongqing wrote: > > > > > Rather than have the guest rely on host KVM behavior clearing > > > > > PV_UNHALT when HLT is passed through), would it make sense to > > > > > add something like KVM_HINTS_HLT_PASSTHROUGH to more explicitly > > > > > tell the guest that HLT isn't intercepted? > > > > > > > > KVM_HINTS_HLT_PASSTHROUGH is more obvious, but it need both kvm > > > > and guest support > > > > > > Yeah, that's the downside. But modifying KVM and/or the userspace > > > VMM shouldn't be difficult, i.e the only meaningful cost is the > > > rollout of a new kernel/VMM. > > > > > > On the other hand, establishing the heuristic that !PV_UNHALT == > > > HLT_PASSTHROUGH could have to subtle issues in the future. It > > > safe-ish in the context of this patch as userspace is unlikely to > > > set KVM_HINTS_REALTIME, hide PV_UNHALT, and _not_ passthrough HLT. > > > But without the REALTIME side of things, !PV_UNHALT == > HLT_PASSTHROUGH is much less likely to hold true. > > > > Ok, could you submit these codes > > I'd like to hear from others first, especially Paolo and/or Wanpeng. I see no progress How about to adopt this patch at first, it can give small performance for existing KVM and setup Then you continue to modify the kernel/VMM to give better support for KVM/guest -Li
