On Tue, 2022-11-22 at 19:09 +0000, Sean Christopherson wrote: > On Tue, Nov 22, 2022, David Woodhouse wrote: > > On Tue, 2022-11-22 at 16:49 +0000, Paul Durrant wrote: > > > > Tags need your real name, not just your email address, i.e. this should be: > > > > Reviewed-by: Paul Durrant <paul@xxxxxxx> > > > > > > Yes indeed it should. Don't know how I managed to screw that up... It's > > > not like haven't type that properly hundreds of times on Xen patch reviews. > > > > All sorted in the tree I'm curating > > https://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/gpc-fixes > > > > > > Of those, three are marked as Cc:stable and want to go into the 6.1 release: > > > > KVM: x86/xen: Validate port number in SCHEDOP_poll > > KVM: x86/xen: Only do in-kernel acceleration of hypercalls for guest CPL0 > > KVM: Update gfn_to_pfn_cache khva when it moves within the same page > > > > The rest (including the runstate compatibility fixes) are less > > critical. > > > > Sean, given that this now includes your patch series which in turn you > > took over from Michal, how would you prefer me to proceed? > > If you're ok with a slight delay for fixing the runstate stuff, I think it makes > sense to push out everything else to fixes out to 6.3. I can live with that. Will post those three fixes. > At the very least, I want to explore using a gfn_to_hva_cache > instead of two gfn_to_pfn_cache structures for the runstate, which at > this point would be a bit rushed for 6.2. As noted, I think we'd need two gfn_to_hva_caches anyway. But happy to explore options. > Pushing out to 6.3 will also give us time to do the more aggressive cleanup of > adding kvm_gpc_lock(), which I think will yield APIs that both of us are happy with, > i.e. the gpa+len of the cache can be immutable, but users can still validate their > individual usage. Yeah. The kvm_gpc_lock() thing is another one I just couldn't see a clean one-size-fits-all solution for with irqsave and not-irqsave variants, and different conditions (and other locks to drop) between the check() failing and the refresh() occurring... but if we can make a helper which covers the *common* case without ending up being just an obfuscation, that's a win.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
