> -----Original Message-----
> From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
> Sent: 29 April 2006 08:22
> To: Khoa Huynh
> Cc: Petersson, Mats; xen-devel
> Subject: Re: [Xen-devel] [PATCH] Calculate correct
> instruction length for data-fault VM exits on VT-x systems
>
>
> On 28 Apr 2006, at 19:10, Khoa Huynh wrote:
>
> > 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.
>
> The Intel code only uses the instr-len field because it
> happens to be handy. Going to a look-up function in a
> separate file when you *know* at compile time what the
> instruction length must be is stupid, imo. We should only
> have to do that if the instruction needs some decoding for us
> to know its length (perhaps because of prefix bytes or
> effective address suffixes) and we are not otherwise going to
> be decoding the instruction as part of emulation.
We do have to forward the RIP to next instruction, and we don't know the
prefix and other things, so I don't think we can improve on the current
setup [although I noticed some time ago that you replaced the call to
calculate instrlen on HLT with a constant one, which I suppose is fine,
since IF there is a prefix (unlikely) to HLT, then we just re-execute it
without prefix, which doesn't make a whole lot of difference [Except we
MAY end up waiting for another interrupt, technically speaking, which
would probably not be a good thing - of course, I've never seen any code
with a prefix to HLT - but it's perfectly allowed to do redundant and
useless prefixes on any instruction, for example to change the alignment
of the next instruction].
>
> > 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 ?
>
> Yes, exactly. It gets a bit trickier though -- we'll have to
> fill the buffer with up to 15 bytes. If we fail to get all of
> 15 bytes (perhaps because the instruction straddles a page
> boundary and the second page has been evicted since the
> instruction faulted) then we ought to tell the emulator how
> many bytes we actually copied and it shoudl return error if
> it ends up going off the end of teh instruction buffer.
> Alternatively we could re-enter the guest immediately if we
> cannot read
> 15 bytes from the EIP -- but that'll cause an infinite loop
> if the instruction itself doesn't straddle the page boundary
> as it won't trigger paging in the guest. But I/O instructions
> are unlikely to be in paged memory.
Yes - at the moment, we do not cope well with instructions that straddle
a page-boundary if the next page isn't present in memory.
On the other hand, I've been looking at just using the existing hooks
(in the ops structure) to read instruction bytes and I think that would
work just fine.
However, I haven't been looking through this entire thread to see what
the conclusion is, so this may all be moot...
--
Mats
>
> -- Keir
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home