David Woodhouse <dwmw2@xxxxxxxxxxxxx> writes: > On 14 December 2020 21:41:23 GMT, Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> wrote: >>>Your change is correct but I'm not sure that it's entirely clear that >>kvm_map_gfn() implicitly uses 'as_id=0' and I don't even see a comment >>about the fact :-( > > Isn't that true of all the kvm_read_guest and kvm_write_guest > functions and indeed of kvm_memslots() itself? Yes, sadly. Multiple address spaces support was added to KVM as a generic feature but the only use-case for it at this moment is SMM on x86 which is 'special', i.e. currently there's only one user for kvm_map_gfn()/kvm_unmap_gfn() which is steal time accounting and it's not easy to come up with a use-case when this PV feature needs to be used from SMM. On the other hand, if we try using multiple address spaces in KVM for e.g. emulating something like Hyper-V VSM, it becomes unclear which address space id needs to be used even for steal time. To be entirely correct, we probably need to remember as_id which was active when steal time was enabled and stick to it later when we want to update the data. If we do that, kvm_map_gfn() will lose its only user. All the above doesn't make your patch incorrect of course, I just used it to express my observation that we seem to be using as_id=0 blindly and the API we have contributes to that. -- Vitaly
