Thanks Hollis for the pointer's..pls see inline.. -----Original Message----- From: Hollis Blanchard [mailto:hollisb@xxxxxxxxxx] Sent: Thursday, April 02, 2009 9:00 AM To: Liu Yu-B13201 Cc: Rahul Kulkarni; kvm-ppc@xxxxxxxxxxxxxxx Subject: RE: PowerPC KVM build directions On Thu, 2009-04-02 at 10:52 +0800, Liu Yu-B13201 wrote: > > > Since KVM supports a NetBSD 4.0 guest (I > > think) and 8544/e500 emulation is already present in qemu -- > > theoretically the first part should work...but I recall Liu > > mentioning that there might be some OS specific quirks > > present in the port...and that was what I my question was > > hinting at earlier.. > > There must be a lot of differences between Linux and NetBSD. > So the design of kvmppc may not be careful considerate. > > The main trick is to hijack the system interrupts. > You should check if this part of code cater to NetBSD. > Context switch needs to be taken care as well. > > At least there is one thing I can point out. > See comments in the file booke_interrupts.S line 195. :-) Liu, you're talking about BSD as the *host*. Rahul is asking about BSD as the guest. Rahul, one major quirk we exploit is that Linux does not use the MSR[AS] bit at all. One way that bit could be used is to give 32-bit userspace a separate 4GB address space from the kernel. Instead, Linux puts both kernel and userspace into the same 4GB address space (with Linux mappings above 0xc0000000 and user mappings below). If NetBSD uses MSR[AS]=1 for userspace (which I think is what the hardware architects envisioned), you're going to have a lot of MMU fun. Rahul>> The NetBSD port for e500/85xx which we have uses the MSR[AS] (IS/DS) for user/kernel address space separation which keep the address spaces split. So that's a major problem to start with. How do we get creative with this to provide guest mappings is something, which has to be explored. Let me know if you have any thoughts.. Another potential issue could be the initial environment (described earlier as option 2) not being what BSD expects. Do you use u-boot? You can see the initial environment set up in kvm_arch_vcpu_setup() in KVM and mpc8544ds_init() in Qemu. Rahul>> Yes..I will look into those functions..We do use uboot..Are you hinting to go with option 1? Does NetBSD use flattened device trees at all? KVM (Qemu) supplies a stripped-down device tree to the guest so that the guest won't try to access IO devices not currently emulated by qemu. If BSD has a hardcoded device configuration system (e.g. "we built for 8544, therefore we always have the following SoC devices") that will be an issue. Rahul>> The device config is hardcoded our NetBSD code base(more so because of the embedded nature it's a preferred way) but since I see NetBSD supported on Qemu..I would think there is a support available for a flattened device tree to be passed in from qemu..I'll look at x86 implementations. As a concrete example, qemu doesn't emulate the TSEC ethernet controller. You need to either convince your guest not to try to use the TSEC (and use e1000 or some other qemu-supported device instead), or add just enough TSEC emulation to qemu to make your guest happy. That could be as simple as always reporting "link down" so the guest doesn't try to use it. Rahul>> Yes ok.. Please keep us posted about any issues you encounter. Also, documenting the hurdles and how you overcame them might be an interesting conference paper, if you're into that sort of thing. :) Rahul>> Will do and hopefully we pull this off :> -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
