From: Jiaxun Yang <jiaxun.yang@flygoat.com>
To: maobibo <maobibo@loongson.cn>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
kvm@vger.kernel.org, Huacai Chen <chenhuacai@gmail.com>,
Fuxin Zhang <zhangfx@lemote.com>,
linux-mips@vger.kernel.org, qemu-devel@nongnu.org,
aleksandar.qemu.devel@gmail.com,
Paolo Bonzini <pbonzini@redhat.com>,
Huacai Chen <chenhc@lemote.com>,
lixing@loongson.cn
Subject: Re: [PATCH 0/15] KVM: MIPS: Add Loongson-3 support (Host Side)
Date: Tue, 14 Apr 2020 12:44:58 +0800 [thread overview]
Message-ID: <20200414124458.4675125b@flygoat-x1e> (raw)
In-Reply-To: <bbbeb507-5692-5969-c320-57d04823edc7@loongson.cn>
On Tue, 14 Apr 2020 09:40:26 +0800
maobibo <maobibo@loongson.cn> wrote:
> On 04/13/2020 04:18 PM, Jiaxun Yang wrote:
> > On Mon, 13 Apr 2020 15:30:09 +0800
> > Huacai Chen <chenhc@lemote.com> wrote:
> >
> >> We are preparing to add KVM support for Loongson-3. VZ extension is
> >> fully supported in Loongson-3A R4+, and we will not care about old
> >> CPUs (at least now). We already have a full functional Linux kernel
> >> (based on Linux-5.4.x LTS) and QEMU (based on 5.0.0-rc2) and their
> >> git repositories are here:
> >>
> >> QEMU: https://github.com/chenhuacai/qemu
> >> Kernel: https://github.com/chenhuacai/linux
> >>
> >> Of course these two repositories need to be rework and not suitable
> >> for upstream (especially the commits need to be splitted). We show
> >> them here is just to tell others what we have done, and how
> >> KVM/Loongson will look like.
> >>
> >> Our plan is make the KVM host side be upstream first, and after
> >> that, we will make the KVM guest side and QEMU emulator be
> >> upstream.
> >
> > + Aleksandar as QEMU/MIPS mainatiner
> >
> > I was involved in KVM/Loongson development a bit and also intend to
> > help with mainline these works.
> >
> > After dealing with basic LS7A PCH kernel support, I'm going to
> > cooperate with Huacai and anyone who interested in to deal with
> > following stuff:
> >
> > - Basic QEMU/TCG support for Loongson64 instructions.
> > Well, it seems unrelated with KVM, but that would make
> > development easier with cross ISA emulation. I'm not going
> > to implement all the features like Loongson's page table fast walk
> > extension and binary translation extension but I'll ensure
> > any binary compiled with march=loongson3a can run flawlessly on
> > TCG.
> >
> > - Design of Loongson-VIRT QEMU machine
> > It is nearly impossible to bring a real Loongson system into
> > QEMU. Both RS780E and LS7A PCH have tons of unreasonable
> > design that would make the emulation extremely complex, Loongson
> > company's KVM implementation[1] has already proofed that,
> > thay're now in the hell. So we all agreed that we should
> > build a machine from draft. I think we should reuse existing infra
> > as far as possible to reduce our work load. I'm planing to use
> > pci-host-cam-generic together with VIRTIO PCI devices and a
> > a strip down version of loongson,liointc-1.0a to build a
> > pure PCI based system. But if any one have better idea please just
> > tell us, I'm still considering how to implement SMP-IPI and
> > ACPI stuff.
Hi Bibo,
Thanks for your response.
+ Xing Li as I heard he is in charge of KVM from Loongson's news post.
> It is a good job to add kvm virtualization support on loongson64
> platform. I agree that we should define common virt machine hardware
> system, however the compiled kernel binary should be the same with
> host system, else it will bring out trouble for customers to
> differentiate them between guest system and host system.
I'm planing to use DeviceTree to pass device information between QEMU
and guest kernel. So we can upgrade VM design at any moment without
breaking Host Guest kernel compatibility.
> For pci host bridge emulation, I suggest that gpex pcie host bridge
> should be used, since it supports pcie hotplug and arm/riscv uses
> this pcie host bridge.
gpex is basically a pci-host-cam-generic at kernel point of view. I'm
planing to reuse it too.
>
> For virtual interrupt controller, it should support MSI/MSIX
> interrupt, irqchip in kernel, IRQFD, vhost/vfio etc. I have no idea
> how to define virtual interrupt controller now.
Yes, APIC from x86 and GIC from Arm are all bonded closely with their
architecture so we can't reuse them. Probably what we need is a
modified version of EXTIOI from Loongson-3A4000.
Does Loongson have a plan to implement hardware virtual irqchip? If so
we must align with it's design.
My plan is we can firstly implement a very simple IRQCHIP instead of
complex one which only handle UART and PCI INTx. That is enough to make
the system work. After that we can sit and discuss how to implement a
complicated version to archive more features.
>
>
> regards
> bibo,mao
>
[...]
next prev parent reply other threads:[~2020-04-14 4:46 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-13 7:30 [PATCH 0/15] KVM: MIPS: Add Loongson-3 support (Host Side) Huacai Chen
2020-04-13 7:30 ` [PATCH 01/15] mips: define pud_index() regardless of page table folding Huacai Chen
2020-04-13 7:30 ` [PATCH 02/15] KVM: MIPS: Define KVM_ENTRYHI_ASID to cpu_asid_mask(&boot_cpu_data) Huacai Chen
2020-04-21 19:56 ` Sasha Levin
2020-04-22 4:40 ` chen huacai
2020-04-13 7:30 ` [PATCH 03/15] KVM: MIPS: Fix VPN2_MASK definition for variable cpu_vmbits Huacai Chen
2020-04-21 19:56 ` Sasha Levin
2020-04-22 4:40 ` chen huacai
2020-04-13 7:30 ` [PATCH 04/15] KVM: MIPS: Increase KVM_MAX_VCPUS and KVM_USER_MEM_SLOTS to 16 Huacai Chen
2020-04-13 7:30 ` [PATCH 05/15] KVM: MIPS: Add EVENTFD support which is needed by VHOST Huacai Chen
2020-04-13 7:30 ` [PATCH 06/15] KVM: MIPS: Use lddir/ldpte instructions to lookup gpa_mm.pgd Huacai Chen
2020-04-13 7:30 ` [PATCH 07/15] KVM: MIPS: Introduce and use cpu_guest_has_ldpte Huacai Chen
2020-04-13 7:30 ` [PATCH 08/15] KVM: MIPS: Use root tlb to control guest's CCA for Loongson-3 Huacai Chen
2020-04-13 7:30 ` [PATCH 09/15] KVM: MIPS: Let indexed cacheops cause guest exit on Loongson-3 Huacai Chen
2020-04-13 7:30 ` [PATCH 10/15] KVM: MIPS: Add more types of virtual interrupts Huacai Chen
2020-04-13 7:30 ` [PATCH 11/15] KVM: MIPS: Add Loongson-3 Virtual IPI interrupt support Huacai Chen
2020-04-13 7:30 ` [PATCH 12/15] KVM: MIPS: Add CPUCFG emulation for Loongson-3 Huacai Chen
2020-04-13 7:30 ` [PATCH 13/15] KVM: MIPS: Add CONFIG6 and DIAG registers emulation Huacai Chen
2020-04-13 11:19 ` Jiaxun Yang
2020-04-19 9:58 ` Huacai Chen
2020-04-13 7:30 ` [PATCH 14/15] KVM: MIPS: Add more MMIO load/store instructions emulation Huacai Chen
2020-04-13 7:30 ` [PATCH 15/15] KVM: MIPS: Enable KVM support for Loongson-3 Huacai Chen
2020-04-13 8:18 ` [PATCH 0/15] KVM: MIPS: Add Loongson-3 support (Host Side) Jiaxun Yang
2020-04-13 9:20 ` Huacai Chen
2020-04-14 1:40 ` maobibo
2020-04-14 4:44 ` Jiaxun Yang [this message]
2020-04-19 9:42 ` Huacai Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200414124458.4675125b@flygoat-x1e \
--to=jiaxun.yang@flygoat.com \
--cc=aleksandar.qemu.devel@gmail.com \
--cc=chenhc@lemote.com \
--cc=chenhuacai@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=lixing@loongson.cn \
--cc=maobibo@loongson.cn \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=tsbogend@alpha.franken.de \
--cc=zhangfx@lemote.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).