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/
Home Products Support Community News


Re: [Xen-devel] [PATCH] Calculate correct instruction length for data-fa

To: Khoa Huynh <khoa@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Calculate correct instruction length for data-fault VM exits on VT-x systems
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Sat, 29 Apr 2006 08:21:31 +0100
Cc: "Petersson, Mats" <Mats.Petersson@xxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sat, 29 Apr 2006 00:26:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <OFB90097DE.AAC38DDB-ON8525715E.005F664F-8625715E.0063DA01@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <OFB90097DE.AAC38DDB-ON8525715E.005F664F-8625715E.0063DA01@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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.

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.

 -- Keir

Xen-devel mailing list