Re: [PATCH v2] KVM: x86: Fix recording of guest steal time / preempted status

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 3 November 2021 13:05:11 GMT, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
>On 11/3/21 13:56, David Woodhouse wrote:
>>> No need to resubmit, thanks!  I'll review the code later and
>>> decide whether to include this in 5.16 or go for the "good"
>>> solution in 5.16 and submit this one for 5.15 only.
>> I would call this the good solution for steal time. We really do
>> always have a userspace HVA for that when it matters, and we should
>> use it.
>> 
>> For Xen event channel delivery we have to do it from hardware
>> interrupts under arbitrary current->mm and we need a kernel mapping,
>> and we need the MMU notifiers and all that stuff. But for every
>> mapping we do that way, we need extra checks in the MMU notifiers.
>> 
>> For steal time there's just no need.
>
>Yes, but doing things by hand that it is slightly harder to get right, 
>between the asm and the manual user_access_{begin,end}.

Yes. Before I embarked on this I did have a fantasy that I could just use the futex asm helpers which already do much of that, but it didn't turn out that way. But once that part is done it shouldn't need to be touched again. It's only for the *locked* accesses like bit set and xchg; for anything else the normal user access works.

>The good solution would be to handle the remapping of _all_ gfn-to-pfn 
>caches from the MMU notifiers, so that you can still do map/unmap, keep 
>the code simple, and get for free the KVM-specific details such as 
>marking the gfn as dirty.
>
>When I was working on it before, I got stuck with wanting to do it not 
>just good but perfect, including the eVMCS page in it.  But that makes 
>no sense because really all that needs to be fixed is the _current_ 
>users of the gfn-to-pfn cache.

Yeah. Well, let's take a look at the Xen evtchn stuff and heckle the new rwlock I used, and the way we have to hold that lock *while* doing the access. Then we can ponder whether we want to offer that as a "generic" thing for providing a kernel mapping, and have the MMU notifiers walk a list of them to check for invalidation. Or whether we can actually use an HVA after all (and in at least some cases we really can).

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux