Take a couple assembly language/computer organization classes for starters,
and then start looking things up & asking questions. Then you can keep up
with the big fish (& then you will be just barely able to keep up--like
me!!).
Drew Northup, N1XIM
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
> Of Nick Behnken
> Sent: Saturday, December 16, 2000 5:58 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [plex86] Performance enhancement: elminiating mode and
> context switches
>
>
> SIMPLE??????????? SOUNDS LIKE GREEK! lol Actually.. thats scary that I
> followed the conversation! lol
> I am assuming MMIO = memory mapped input output?
>
> I don't know about the rest of you but I want to be as smart as Ramon and
> Kevin one day!
>
> Nick
>
> ----- Original Message -----
> From: "Ramon van Handel" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Saturday, December 16, 2000 4:53 AM
> Subject: Re: [plex86] Performance enhancement: elminiating mode
> and context
> switches
>
>
> > On Fri, 15 Dec 2000, Kevin Lawton wrote:
> > > Running guest ring0 code at ring0 open memory access to
> PTE.P==1 pages,
> > > which includes the monitor interrupt handlers, and monitor data
> > > structures. Thus, all memory access instructions would be dangerous.
> > > We'd have to move to the concept of 'shortening' guest kernel
> segments,
> > > so we leave our selves a safe hole to put the monitor in.
> >
> > You need to prescan memory accesses anyway in order to catch
> > MMIO. You don't need to emulate non-MMIO memory acesses, but
> you can keep
> > the monitor in the same place and simply change the address (the size of
> > the memory access instruction will remain the same anyway.)
> >
> > > Once you modify the instructions in a page by extending the size
> > > of an instruction (changing an IO to a call), as opposed to
> > > inserting an INT3 (always 1 byte), we have to move from our notion
> > > of simple modified cache pages to a more dynamic translation like
> > > scheme. The branch offsets change etc.
> >
> > No, not necessarily. What you do is overwrite the next instruction and
> > keep the original in a branch table. You use a call to go to the
> > emulation routine; in stead of using ret, however, the emulation routine
> > will look in the branch table, which contains (1) the next
> instructions to
> > be executed, and (2) the address of the first instruction that was not
> > overwritten.
> >
> > It's simple really, perhaps I should make a little graphic
> description of
> > the process?
> >
> > -- Ramon
> >
> >
> >
>
>
