From: David Woodhouse <dwmw2@infradead.org> Date: 2021-11-16 11:52:20
On Mon, 2021-11-15 at 20:26 +0100, Paolo Bonzini wrote:
quoted
quoted
Also, for the small requests: since you are at it, can you add the code
in a new file under virt/kvm/?
Hm... only if I can make hva_to_pfn() and probably a handful of other
things non-static?
Yes, I think sooner or later we also want all pfn stuff in one file
(together with MMU notifiers) and all hva stuff in another; so for now
you can create virt/kvm/hva_to_pfn.h, or virt/kvm/mm.h, or whatever
color of the bikeshed you prefer.
OK... let's start with this.
David Woodhouse (7):
KVM: Introduce CONFIG_HAVE_KVM_DIRTY_RING
KVM: Add Makefile.kvm for common files, use it for x86
KVM: s390: Use Makefile.kvm for common files
KVM: mips: Use Makefile.kvm for common files
KVM: RISC-V: Use Makefile.kvm for common files
KVM: powerpc: Use Makefile.kvm for common files
KVM: arm64: Use Makefile.kvm for common files
arch/arm64/kvm/Makefile | 6 ++----
arch/mips/kvm/Makefile | 3 ++-
arch/powerpc/kvm/Makefile | 6 +-----
arch/riscv/kvm/Makefile | 6 +-----
arch/s390/kvm/Makefile | 6 ++----
arch/x86/kvm/Kconfig | 1 +
arch/x86/kvm/Makefile | 7 +------
include/linux/kvm_dirty_ring.h | 8 ++++----
virt/kvm/Kconfig | 3 +++
virt/kvm/Makefile.kvm | 13 +++++++++++++
virt/kvm/kvm_main.c | 4 ++--
11 files changed, 32 insertions(+), 31 deletions(-)
From: David Woodhouse <dwmw2@infradead.org> Date: 2021-11-16 11:52:36
From: David Woodhouse <redacted>
It's all fairly baroque but in the end, I don't think there's any reason
for $(KVM)/irqchip.o to have been handled differently, as they all end
up in $(kvm-y) in the end anyway, regardless of whether they get there
via $(common-objs-y) and the CPU-specific object lists.
The generic Makefile.kvm uses HAVE_KVM_IRQCHIP for irqchip.o instead of
HAVE_KVM_IRQ_ROUTING. That change is fine (and arguably correct) because
they are both set together for KVM_MPIC, or neither is set.
Signed-off-by: David Woodhouse <redacted>
---
arch/powerpc/kvm/Makefile | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
From: David Woodhouse <dwmw2@infradead.org> Date: 2021-11-16 11:52:46
From: David Woodhouse <redacted>
Splitting kvm_main.c out into smaller and better-organized files is
slightly non-trivial when it involves editing a bunch of per-arch
KVM makefiles. Provide virt/kvm/Makefile.kvm for them to include.
Signed-off-by: David Woodhouse <redacted>
---
arch/x86/kvm/Makefile | 7 +------
virt/kvm/Makefile.kvm | 13 +++++++++++++
2 files changed, 14 insertions(+), 6 deletions(-)
create mode 100644 virt/kvm/Makefile.kvm
From: David Woodhouse <dwmw2@infradead.org> Date: 2021-11-16 11:53:06
From: David Woodhouse <redacted>
I'd like to make the build include dirty_ring.c based on whether the
arch wants it or not. That's a whole lot simpler if there's a config
symbol instead of doing it implicitly on KVM_DIRTY_LOG_PAGE_OFFSET
being set to something non-zero.
Signed-off-by: David Woodhouse <redacted>
---
arch/x86/kvm/Kconfig | 1 +
include/linux/kvm_dirty_ring.h | 8 ++++----
virt/kvm/Kconfig | 3 +++
virt/kvm/kvm_main.c | 4 ++--
4 files changed, 10 insertions(+), 6 deletions(-)
@@ -2,9 +2,10 @@# Makefile for KVM support for MIPS#+include $(srctree)/virt/kvm/Makefile.kvm+ccflags-y+=-Ivirt/kvm-Iarch/mips/kvm-kvm-y:=$(addprefix../../../virt/kvm/,kvm_main.ocoalesced_mmio.oeventfd.obinary_stats.o)kvm-$(CONFIG_CPU_HAS_MSA)+=msa.okvm-y+=mips.oemulate.oentry.o\
From: Sean Christopherson <seanjc@google.com> Date: 2021-11-16 18:45:30
On Tue, Nov 16, 2021, David Woodhouse wrote:
From: David Woodhouse <redacted>
It's all fairly baroque but in the end, I don't think there's any reason
for $(KVM)/irqchip.o to have been handled differently, as they all end
up in $(kvm-y) in the end anyway, regardless of whether they get there
via $(common-objs-y) and the CPU-specific object lists.
The generic Makefile.kvm uses HAVE_KVM_IRQCHIP for irqchip.o instead of
HAVE_KVM_IRQ_ROUTING. That change is fine (and arguably correct) because
they are both set together for KVM_MPIC, or neither is set.
Nope.
Symbol: HAVE_KVM_IRQCHIP [=y]
Type : bool
Defined at virt/kvm/Kconfig:7
Selected by [m]:
- KVM_XICS [=y] && VIRTUALIZATION [=y] && KVM_BOOK3S_64 [=m] && !KVM_MPIC [=n]
Selected by [n]:
- KVM_MPIC [=n] && VIRTUALIZATION [=y] && KVM [=y] && E500 [=n]
leads to this and a whole pile of other errors
arch/powerpc/kvm/../../../virt/kvm/irqchip.c: In function ‘kvm_irq_map_gsi’:
arch/powerpc/kvm/../../../virt/kvm/irqchip.c:31:35: error: invalid use of undefined type ‘struct kvm_irq_routing_table’
31 | if (irq_rt && gsi < irq_rt->nr_rt_entries) {
| ^~
Side topic, please don't post a new version/series in-reply-to a different series.
b4 also gets confused in this case, e.g. it tried to grab the original patch. b4
has also made me really lazy, heaven forbid I actually had to manually grab these
from mutt :-)
From: David Woodhouse <dwmw2@infradead.org> Date: 2021-11-16 19:15:34
On Tue, 2021-11-16 at 18:43 +0000, Sean Christopherson wrote:
On Tue, Nov 16, 2021, David Woodhouse wrote:
quoted
From: David Woodhouse <redacted>
It's all fairly baroque but in the end, I don't think there's any reason
for $(KVM)/irqchip.o to have been handled differently, as they all end
up in $(kvm-y) in the end anyway, regardless of whether they get there
via $(common-objs-y) and the CPU-specific object lists.
The generic Makefile.kvm uses HAVE_KVM_IRQCHIP for irqchip.o instead of
HAVE_KVM_IRQ_ROUTING. That change is fine (and arguably correct) because
they are both set together for KVM_MPIC, or neither is set.
Nope.
Symbol: HAVE_KVM_IRQCHIP [=y]
Type : bool
Defined at virt/kvm/Kconfig:7
Selected by [m]:
- KVM_XICS [=y] && VIRTUALIZATION [=y] && KVM_BOOK3S_64 [=m] && !KVM_MPIC [=n]
Selected by [n]:
- KVM_MPIC [=n] && VIRTUALIZATION [=y] && KVM [=y] && E500 [=n]
leads to this and a whole pile of other errors
arch/powerpc/kvm/../../../virt/kvm/irqchip.c: In function ‘kvm_irq_map_gsi’:
arch/powerpc/kvm/../../../virt/kvm/irqchip.c:31:35: error: invalid use of undefined type ‘struct kvm_irq_routing_table’
31 | if (irq_rt && gsi < irq_rt->nr_rt_entries) {
| ^~
Hm, perhaps it should have been like this then (incremental):
Side topic, please don't post a new version/series in-reply-to a different series.
b4 also gets confused in this case, e.g. it tried to grab the original patch. b4
has also made me really lazy, heaven forbid I actually had to manually grab these
from mutt :-)
Sorry ;)
I think that one might even be a new series in reply to what was
already a second series on top of what I was *actually* trying to do
when I first started shaving this yak. Or maybe what I was originally
trying to implement has already been lost in the noise :)