On 08.07.2009, at 10:01, Benjamin Herrenschmidt wrote:
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.
PA-Semi, maybe rs64 (not sure, I have some vague memories here though
the later is only supported on some legacy iSeries which we may not
care
about... the kernel cputable still says 128 though, but maybe the
device-tree says otherwise).
Also, for 32-bit, there's some e500's that have 64 byte cache line
size
and I know of at least one thing not released yet that will be 32-bits
and will have 128 d-side and 32 i-side :-) (so it can be tricked into
making look like i side is 128 too).
Sounds like all of those are potential guest CPUs, but probably not
host :-).
E500 has its own KVM implementation, as does 440. So I don't think
we'll run into dcbz issues again in the near future.
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.
Right. As long as the guest OS does the right thing, which afaik only
linux 64-bit does at the moment, though we plan to fix linux 32-bit.
MacOS always sets the HID5 dcbz32 bit and assumes 128 bytes for
dcbzl.
Which will be a problem on processor that don't support that bit..
your
patching technique is interesting though. It should probably remain an
option in case it causes trouble.
For MacOS X, it's reasonably easy to fix things up with paravirt
extensions to a certain extent. For MOL, we have some optional add-ons
you can install inside OS X that patch its kernel in various ways to
make it work better/faster in MOL by avoiding some nasty constructs,
such as abuse of split MMU mode (IR clear DR set or the other way
around) (thanks for Apple publishing their source code here :-)
What about userspace applications that use dcbz?
But to run Mac OS X we first have to fix quite a lot of qemu stuff
anyways ;-). It might also make sense to only run osx in PPC32 mode,
as the PPC64 one doesn't add that much value.
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.
Well, most 32-bit "S" processors don't support NX at the PTE level
anyway, only at the segment level.
Which is all the same from my code's perspective. Host segments are
just mapped unconditionally while the real handling happens on a per-
page basis. So if the guest sets NX on a segment, it ends up as NX in
every host page we map.
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
