xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: "Tim (Xen.org)" <tim@xen.org>, "Keir (Xen.org)" <keir@xen.org>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: Segment registers at top of stack
Date: Thu, 3 Jan 2013 17:14:54 +0000	[thread overview]
Message-ID: <50E5BC8E.9090702@citrix.com> (raw)
In-Reply-To: <50E5C11502000078000B2CF2@nat28.tlf.novell.com>

On 03/01/13 16:34, Jan Beulich wrote:
>>>> On 03.01.13 at 17:00, Andrew Cooper<andrew.cooper3@citrix.com>  wrote:
>> While debugging an issue of 0xdeadbeef's appearing in a crash report, I
>> have discovered that the es thru gs entries in cpu_user_regs appear to
>> be completely unused on a 64bit hypervisor per-cpu stack.
>>
>> In 64bit mode, all segment register changes happen in
>> {load,save}segments().  The only code I can find which ever sets these
>> values is the NDEBUG poisoning on the VMX/SVM vmexit hypervisor entry paths.
>>
>> If the values are indeed completely unused, would it be sensible to
>> remove them from the per-cpu stacks as we have now dropped support for
>> the 32bit hypervisor (which certainly does use them)?
> Doing that would imply breaking the association of there being
> a struct cpu_user_regs close to the end of the stack - I'm sure
> you realize that you can't drop these fields from that structure.

I do realize that, hence the problem of doing this in a neat fashion.

> I think that would uglify the code enough to warrant keeping
> the fields instead. Of course you're free to prove the contrary.
>
> Jan
>

Ok - I was just wondering how much we cared about half a cache line.  
(The neatest way I can think of doing this would be to create a shadow 
structure and tweak the macros in current.h to always typecast it.  
Which is quite ugly under the surface, and problematic if some unknowing 
programmer does try and use the segment register values.)

~Andrew

      reply	other threads:[~2013-01-03 17:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-03 16:00 Segment registers at top of stack Andrew Cooper
2013-01-03 16:34 ` Jan Beulich
2013-01-03 17:14   ` 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=50E5BC8E.9090702@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=keir@xen.org \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).