Re: [Qemu-devel] Removal of some target CPU macros

[J. Mayer]

On Wed, 2007-11-07 at 22:47 +0000, Paul Brook wrote:
> > Removing the ppc64h target means, for me, removing any option to emulate
> > the hypervisor feature at any time (if removed) or removing the ability
> > to use the PowerPC 64 targets the way they are when booting on Apple G5
> > machines (if merged with the ppc64 target). None of those options seem
> > acceptable to me.
> 
> ICBW, but it looks like it should be fairly straightforward to replace 
> TARGET_PPC64H with a runtime check. The only really significant overhead I 
> can see is having to flush an extra set of TLBs, and I guess there are ways 
> round that if it is a problem.

I can check the hypervisor feature is not present, for emulating PowerPC
620 on a target that would have hypervisor emulation support. But I
cannot do as if the CPU do not have the feature if it's actually
available. The PowerPC 64 target emulates PowerPC 64 without the
hypervisor feature, which actually do not exist but looks like a G5
machine when running Linux on it. If the emulator has the hypervisor
feature enabled, I need an hypervisor software to boot and manage the
machine (trap the hypervisor exception, update or emulate the registers
the OS is not allowed to access anymore, ...), which I don't have, then
I would not be able to do any test or run any OS on this emulated target
(you could argue that I  do not have it to test the ppc64h target too,
which is true...). There is nothing in the CPU that would allow me to
make it run "as if the hypervisor mode do not exists". Then I do not
have anything to check. The only possible runtime solution would be to
duplicate every defined 64 bits CPU to define one model supporting
hypervisor feature and another acting as this feature do not exist (the
register definitions / access rights are not the same, and are defined
at CPU instanciation time, adding run-time checks there would cost a
lot...) and hope run-time checks won't cost too much. I don't think this
solution is cleaner than having a separate target, it would bring
confusion for the user imho, and it does not seem easier to test.

> I can see why you want CPUs with and without hypervisor mode, I'm just not 
> convinced it needs a separate qemu binary.

-- 
J. Mayer <address@hidden>
Never organized