Hello,
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)?
On the plus side, it would mean that our hypervisor entry points would
be at the start of a cache line, rather than half way along it, and we
gain an extra 32 bytes of space on the cpu stacks. On the other hand,
doing it neatly would be rather more difficult, and might just be a lot
of effort for minimal gains.
~Andrew
>>> 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 think that would uglify the code enough to warrant keeping the fields instead. Of course you''re free to prove the contrary. Jan
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