Hi Anthony,

Perhaps you did --emulate-16bit instead of -emulate-16bit? The patch 
definitely has the added option.

You are right, it was -emulate-16bit.

> - I tried hardcoding this to 1 in the qemu code, and found that the 
> port x595 is not reflecting it correctly to hvmloader.
Are you sure you don't have something stale?

I started with a fresh tree for your patch. I also tried rebuilding the quemu from start.

I suspect you have a partial install or something. I have never seen 
this happen.

I have already tried few times. i will try one more time with newer fresh xen-unstable tree. Some of the debug messages were coming from my prinks.

You should see x86_emulate run for a good number of instructions. The 
odd thing about your log is that the transfering control to x86_emulate 
message uses the EIP from the vmcs. If this is the first time the 
emulator is being invoked, how can eip be 0? There's nothing in the 
emulate path that would touch the vmcs.
How exactly are you forcing the use of the emulator instead of vmxassist?

I basically forced emulate_16bit varilable in qemu to 1.

int acpi_enabled = 0;
int fd_bootchk = 1;
int emulate_16bit = 1;

and in the hvmloader instead of checking the output of the port 595, I replaced it with if (1).
like this:
#if 0
if (inl(0x595) == 0xdeadbeef) {
#else
if (1) {
#endif

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel