On 08.07.2009, at 08:17, Benjamin Herrenschmidt wrote:
On Tue, 2009-07-07 at 17:44 +0200, Arnd Bergmann wrote:
Most of the code is after 970 but does look generic enough to be
usable
on other powerpc64 implementations. How specific to 970 is it really?
Maybe the files and identifiers could be renamed to ppc64?
You mentioned before that you could not get ppc32 guests to run on
Cell hosts, but how about 970 or cell guests? Are there any problems
that mean it cannot work on Power5/6/7 hosts, or was that just a
matter of your priorities and available test hardware?
There is another problem I foresee which is the cache line size
difference.... That can not be emulated.
The cache line sizes vary between processors, that is, the problem is
not only classic 32 "32 bytes" vs. classic 64 "128 bytes", some CPUs
have 64 bytes cache line size for example too.
Which non-booke CPUs have 64 byte cache line size? I thought all BookS
PPC64 ones are on 128 bytes.
However, we can somewhat work around. At least 64-bit linux uses the
cache line size from the device-tree for example and overrides the
cputable content with that.
So if we manage to pass a "manufactures" device-tree down, we can cope
with the differences to some extent.
Well, we only need to tell our guest firmware what the host cache line
size is, which qemu knows already, as it's passed to userspace.
Things are going to be harder if the goal is to run some other OS, of
course, to the extent that we may not be able to sort it out
completely
but at least for the linux-in-linux case it should work. For
example, I
think MacOS uses the PVR and ignores the device-tree values...
MacOS always sets the HID5 dcbz32 bit and assumes 128 bytes for dcbzl.
Unfortunately, 32-bit linux does the same, though there is some work
in
progress to change that, so it won't be a problem in the long run.
It'd be really nice to have 32-bit Linux be a bit more clever about
this. Right now I have a dcbz hack in that makes all dcbz basically be
dcbz32 when running in book3s_32 mode or HID5.dcbz32 = 1 for book3s_64.
That hack is either achieved by setting HID5.dcbz32 = 1 on the host
(if possible) or by runtime binary patching of the guest.
The patching technique Alexander does on executable pages is fun :-)
Though it's also both a bit slow and potentially dangerous (you don't
know for sure that what you are patching is actually an instruction).
Yeah, we also lose nx capabilites in the guest atm. We're rather safe
on not patching data by only patching on execution, but you're right -
there could still be data in executed pages.
Maybe it should be a configuration option to only be enabled when
needed.
It _is_ needed for every possible configuration atm :-). PPC32 Linux
doesn't boot without. PPC64 Linux doesn't set dcbz32.
Alex
--
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
