[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • 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

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... 

>   -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.