On Thu, Mar 30, 2023, Li,Rongqing wrote: > > From: Sean Christopherson <seanjc@xxxxxxxxxx> > > 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 Guest-side KVM stuff is not my maintenance domain, i.e. this needs Paolo's attention no matter what.
