From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: Fetching instructions after page-fault, near page boundary? Date: Fri, 02 Jun 2006 15:16:00 -0500 Message-ID: <44809C80.2080105@us.ibm.com> References: <907625E08839C4409CE5768403633E0BA7FCDC@sefsexmb1.amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <907625E08839C4409CE5768403633E0BA7FCDC@sefsexmb1.amd.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Petersson, Mats" Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org I would think you would not only have to worry about crossing page boundaries, but also crossing a segment descriptor limit. These days, segmentation is used for some security purposes (to emulate a NX bit for instance). Regards, Anthony Liguori Petersson, Mats wrote: > If we get a page-fault due to a MMIO access to a virtual MMIO device > (such as VGA screen in HVM), we shouldn't need to worry about crossing > the page-boundary at the end of the instruction, right? Let's say the > instruction is a 7-byte instruction like this: > > xxxx1FFD: 11 22 33 44 55 66 77 > > If the page xxxx2000 isn't present when the instruction is started, then > we'd FIRST get a page-fault for this address, so either we fail the > instruction (if xxxx2000 page isn't actually possible to be fixed up), > or we get the page fixed up and therefore the second time, when we get > to the page-fault handler looking at the address the instruction is > accessing [doing the MMIO part], the second page is present [assuming we > haven't got any sneaky code going round modifying the page-tables for > this guest domain - which I don't think is a VALID thing to expect, is > it?] > > Next case is where we have a short instruction before an empty(unused > page), say a three-byte instruction (RR is another instructon, such as a > return instruction). > > xxx1FFC: 11 22 33 RR [not readable since > it's not present]. > > > My design idea for the merged x86_emulate.c in QEMU is to read > instruction bytes blind (i.e. not knowing the actual instruction length) > by the this method: > Try to read 15 bytes (MAX_INST_LEN), and if the instruction bytes happen > to cross a page-boundary, and the second page is not readable, I'll just > cut the number of bytes short, assuming that the valid instruction is > shorter than 15 bytes. > > Does anyone see a problem with this method? > > [By the way, this makes an improvement over the current setup, which > fails if we try to read a page that isn't readable - which at least the > SVM model does try sometimes]. > > -- > Mats > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >