[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] Calculate correct instruction length for data-fault VM exits on VT-x systems
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |