All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v2 2/3] xen/hvm: introduce a fpu_uninitialised field to the CPU save record
Date: Wed, 18 Nov 2015 10:51:10 +0000	[thread overview]
Message-ID: <564C581E.10008@citrix.com> (raw)
In-Reply-To: <564B79AD.6040703@citrix.com>

El 17/11/15 a les 19.02, Andrew Cooper ha escrit:
> On 17/11/15 18:44, Roger Pau Monne wrote:
>> Introduce a new filed to signal if the FPU has been initialised or not. Xen
> 
> field
> 
>> needs this new filed in order to know whether to set the FPU as initialised
>> or not during restore of CPU context. Previously Xen always wrongly assumed
>> the FPU was initialised on restore.
>>
>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>> Cc: Jan Beulich <jbeulich@suse.com>
>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>> ---
>> Changes since v1:
>>  - Don't add yet another compat structure, new fields should always be added
>>    to the end of the existing structure and offsetof should be used to
>>    compare sizes.
>>  - Leave the previous compat structure as-is, since the field was not added
>>    to the end we cannot remove it and use offsetof in this case.
> 
> How can this work?
> 
> Making it zeroextended means that any short record will be padded with
> zeroes.  As a result, the compat checking logic is skipped.
> 
> (This HVM_SAVE_* infrastructure is truly horrifying code which should
> never have been accepted.  I think I have correctly followed what it is
> doing, but I could be mistaken.)

No, you are completely right, it was an oversight on my side. So neither
hvm_load_entry or hvm_load_entry_zeroextend will do what I want/need.
The options I see so far are:

 - Make hvm_hw_cpu_compat hvm_hw_cpu minus the fpu_initalised field
(this means dropping support for Xen pre-3.4).

 - Rewrite part of the hvm_load_entry_zeroextend so that it will load
records with "len < expected len" and still call the fixup function.

TBH the mess with the hvm_hw_cpu_compat structure is very bad. Adding
the msr_tsc_aux in the middle of the structure makes all the compat
handling much more complicated that what it needs to be.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2015-11-18 10:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-17 18:44 [PATCH v2 0/3] Introduce a fpu_initilised filed to HVM CPU context Roger Pau Monne
2015-11-17 18:44 ` [PATCH v2 1/3] xen/save: pass a size paramter to the HVM compat functions Roger Pau Monne
2015-11-17 18:50   ` Andrew Cooper
2015-11-17 18:44 ` [PATCH v2 2/3] xen/hvm: introduce a fpu_uninitialised field to the CPU save record Roger Pau Monne
2015-11-17 19:02   ` Andrew Cooper
2015-11-18 10:51     ` Roger Pau Monné [this message]
2015-11-18 11:00       ` Andrew Cooper
2015-11-18 11:04         ` Jan Beulich
2015-11-18 11:24           ` Andrew Cooper
2015-11-17 18:44 ` [PATCH v2 3/3] Revert "libxc: create an initial FPU state for HVM guests" Roger Pau Monne
2015-11-17 19:03   ` Andrew Cooper
2015-11-18  9:57   ` Wei Liu

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=564C581E.10008@citrix.com \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.com \
    --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.