WARNING - OLD ARCHIVES

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

xen-devel

RE: [Xen-devel] Fetching instructions after page-fault, near page bounda

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] Fetching instructions after page-fault, near page boundary?
From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Fri, 2 Jun 2006 21:04:00 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 02 Jun 2006 12:04:52 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <e3efccb021ee6ec7360e13b4204bbc56@xxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcaGdZwj1upU5MgsS5+vZgft5Mz/gQAAFoRQ
Thread-topic: [Xen-devel] Fetching instructions after page-fault, near page boundary?
> -----Original Message-----
> From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] 
> Sent: 02 June 2006 19:51
> To: Petersson, Mats
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] Fetching instructions after 
> page-fault, near page boundary?
> 
> 
> On 2 Jun 2006, at 18:20, Petersson, Mats wrote:
> 
> >> Just try re-executing the instruction (i.e. directly return to the 
> >> guest). If the page has become unmapped then the processor should 
> >> handle the fault on instruction fetch.
> >
> > Ok, that approach makes more sense than my silly ideas of counting 
> > instruction bytes... And hopefully the code that removed 
> our very much 
> > needed page will eventually let us actually emulate the 
> instruction at 
> > some point, without too many re-executions... ;-)
> 
> Bear in mind that we need to be able to inject page faults 
> into the guest from the emulator anyway, for other reasons. 
> For example, consider INSB/OUTSB -- the memory area being 
> transferred to/from may be paged out. Current HVM MMIO code 
> is rather lax about dealing with this (i.e., it doesn't -- it 
> ignores error returns from gva_to_gpa(), which itself has a 
> bogus error value anyway (0 is a valid pa)). Given we need 
> the code, we may just want to inject faults for 
> instruction-fetch errors too, but we do have a choice for those.

I was initially going to ignore IN/OUT instructions, because:
1. They are fairly "OK" to handle in SVM/VMX, because there's very
little parsing that needs to be done, because most of the info is in
VMC[BS] already - relative to Page-fault MMIO handling at least... I
think it's only the target memory address that isn't being handled by
the chip itself. [In fact, we even get the next EIP given to us in the
VMCB on this one, so no need to figure out how long the instruction is,
and we only need to scan for prefix if we see an unusual length
instruction]. 

2. They are not currently supported by x86_emulate.c anyways - so
there's no apparent duplicated code - except that SVM and VMX code being
near-identical copies of each other - or at least they were before I
re-arranged ours... ;-)

It is of course broken wrt page-faults on the destination address. Most
drivers however that do INS/OUTS would be doing so in response to an
interrupt, and if it's done IN the interrupt handler, then it's going to
be to a non-pagable memory region. But it could of course be deferred to
a lower priority level and thus be to a pageable memory region... Which
would make for "interesting" crashes on a SMP system where that page is
replaced by something completely different... <Kaboom> - can see bits
flying every direction... 

--
Mats
> 
>   -- Keir
> 
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel