From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Daniel Kiper <daniel.kiper@oracle.com>
Cc: xen-devel@lists.xenproject.org, keir@xen.org, jbeulich@suse.com
Subject: Re: Relocatable Xen early boot code
Date: Fri, 12 Jun 2015 16:30:06 +0100 [thread overview]
Message-ID: <557AFAFE.4020806@citrix.com> (raw)
In-Reply-To: <20150612143645.GO19315@olila.local.net-space.pl>
On 12/06/15 15:36, Daniel Kiper wrote:
>> As stated at the hackathon, the problem with using %ebp is that it turns
>> all implicit %ds references into implicit %ss references, and tends to
> I am aware of that. However, I think that this is not a problem right
> now because %ds == %ss.
Some data segment attributes have different meanings when loaded into
%ss, than when loaded into any of the plain data segment registers. I
believe what we have is compatible between the two. but...
> Additionally, I do not think that it will change in the future.
Stack references behave differently to data references. For example, a
non-canonical addresses generate a #GP fault for data references, or a
#SS fault for stack references.
The concern with implicit stack references comes from the subtle
behaviour changes, not because it won't work in the general case.
>
>> add a SIB+imm32 to each instruction with a memory reference (ebp
>> relative memory references, and r13 for that matter, have restrictions
>> in the way in which they can be encoded).
> I am not sure what are you talking about here. What do you mean by r13?
> Register name? In 32-bit mode? Could you point me a paragraph in Intel
> or AMD docs which says about this restrictions?
This isn't a restriction pe say. It is a properly of ModRM/SIB
encoding. It is described in both the Intel and AMD instruction
reference manuals.
~Andrew
prev parent reply other threads:[~2015-06-12 15:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-12 11:14 Relocatable Xen early boot code Daniel Kiper
2015-06-12 12:08 ` Jan Beulich
2015-06-12 13:51 ` Daniel Kiper
2015-06-12 13:57 ` Jan Beulich
2015-06-12 14:43 ` Daniel Kiper
2015-06-12 13:19 ` Andrew Cooper
2015-06-12 14:36 ` Daniel Kiper
2015-06-12 15:30 ` Andrew Cooper [this message]
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=557AFAFE.4020806@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=daniel.kiper@oracle.com \
--cc=jbeulich@suse.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xenproject.org \
/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.