mbox series

[v4,00/20] KVM RISC-V Support

Message ID 20190807122726.81544-1-anup.patel@wdc.com (mailing list archive)
Headers show
Series KVM RISC-V Support | expand

Message

Anup Patel Aug. 7, 2019, 12:27 p.m. UTC 
This series adds initial KVM RISC-V support. Currently, we are able to boot
RISC-V 64bit Linux Guests with multiple VCPUs.

Few key aspects of KVM RISC-V added by this series are:
1. Minimal possible KVM world-switch which touches only GPRs and few CSRs.
2. Full Guest/VM switch is done via vcpu_get/vcpu_put infrastructure.
3. KVM ONE_REG interface for VCPU register access from user-space.
4. PLIC emulation is done in user-space. In-kernel PLIC emulation, will
   be added in future.
5. Timer and IPI emuation is done in-kernel.
6. MMU notifiers supported.
7. FP lazy save/restore supported.
8. SBI v0.1 emulation for KVM Guest available.

Here's a brief TODO list which we will work upon after this series:
1. Handle trap from unpriv access in reading Guest instruction
2. Handle trap from unpriv access in SBI v0.1 emulation
3. Implement recursive stage2 page table programing
4. SBI v0.2 emulation in-kernel
5. SBI v0.2 hart hotplug emulation in-kernel
6. In-kernel PLIC emulation
7. ..... and more .....

This series can be found in riscv_kvm_v4 branch at:
https//github.com/avpatel/linux.git

Our work-in-progress KVMTOOL RISC-V port can be found in riscv_v1 branch at:
https//github.com/avpatel/kvmtool.git

We need OpenSBI with RISC-V hypervisor extension support which can be
found in hyp_ext_changes_v1 branch at:
https://github.com/riscv/opensbi.git

The QEMU RISC-V hypervisor emulation is done by Alistair and is available
in riscv-hyp-work.next branch at:
https://github.com/alistair23/qemu.git

To play around with KVM RISC-V, here are few reference commands:
1) To cross-compile KVMTOOL:
   $ make lkvm-static
2) To launch RISC-V Host Linux:
   $ qemu-system-riscv64 -monitor null -cpu rv64,h=true -M virt \
   -m 512M -display none -serial mon:stdio \
   -kernel opensbi/build/platform/qemu/virt/firmware/fw_jump.elf \
   -device loader,file=build-riscv64/arch/riscv/boot/Image,addr=0x80200000 \
   -initrd ./rootfs_kvm_riscv64.img \
   -append "root=/dev/ram rw console=ttyS0 earlycon=sbi"
3) To launch RISC-V Guest Linux with 9P rootfs:
   $ ./apps/lkvm-static run -m 128 -c2 --console serial \
   -p "console=ttyS0 earlycon=uart8250,mmio,0x3f8" -k ./apps/Image --debug
4) To launch RISC-V Guest Linux with initrd:
   $ ./apps/lkvm-static run -m 128 -c2 --console serial \
   -p "console=ttyS0 earlycon=uart8250,mmio,0x3f8" -k ./apps/Image \
   -i ./apps/rootfs.img --debug

Changes since v3:
- Moved patch for ISA bitmap from KVM prep series to this series
- Make vsip_shadow as run-time percpu variable instead of compile-time
- Flush Guest TLBs on all Host CPUs whenever we run-out of VMIDs

Changes since v2:
- Removed references of KVM_REQ_IRQ_PENDING from all patches
- Use kvm->srcu within in-kernel KVM run loop
- Added percpu vsip_shadow to track last value programmed in VSIP CSR
- Added comments about irqs_pending and irqs_pending_mask
- Used kvm_arch_vcpu_runnable() in-place-of kvm_riscv_vcpu_has_interrupt()
  in system_opcode_insn()
- Removed unwanted smp_wmb() in kvm_riscv_stage2_vmid_update()
- Use kvm_flush_remote_tlbs() in kvm_riscv_stage2_vmid_update()
- Use READ_ONCE() in kvm_riscv_stage2_update_hgatp() for vmid

Changes since v1:
- Fixed compile errors in building KVM RISC-V as module
- Removed unused kvm_riscv_halt_guest() and kvm_riscv_resume_guest()
- Set KVM_CAP_SYNC_MMU capability only after MMU notifiers are implemented
- Made vmid_version as unsigned long instead of atomic
- Renamed KVM_REQ_UPDATE_PGTBL to KVM_REQ_UPDATE_HGATP
- Renamed kvm_riscv_stage2_update_pgtbl() to kvm_riscv_stage2_update_hgatp()
- Configure HIDELEG and HEDELEG in kvm_arch_hardware_enable()
- Updated ONE_REG interface for CSR access to user-space
- Removed irqs_pending_lock and use atomic bitops instead
- Added separate patch for FP ONE_REG interface
- Added separate patch for updating MAINTAINERS file

Anup Patel (15):
  KVM: RISC-V: Add KVM_REG_RISCV for ONE_REG interface
  RISC-V: Add bitmap reprensenting ISA features common across CPUs
  RISC-V: Add hypervisor extension related CSR defines
  RISC-V: Add initial skeletal KVM support
  RISC-V: KVM: Implement VCPU create, init and destroy functions
  RISC-V: KVM: Implement VCPU interrupts and requests handling
  RISC-V: KVM: Implement KVM_GET_ONE_REG/KVM_SET_ONE_REG ioctls
  RISC-V: KVM: Implement VCPU world-switch
  RISC-V: KVM: Handle MMIO exits for VCPU
  RISC-V: KVM: Handle WFI exits for VCPU
  RISC-V: KVM: Implement VMID allocator
  RISC-V: KVM: Implement stage2 page table programming
  RISC-V: KVM: Implement MMU notifiers
  RISC-V: Enable VIRTIO drivers in RV64 and RV32 defconfig
  RISC-V: KVM: Add MAINTAINERS entry

Atish Patra (5):
  RISC-V: Export few kernel symbols
  RISC-V: KVM: Add timer functionality
  RISC-V: KVM: FP lazy save/restore
  RISC-V: KVM: Implement ONE REG interface for FP registers
  RISC-V: KVM: Add SBI v0.1 support

 MAINTAINERS                             |  10 +
 arch/riscv/Kconfig                      |   2 +
 arch/riscv/Makefile                     |   2 +
 arch/riscv/configs/defconfig            |  13 +
 arch/riscv/configs/rv32_defconfig       |  13 +
 arch/riscv/include/asm/csr.h            |  58 ++
 arch/riscv/include/asm/hwcap.h          |  26 +
 arch/riscv/include/asm/kvm_host.h       | 246 ++++++
 arch/riscv/include/asm/kvm_vcpu_timer.h |  32 +
 arch/riscv/include/asm/pgtable-bits.h   |   1 +
 arch/riscv/include/uapi/asm/kvm.h       |  98 +++
 arch/riscv/kernel/asm-offsets.c         | 148 ++++
 arch/riscv/kernel/cpufeature.c          |  79 +-
 arch/riscv/kernel/smp.c                 |   2 +-
 arch/riscv/kernel/time.c                |   1 +
 arch/riscv/kvm/Kconfig                  |  34 +
 arch/riscv/kvm/Makefile                 |  14 +
 arch/riscv/kvm/main.c                   |  92 +++
 arch/riscv/kvm/mmu.c                    | 905 ++++++++++++++++++++++
 arch/riscv/kvm/tlb.S                    |  43 ++
 arch/riscv/kvm/vcpu.c                   | 989 ++++++++++++++++++++++++
 arch/riscv/kvm/vcpu_exit.c              | 556 +++++++++++++
 arch/riscv/kvm/vcpu_sbi.c               | 119 +++
 arch/riscv/kvm/vcpu_switch.S            | 368 +++++++++
 arch/riscv/kvm/vcpu_timer.c             | 106 +++
 arch/riscv/kvm/vm.c                     |  86 +++
 arch/riscv/kvm/vmid.c                   | 123 +++
 drivers/clocksource/timer-riscv.c       |   8 +
 include/clocksource/timer-riscv.h       |  16 +
 include/uapi/linux/kvm.h                |   1 +
 30 files changed, 4187 insertions(+), 4 deletions(-)
 create mode 100644 arch/riscv/include/asm/kvm_host.h
 create mode 100644 arch/riscv/include/asm/kvm_vcpu_timer.h
 create mode 100644 arch/riscv/include/uapi/asm/kvm.h
 create mode 100644 arch/riscv/kvm/Kconfig
 create mode 100644 arch/riscv/kvm/Makefile
 create mode 100644 arch/riscv/kvm/main.c
 create mode 100644 arch/riscv/kvm/mmu.c
 create mode 100644 arch/riscv/kvm/tlb.S
 create mode 100644 arch/riscv/kvm/vcpu.c
 create mode 100644 arch/riscv/kvm/vcpu_exit.c
 create mode 100644 arch/riscv/kvm/vcpu_sbi.c
 create mode 100644 arch/riscv/kvm/vcpu_switch.S
 create mode 100644 arch/riscv/kvm/vcpu_timer.c
 create mode 100644 arch/riscv/kvm/vm.c
 create mode 100644 arch/riscv/kvm/vmid.c
 create mode 100644 include/clocksource/timer-riscv.h

