Re: [kvm-ppc-devel] Current e500 kvm guest kernel booting log

[Hollis Blanchard <hollisb@us.ibm.com>]

On Wed, 2007-12-12 at 19:57 +0800, Zhang Wei wrote:
> > 
> > Congratulations! :) Will you send patches? What are your 
> > thoughts on the
> > commonality between 440 and e500 code?
> 
> Thanks! The MMU and some core registers are different, but almost of the
> other can be reused. So I change 440 TLB functions to core independence
> API and add an exceptions_e500.S file.

Interesting, good to know.
 
> > We haven't touched the "hack" code recently, since we've been
> > refactoring the upstream tree. That's pretty much done 
> > though, and right
> > now I'm just starting to integrate the old 440 support with the new
> > upstream code. That's not in a good state right now, but I could clean
> > it up and send it out if you're interested.
> 
> Yes! I think hack codes are only for verifying the idea. Our target is
> for upstream code. I hope I could join you!

Well, unfortunately at the moment I'm just fighting with
asm-offsets.h . :( Since I'm basically already on vacation, I'm not sure
I'll be able to get anything ready until January.

> > Also, I'm messing around with Makefiles now, and have been thinking
> > about how to connect the modules... For example, should there be a
> > kvm-powerpc-guest-440.ko that could link with 
> > kvm-powerpc-host-e500.ko?
> > For now, a single kvm-powerpc-e500.ko (e500 guests on e500 host) is
> > probably easiest, but we should think about the long-term goal too.
> > 
> 
> I will make some studies about this. What's kvm-guest-xxx.ko and
> kvm-host-xxx.ko?
> Why not one kvm-powerpc.ko?

Books 1 and 2 are (more or less) identical across PowerPC. Book 3 is
where the big differences are, but we are emulating all Book 3 stuff in
software. That means we can emulate whatever Book 3 we want; we don't
need to run only e500 guests on e500 hosts.

So, we could in theory have a module that e.g. emulates the e500 Book 3,
which we'd call something like kvm-powerpc-e500-guest.ko. If we emulate
tlbwe with HTAB modifications, we could run e500 guests on an e600. We
would call the module with the HTAB logic something like
kvm-powerpc-e600-host.ko.

The important point for the MMU is that all PPC have the concept of a
virtual address, which is an effective address + some context
identifier. On classic or server PPC, that context comes from
segmentation (SRs, SLB, or STAB), whereas on Book E the context is AS +
PID.

It's just a (maybe crazy) idea, but if we're clever we might actually
get it to work. Of course, since you guys have a few different embedded
cores, that might be of more interest to your company than mine...

> > By the way, we booted with an initrd so we wouldn't need the network,
> > and hacked the device tree not to use interrupts for the UART. If you
> > take shortcuts like that you can really minimize your 
> > dependency on qemu for now.
> 
> How about the qemu position in our roadmap? If it still be the key role,
> I'll have to add some e500 hw drivers into it.

Yeah, that's a good question. I believe that emulating complex IP blocks
(e.g. IBM EMAC, Freescale TSEC) would take significant effort. Instead
I'm going to be trying alternatives, such as an x86-like "virtual board"
or virtual IO drivers.

In the first case, you pretend you have a bare core (without any SoC
peripherals) on a board with x86 devices. Qemu supports a set of x86
devices, so instead of writing all the TSEC emulation, you would just
tell the guest it has a Realtek NIC. Guests may already have device
drivers for "standard" devices like these.

Qemu will also gain virtual IO support in the future, which is basically
idealized IO devices to increase performance by using a
virtualization-friendly design (e.g. minimize MMIO accesses). The down
side is that guests would need new device drivers for this.

That said, we'd probably want to stick with emulated versions of
simple/critical PPC devices like the interrupt controller, so you might
have a little work to do there.

Personally I don't think writing all the SoC device emulation from
scratch is a realistic goal, at least not for me. You're welcome to
prioritize whatever you want of course. :)

-- 
Hollis Blanchard
IBM Linux Technology Center


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel