Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote on 04/28/2006 01:03:02 AM:
>
> On 28 Apr 2006, at 02:52, Khoa Huynh wrote:
>
> > It should be noted that VMX only uses this instrlen
> > function when the hypervisor needs the instruction-length
> > info and that info is undefined in VMCS, e.g., for MMIO
> > instructions. In other cases where the instruction-length
> > field is valid in VMCS, the hypervisor continues to get
> > that info from VMCS (via vmread operation).
>
> I don't believe we need the instruction-length at all, and I suspect
> that the decoder could be removed from hvm/svm entirely. There are two
> broad categories of instruction I'm thinking of:
> 1. Instructions with their own VMEXIT reason code tend to be really
> simple so we know their length anyway and, if not, the instr-length
> field should be valid
For these instructions, on Intel VT-x, the instruction length is valid
in VMCS. On AMD, there is a simple look-up function which determines
the length of the instruction which is passed in as a parameter.
We are good here.
> 2. For mmio instructions, the emulator can work out the length for
> itself and increment eip appropriately. There's no need to know the
> instruction length in advance of invoking the emulator.
Yeah, MMIO instructions are problematic and I was trying to address
this area by using the stripped-down emulator for SVM, but you are
suggesting that we get rid of that stripped-down emulator in SVM,
get rid of the MMIO decoder/emulator in HVM directory (platform.c),
and use the generic x86 emulator in xen/arch/x86 for MMIO instructions
instead. This would certainly be much cleaner than having different
versions of decoder/emulator lying around in different places. I wonder
if there would be any noticeable impact on path lengths for MMIO
instructions ?
> > On 28 Apr 2006, at 10:02, Petersson, Mats wrote:
> >
> > > I'll look at your previous suggestion of merging the MMIO emulation
> > > into x86_emulate later on today. We probably do need to sum up the
> > > length and pass it back to the caller - as that code
> > > doesn't know how
> > > to update the correct field of the different processor
> > > architectures
> > > (vmcb vs. vmcs vs. stack-frame for Para-virtual machine). But it
> > > shouldn't be particularly hard to achieve this.
> >
> > The emulator uses and updates the eip field of the passed-in
> > regs structure. We may want to change this interface in
> > future by having the caller explicitly pass in a buffer
> > containing the instruction, and the number of valid bytes in
> > the buffer. Or add a 'fetch_insn_byte'
> > callback hook to the emulator interface.
>
> I think passing a buffer is the best choice here. And I suppose we can
> always stuff vmc[bs]->rip into regs->eip and pull it back out again when
> we get back - using a wrapper function may be the easiest way to achieve
> this (at least short term).
I guess we can have a wrapper that takes as input the guest instruction
pointer (rip), fetches the whole MAX_INST_LEN (15-byte) buffer starting
at rip (make sure that we don't cross a page boundary), and then passes
that to the emulator. The emulator would decode, emulate, and would
include in its return the updated guest instruction pointer (rip) and
instruction length. This info will be stuffed back into vmcs/vmcb/stack
as appropriate. Is this more or less what you have in mind ?
Thanks.
Regards,
Khoa
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home