From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel@lists.xenproject.org,
Ian Jackson <ian.jackson@eu.citrix.com>,
Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>
Subject: Re: [PATCH RFC 1/3] xen/save: pass a size paramter to the HVM compat functions
Date: Thu, 15 Oct 2015 11:49:32 +0200 [thread overview]
Message-ID: <561F76AC.9090905@citrix.com> (raw)
In-Reply-To: <561F7BF702000078000AB3D4@prv-mh.provo.novell.com>
El 15/10/15 a les 10.12, Jan Beulich ha escrit:
>>>> On 14.10.15 at 18:24, <roger.pau@citrix.com> wrote:
>> In order to cope with types having multiple compat versions pass a parameter
>> to the fixup function so we can identify which compat version Xen is dealing
>> with.
>
> Having peeked at patch 2, this won't help once another bit gets added
> to the tail of that structure. Also it doesn't seem logical that the
> previous compat handling got around without being passed the size
> explicitly. I.e. while perhaps more involved, I think the compat
> handling needs to be extended to allow for multiple versions.
Yes, patch #2 needs to be fixed by making fpu_initialised an uint32_t.
Adding versions would be the best option IMHO, but I don't think I have
enough time to do that myself right now.
> Or, since we have this under control going forward, don't even declare
> all the various compat structures in the public header (and only ever
> add to the tail). Then staying with the passing of size probably makes
> sense, but the fixup function then should use offsetof() instead of
> sizeof() (and validate unused tail bits are zero, so they can be used for
> something later on).
Since we use hvm_load_entry_zeroextend I think we can assert that all
new tail bits are going to be 0, but I'm not sure I follow you regarding
the usage of offsetof instead of sizeof. What are we going to compare
with offsetof?
Also, we already have a compat version of hvm_hw_cpu that didn't add the
new field to the end.
Roger.
next prev parent reply other threads:[~2015-10-15 9:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-14 16:24 [PATCH RFC 0/3] Introduce a fpu_initilised filed to HVM CPU context Roger Pau Monne
2015-10-14 16:24 ` [PATCH RFC 1/3] xen/save: pass a size paramter to the HVM compat functions Roger Pau Monne
2015-10-15 8:12 ` Jan Beulich
2015-10-15 9:49 ` Roger Pau Monné [this message]
2015-10-15 9:59 ` Jan Beulich
2015-10-15 10:31 ` Andrew Cooper
2015-10-14 16:24 ` [PATCH RFC 2/3] xen/hvm: introduce a fpu_initialised filed to the CPU save record Roger Pau Monne
2015-10-14 16:51 ` Andrew Cooper
2015-10-15 8:13 ` Jan Beulich
2015-10-15 9:53 ` Roger Pau Monné
2015-10-14 16:24 ` [PATCH RFC 3/3] Revert "libxc: create an initial FPU state for HVM guests" Roger Pau Monne
2015-10-14 16:30 ` Wei Liu
2015-11-16 12:51 ` Ian Campbell
2015-11-17 12:16 ` Roger Pau Monné
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=561F76AC.9090905@citrix.com \
--to=roger.pau@citrix.com \
--cc=JBeulich@suse.com \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=tim@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.