From: Anthony Liguori <aliguori@us.ibm.com>
To: "Petersson, Mats" <Mats.Petersson@amd.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: Fetching instructions after page-fault, near page boundary?
Date: Fri, 02 Jun 2006 15:16:00 -0500 [thread overview]
Message-ID: <44809C80.2080105@us.ibm.com> (raw)
In-Reply-To: <907625E08839C4409CE5768403633E0BA7FCDC@sefsexmb1.amd.com>
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 <page boundary to page xxxx2000> 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 <page boundary to xxxx2000> [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
>
next prev parent reply other threads:[~2006-06-02 20:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-02 16:34 Fetching instructions after page-fault, near page boundary? Petersson, Mats
2006-06-02 16:40 ` Keir Fraser
2006-06-02 17:07 ` Petersson, Mats
2006-06-02 17:12 ` Keir Fraser
2006-06-02 17:20 ` Petersson, Mats
2006-06-02 18:50 ` Keir Fraser
2006-06-02 19:04 ` Petersson, Mats
2006-06-03 8:53 ` Keir Fraser
2006-06-02 21:39 ` Usage of "container_of" in QEMU Petersson, Mats
2006-06-03 8:50 ` Keir Fraser
2006-06-02 20:16 ` Anthony Liguori [this message]
2006-06-02 20:29 ` Fetching instructions after page-fault, near page boundary? Petersson, Mats
2006-06-02 20:35 ` Anthony Liguori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44809C80.2080105@us.ibm.com \
--to=aliguori@us.ibm.com \
--cc=Mats.Petersson@amd.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.