WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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