On Tue, 14 Apr 2020 09:40:26 +0800
maobibo <maob...@loongson.cn> wrote:

> On 04/13/2020 04:18 PM, Jiaxun Yang wrote:
> > On Mon, 13 Apr 2020 15:30:09 +0800
> > Huacai Chen <che...@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
> 
[...]

Reply via email to