--
2.17.1

Comments

Paolo Bonzini Aug. 7, 2019, 8:09 p.m. UTC | #1 
On 07/08/19 14:27, Anup Patel wrote:
> This series adds initial KVM RISC-V support. Currently, we are able to boot
> RISC-V 64bit Linux Guests with multiple VCPUs.

Looks good to me!  Still need an Acked-by from arch/riscv folks if I
have to merge it, otherwise they can take care of the initial merge.

Paolo

> Few key aspects of KVM RISC-V added by this series are:
> 1. Minimal possible KVM world-switch which touches only GPRs and few CSRs.
> 2. Full Guest/VM switch is done via vcpu_get/vcpu_put infrastructure.
> 3. KVM ONE_REG interface for VCPU register access from user-space.
> 4. PLIC emulation is done in user-space. In-kernel PLIC emulation, will
>    be added in future.
> 5. Timer and IPI emuation is done in-kernel.
> 6. MMU notifiers supported.
> 7. FP lazy save/restore supported.
> 8. SBI v0.1 emulation for KVM Guest available.
> 
> Here's a brief TODO list which we will work upon after this series:
> 1. Handle trap from unpriv access in reading Guest instruction
> 2. Handle trap from unpriv access in SBI v0.1 emulation
> 3. Implement recursive stage2 page table programing
> 4. SBI v0.2 emulation in-kernel
> 5. SBI v0.2 hart hotplug emulation in-kernel
> 6. In-kernel PLIC emulation
> 7. ..... and more .....
> 
> This series can be found in riscv_kvm_v4 branch at:
> https//github.com/avpatel/linux.git
> 
> Our work-in-progress KVMTOOL RISC-V port can be found in riscv_v1 branch at:
> https//github.com/avpatel/kvmtool.git
> 
> We need OpenSBI with RISC-V hypervisor extension support which can be
> found in hyp_ext_changes_v1 branch at:
> https://github.com/riscv/opensbi.git
> 
> The QEMU RISC-V hypervisor emulation is done by Alistair and is available
> in riscv-hyp-work.next branch at:
> https://github.com/alistair23/qemu.git
> 
> To play around with KVM RISC-V, here are few reference commands:
> 1) To cross-compile KVMTOOL:
>    $ make lkvm-static
> 2) To launch RISC-V Host Linux:
>    $ qemu-system-riscv64 -monitor null -cpu rv64,h=true -M virt \
>    -m 512M -display none -serial mon:stdio \
>    -kernel opensbi/build/platform/qemu/virt/firmware/fw_jump.elf \
>    -device loader,file=build-riscv64/arch/riscv/boot/Image,addr=0x80200000 \
>    -initrd ./rootfs_kvm_riscv64.img \
>    -append "root=/dev/ram rw console=ttyS0 earlycon=sbi"
> 3) To launch RISC-V Guest Linux with 9P rootfs:
>    $ ./apps/lkvm-static run -m 128 -c2 --console serial \
>    -p "console=ttyS0 earlycon=uart8250,mmio,0x3f8" -k ./apps/Image --debug
> 4) To launch RISC-V Guest Linux with initrd:
>    $ ./apps/lkvm-static run -m 128 -c2 --console serial \
>    -p "console=ttyS0 earlycon=uart8250,mmio,0x3f8" -k ./apps/Image \
>    -i ./apps/rootfs.img --debug
> 
> Changes since v3:
> - Moved patch for ISA bitmap from KVM prep series to this series
> - Make vsip_shadow as run-time percpu variable instead of compile-time
> - Flush Guest TLBs on all Host CPUs whenever we run-out of VMIDs
Paul Walmsley Aug. 7, 2019, 11:15 p.m. UTC | #2 
On Wed, 7 Aug 2019, Paolo Bonzini wrote:

> On 07/08/19 14:27, Anup Patel wrote:
> > This series adds initial KVM RISC-V support. Currently, we are able to boot
> > RISC-V 64bit Linux Guests with multiple VCPUs.
> 
> Looks good to me!  Still need an Acked-by from arch/riscv folks if I
> have to merge it, otherwise they can take care of the initial merge.

Since almost all of the patches touch arch/riscv files, we'll plan to 
merge them through the RISC-V tree.  Care to ack patch one, and send tags 
for any other patches as you think might be appropriate?

At the moment we're focused on dealing with a TLB flush-related critical 
stability bug in RISC-V kernel land.  Once that gets cleared up, we'll 
start pulling stuff in for the merge window.

Thanks for the speedy review,


- Paul
Paolo Bonzini Aug. 8, 2019, 8:54 a.m. UTC | #3 
On 08/08/19 01:15, Paul Walmsley wrote:
> On Wed, 7 Aug 2019, Paolo Bonzini wrote:
> 
>> On 07/08/19 14:27, Anup Patel wrote:
>>> This series adds initial KVM RISC-V support. Currently, we are able to boot
>>> RISC-V 64bit Linux Guests with multiple VCPUs.
>>
>> Looks good to me!  Still need an Acked-by from arch/riscv folks if I
>> have to merge it, otherwise they can take care of the initial merge.
> 
> Since almost all of the patches touch arch/riscv files, we'll plan to 
> merge them through the RISC-V tree.  Care to ack patch one, and send tags 
> for any other patches as you think might be appropriate?

Patch 1, 3-20:

Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>

In your 5.4 pull requests, it's best if you add a note that all RISC-V
KVM patches were acked and reviewed by me.  I'll also include a shoutout
about RISC-V KVM in my own pull request.

However, for Linux releases after 5.4 I would rather get pull requests
for arch/riscv/kvm from Anup and Atish without involving the RISC-V
tree.  Of course, they or I will ask for your ack, or for a topic
branch, on the occasion that something touches files outside their
maintainership area.  This is how things are already being handled for
ARM, POWER and s390 and it allows me to handle conflicts in common KVM
files before they reach Linus; these are more common than conflicts in
arch files.  If you have further questions on git and maintenance
workflows, just ask!

Paolo
Paul Walmsley Aug. 9, 2019, 1:35 a.m. UTC | #4 
On Thu, 8 Aug 2019, Paolo Bonzini wrote:

> However, for Linux releases after 5.4 I would rather get pull requests 
> for arch/riscv/kvm from Anup and Atish without involving the RISC-V 
> tree.  Of course, they or I will ask for your ack, or for a topic 
> branch, on the occasion that something touches files outside their 
> maintainership area.  This is how things are already being handled for 
> ARM, POWER and s390 and it allows me to handle conflicts in common KVM 
> files before they reach Linus; these are more common than conflicts in 
> arch files. If you have further questions on git and maintenance 
> workflows, just ask!

In principle, that's fine with me, as long as the arch/riscv maintainers 
and mailing lists are kept in the loop.  We already do something similar 
to this for the RISC-V BPF JIT.  However, I'd like this to be explicitly 
documented in the MAINTAINERS file, as it is for BPF.  It looks like it 
isn't for ARM, POWER, or S390, either looking at MAINTAINERS or 
spot-checking scripts/get_maintainer.pl:

$ scripts/get_maintainer.pl -f arch/s390/kvm/interrupt.c 
Christian Borntraeger <borntraeger@de.ibm.com> (supporter:KERNEL VIRTUAL MACHINE for s390 (KVM/s390))
Janosch Frank <frankja@linux.ibm.com> (supporter:KERNEL VIRTUAL MACHINE for s390 (KVM/s390))
David Hildenbrand <david@redhat.com> (reviewer:KERNEL VIRTUAL MACHINE for s390 (KVM/s390))
Cornelia Huck <cohuck@redhat.com> (reviewer:KERNEL VIRTUAL MACHINE for s390 (KVM/s390))
Heiko Carstens <heiko.carstens@de.ibm.com> (supporter:S390)
Vasily Gorbik <gor@linux.ibm.com> (supporter:S390)
linux-s390@vger.kernel.org (open list:KERNEL VIRTUAL MACHINE for s390 (KVM/s390))
linux-kernel@vger.kernel.org (open list)
$

Would you be willing to send a MAINTAINERS patch to formalize this 
practice?


- Paul
Paolo Bonzini Aug. 9, 2019, 7:37 a.m. UTC | #5 
On 09/08/19 03:35, Paul Walmsley wrote:
> On Thu, 8 Aug 2019, Paolo Bonzini wrote:
> 
>> However, for Linux releases after 5.4 I would rather get pull requests 
>> for arch/riscv/kvm from Anup and Atish without involving the RISC-V 
>> tree.  Of course, they or I will ask for your ack, or for a topic 
>> branch, on the occasion that something touches files outside their 
>> maintainership area.  This is how things are already being handled for 
>> ARM, POWER and s390 and it allows me to handle conflicts in common KVM 
>> files before they reach Linus; these are more common than conflicts in 
>> arch files. If you have further questions on git and maintenance 
>> workflows, just ask!
> 
> In principle, that's fine with me, as long as the arch/riscv maintainers 
> and mailing lists are kept in the loop.  We already do something similar 
> to this for the RISC-V BPF JIT.  However, I'd like this to be explicitly 
> documented in the MAINTAINERS file, as it is for BPF.  It looks like it 
> isn't for ARM, POWER, or S390, either looking at MAINTAINERS or 
> spot-checking scripts/get_maintainer.pl:
> 
> $ scripts/get_maintainer.pl -f arch/s390/kvm/interrupt.c 
> Christian Borntraeger <borntraeger@de.ibm.com> (supporter:KERNEL VIRTUAL MACHINE for s390 (KVM/s390))
> Janosch Frank <frankja@linux.ibm.com> (supporter:KERNEL VIRTUAL MACHINE for s390 (KVM/s390))
> David Hildenbrand <david@redhat.com> (reviewer:KERNEL VIRTUAL MACHINE for s390 (KVM/s390))
> Cornelia Huck <cohuck@redhat.com> (reviewer:KERNEL VIRTUAL MACHINE for s390 (KVM/s390))
> Heiko Carstens <heiko.carstens@de.ibm.com> (supporter:S390)
> Vasily Gorbik <gor@linux.ibm.com> (supporter:S390)
> linux-s390@vger.kernel.org (open list:KERNEL VIRTUAL MACHINE for s390 (KVM/s390))
> linux-kernel@vger.kernel.org (open list)
> $
> 
> Would you be willing to send a MAINTAINERS patch to formalize this 
> practice?

Ah, I see, in the MAINTAINERS entry

KERNEL VIRTUAL MACHINE FOR RISC-V (KVM/riscv)
M:	Anup Patel <anup.patel@wdc.com>
R:	Atish Patra <atish.patra@wdc.com>
L:	linux-riscv@lists.infradead.org
T:	git git://github.com/avpatel/linux.git
S:	Maintained
F:	arch/riscv/include/uapi/asm/kvm*
F:	arch/riscv/include/asm/kvm*
F:	arch/riscv/kvm/

the L here should be kvm@vger.kernel.org.  arch/riscv/kvm/ files would
still match RISC-V ARCHITECTURE and therefore
linux-riscv@lists.infradead.org would be CCed.

Unlike other subsystems, for KVM I ask the submaintainers to include the
patches in their pull requests, which is why you saw no kvm@vger entry
for KVM/s390.  However, it's probably a good idea to add it and do the
same for RISC-V.

Is that what you meant?

Paolo
Anup Patel Aug. 9, 2019, 8:22 a.m. UTC | #6 
On Fri, Aug 9, 2019 at 1:07 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 09/08/19 03:35, Paul Walmsley wrote:
> > On Thu, 8 Aug 2019, Paolo Bonzini wrote:
> >
> >> However, for Linux releases after 5.4 I would rather get pull requests
> >> for arch/riscv/kvm from Anup and Atish without involving the RISC-V
> >> tree.  Of course, they or I will ask for your ack, or for a topic
> >> branch, on the occasion that something touches files outside their
> >> maintainership area.  This is how things are already being handled for
> >> ARM, POWER and s390 and it allows me to handle conflicts in common KVM
> >> files before they reach Linus; these are more common than conflicts in
> >> arch files. If you have further questions on git and maintenance
> >> workflows, just ask!
> >
> > In principle, that's fine with me, as long as the arch/riscv maintainers
> > and mailing lists are kept in the loop.  We already do something similar
> > to this for the RISC-V BPF JIT.  However, I'd like this to be explicitly
> > documented in the MAINTAINERS file, as it is for BPF.  It looks like it
> > isn't for ARM, POWER, or S390, either looking at MAINTAINERS or
> > spot-checking scripts/get_maintainer.pl:
> >
> > $ scripts/get_maintainer.pl -f arch/s390/kvm/interrupt.c
> > Christian Borntraeger <borntraeger@de.ibm.com> (supporter:KERNEL VIRTUAL MACHINE for s390 (KVM/s390))
> > Janosch Frank <frankja@linux.ibm.com> (supporter:KERNEL VIRTUAL MACHINE for s390 (KVM/s390))
> > David Hildenbrand <david@redhat.com> (reviewer:KERNEL VIRTUAL MACHINE for s390 (KVM/s390))
> > Cornelia Huck <cohuck@redhat.com> (reviewer:KERNEL VIRTUAL MACHINE for s390 (KVM/s390))
> > Heiko Carstens <heiko.carstens@de.ibm.com> (supporter:S390)
> > Vasily Gorbik <gor@linux.ibm.com> (supporter:S390)
> > linux-s390@vger.kernel.org (open list:KERNEL VIRTUAL MACHINE for s390 (KVM/s390))
> > linux-kernel@vger.kernel.org (open list)
> > $
> >
> > Would you be willing to send a MAINTAINERS patch to formalize this
> > practice?
>
> Ah, I see, in the MAINTAINERS entry
>
> KERNEL VIRTUAL MACHINE FOR RISC-V (KVM/riscv)
> M:      Anup Patel <anup.patel@wdc.com>
> R:      Atish Patra <atish.patra@wdc.com>
> L:      linux-riscv@lists.infradead.org
> T:      git git://github.com/avpatel/linux.git
> S:      Maintained
> F:      arch/riscv/include/uapi/asm/kvm*
> F:      arch/riscv/include/asm/kvm*
> F:      arch/riscv/kvm/
>
> the L here should be kvm@vger.kernel.org.  arch/riscv/kvm/ files would
> still match RISC-V ARCHITECTURE and therefore
> linux-riscv@lists.infradead.org would be CCed.

