[Qemu-devel] KVM Forum 2018 BoF Meeting minutes - architecture common code

[Christian Borntraeger]

Participants:
Christopher Dall, Marc Zyngier, Paolo Bonzini, Suraj Jitindar Singh, Frediano
Ziglio, Sean Christopherson, Radim Krcmar, Janosch Frank, Christian Borntraeger
+some more


- Discussion about common code for different architectures - initiated by my
  talk 
https://schd.ws/hosted_files/kvmforum2018/a0/Christian-Borntraegercrossarch.pdf
- We agreed that we as architecture maintainers should teach people during
  review about making things generic when applicable
- Problem: we do not understand "the other side" at all, e.g. one example in
  x86 code was: does spte means shadow page table or also nested pages (EPT)
- maybe we need a hack-a-thon to sit together and talk about this
- other idea: To see if we can factor out things, just provide a header file
  with "needed" interfaces and the pass that along to the other side

Things to look at:
- dirty log, now 2 common code variante (and arch specific ones)
- ordering of ioctl (e.g. qemu vs native kvm tool) triggered sometimes bugs on
  ARM - can we test this better and maybe also refactor some of the common
  checks
- api tests should be extended to all architectures
- rmap code for nested virtualization -> x86, power and now arm. All private
  copies (s390 uses radix to make it a 4th variant)
- can we avoid compiling virt/kvm/ from arch folders?
- Christopher also wants to look at nested page table faults (stage 2 faults on
  Arm), where on the Arm side we have a lot of code which is not arch-specific,
  but related to finding a page to back the fault, figuring out if the page is
  hugetlbfs, thp, page size, permission of page, and so on. This could expand to
  functionality for shadow page tables which we'll use for nested virt on Arm as
  well.  Things such as managing caches of shadow page tables for certain guest
  contexts, handling emulated TLB invalidations, etc. should have some
  commonality at least between x86 and Arm.


we agreed to have a meeting of arch maintainers either before or after next
KVM forum or independently. This will be discussed separately.  Christian
Borntraeger will kick of that discussion.