>* Emulation of hlt - virtual machine shuts down
HLT doesn't make the CPU shut down... it makes it block, until an interrupt
occurs. Only "cli; hlt" halts forever. I suggest we implement this behavior.
>Other (from last patch):
>>> diff -urN freemware/CVS/Entries freemware-jens/CVS/Entries
>>> --- freemware/CVS/Entries Wed Jan 12 11:46:02 2000
>>> +++ freemware-jens/CVS/Entries Wed Jan 12 15:58:22 2000
>>
>>What a messy patch... what did you do to your CVS dirs ????
>
>Yes, it bothers me too, does anyone know how to eliminate this?
This is what I do: before I start coding, I always get the latest CVS
tree. I then do cp -R freemware freemware-old, and edit the freemware tree.
Then, diff -Nur freemware-old freemware only gives the "real" changes.
>>> - if (!create_proc_info_entry("freemware", 0, NULL, fmw_read_procmem))
>>> + if (!create_proc_info_entry("freemware", 0, NULL, (void
>>>*)fmw_read_procmem))
>>
>>Oops. Is there a argument type mismatch? Don't hide it, fix it ;-)
>Yes, came a compiler warning. Guess it should be a void *, so the compiler
>is friendly ;)
Shouldn't we compile everything with -Wall ?
>>- The memory-dump now ("vm-core") is not very useful.
>> What I'd find interesting is that we'd dump a
>> core-like ELF file with the memory and the processor
>> state (registers),
>I agree. I added this simliest case of a dump because I need it
>in some cases (like today... ;) and it was quick and simple to
>implement. A core-like ELF file is much better. And also the
>ability to instect the guest memory during run time.
You can inspect the guest memory at runtime already, using the ICE
plugin. You can even modify it at runtime.
I'll see what I can do about ELF dumping next weekend.
>Perhaps we should add an ioctl for translating virtual to linear
>and physical addresses for the case we don't have a flat memory
>model or paging in the guest. For plugins to calculate adresses
>given by segment selector and offset.
That would be a good idea.
>+ case EMU_INSTR_INS_8:
>+ plugin_emulate(EVT_INPORT,context.edx & 0xffff,1,1,&value);
As an optimisation, we could support "rep insb" etc. by providing a value
array that has multiple elements.
Another thing: right now, the plugins are responsible for positioning
the return value, in %eax or something. However, I don't think this is a
good idea, really... I think we should add "return" array in the same way
as the "value" array to plugin_emulate, and that main_run_loop() is then
responsible for returning this to the guest. I'll work on this ASAP.
-- Ramon