In addition to above mentioned lists, we insist of having a separate
KVM RISC-V list which can be CCed for non-kernel patches for projects
such as QEMU, KVMTOOL, and Libvirt. This KVM RISC-V list can also
be used for general queries related to KVM RISCV.

>
> Unlike other subsystems, for KVM I ask the submaintainers to include the
> patches in their pull requests, which is why you saw no kvm@vger entry
> for KVM/s390.  However, it's probably a good idea to add it and do the
> same for RISC-V.

For KVM RISC-V, we will always CC both kvm@vger.kernel.org and
linux-riscv@lists.infradead.org.

Regards,
Anup
Paolo Bonzini Aug. 9, 2019, 9 a.m. UTC | #7 
On 09/08/19 10:22, Anup Patel wrote:
>> the L here should be kvm@vger.kernel.org.  arch/riscv/kvm/ files would
>> still match RISC-V ARCHITECTURE and therefore
>> linux-riscv@lists.infradead.org would be CCed.
> In addition to above mentioned lists, we insist of having a separate
> KVM RISC-V list which can be CCed for non-kernel patches for projects
> such as QEMU, KVMTOOL, and Libvirt. This KVM RISC-V list can also
> be used for general queries related to KVM RISCV.

You can use kvm@vger.kernel.org for that, with CCs to the other
appropriate list (qemu-devel, libvir-list, LKML, linux-riscv, etc.).
But if you want to have kvm-riscv, go ahead and ask for it.

In any case, you can send v5 with all R-b and Acked-by and a fixed
MAINTAINERS entry (listing kvm@vger for now), and Paul will apply it.
For 5.5 you can start sending patches to me, either for direct
application to the KVM tree or as pull requests.

Paolo
Anup Patel Aug. 9, 2019, 9:26 a.m. UTC | #8 
On Fri, Aug 9, 2019 at 2:30 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 09/08/19 10:22, Anup Patel wrote:
> >> the L here should be kvm@vger.kernel.org.  arch/riscv/kvm/ files would
> >> still match RISC-V ARCHITECTURE and therefore
> >> linux-riscv@lists.infradead.org would be CCed.
> > In addition to above mentioned lists, we insist of having a separate
> > KVM RISC-V list which can be CCed for non-kernel patches for projects
> > such as QEMU, KVMTOOL, and Libvirt. This KVM RISC-V list can also
> > be used for general queries related to KVM RISCV.
>
> You can use kvm@vger.kernel.org for that, with CCs to the other
> appropriate list (qemu-devel, libvir-list, LKML, linux-riscv, etc.).
> But if you want to have kvm-riscv, go ahead and ask for it.
>
> In any case, you can send v5 with all R-b and Acked-by and a fixed
> MAINTAINERS entry (listing kvm@vger for now), and Paul will apply it.
> For 5.5 you can start sending patches to me, either for direct
> application to the KVM tree or as pull requests.

Sure, I will send v5 early next week.

Regards,
Anup