[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] non-flat protected mode HVM support



>>> "Trolle Selander" <trolle.selander@xxxxxxxxx> 29.11.06 15:45 >>>
>The assumption of zero base/limit still exists in insn_fetch in
>x86_emulate.c. When an EXCEPTION_PF occurs and cs.base is non-zero,
>x86_emulate_memop fails because it does not take cs.base into account when
>reading the instruction to be decoded/emulated from memory. I had an email
>discussion with Mats early last week about this and he made some
>suggestions, but I didn't have a chance to really look at it until
>yesterday, and by then you had done a lot of work on the zero segment
>base/limit assumptions anyway. Looking at it now, I'm not wholly sure what
>would be the best way to pass this info to x86_emulate_memop. Maybe extend
>the struct x86_emulate_ctxt to include cs base (and limits/attibutes)? Or
>would that cause problems elsewhere?

Indeed, I didn't look outside the hvm directories. But it's not just the 
instruction
fetching there, there are other segment based operations in there, too. Hence
I think adding a callback to obtain the base address would be cleaner;
hvm_get_segment_base() could be used in the hvm case, and a simple function
should be put in place for pv guest handling (for those, assuming a zero base
address seems reasonably safe at this point, since the behavior of them is
known, and if ever page table updates get done through segments with non-
zero base addresses this would need to be revisited.

I'll try to take care of this unless you beat me.

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.