All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 3/4] xen/hvm: introduce a fpu_uninitialised field to the CPU save record
Date: Tue, 24 Nov 2015 07:48:36 -0700	[thread overview]
Message-ID: <565486D402000078000B87D6@prv-mh.provo.novell.com> (raw)
In-Reply-To: <56547656.2090902@citrix.com>

>>> On 24.11.15 at 15:38, <roger.pau@citrix.com> wrote:
> El 24/11/15 a les 14.34, Jan Beulich ha escrit:
>>>>> On 24.11.15 at 14:10, <roger.pau@citrix.com> wrote:
>>> El 20/11/15 a les 16.49, Jan Beulich ha escrit:
>>>>>>> On 18.11.15 at 17:37, <roger.pau@citrix.com> wrote:
>>>>> @@ -157,6 +159,8 @@ struct hvm_hw_cpu {
>>>>>      };
>>>>>      /* error code for pending event */
>>>>>      uint32_t error_code;
>>>>> +    /* is fpu initialised? */
>>>>> +    uint32_t fpu_initialised;
>>>>
>>>> A whole uint32_t for just one bit? Didn't we talk about making this
>>>> new field a flags one, consuming just one bit from it?
>>>
>>> AFAIK we agreed on adding this field to the tail and making it a
>>> uint32_t so that when new fields are added they can be detected by
>>> looking at the size of the structure:
>>>
>>> http://marc.info/?l=xen-devel&m=144490321208291 
>> 
>> Admittedly it's a little implicit, but that mail has, in its quoting parts,
>> 
>> "... (and validate unused tail bits are zero, so they can be used for
>> something later on)"
>> 
>> going back to that intention of using just a single bit here afaict.
> 
> Ack. I have to admit I've misunderstood that part. Then I guess the
> field should also have a more generic name, like "flags", and
> fpu_initialised should be defined as (1U << 0).

Yes.

Jan

  reply	other threads:[~2015-11-24 14:48 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-18 16:37 [PATCH v3 0/4] Introduce a fpu_initilised field to HVM CPU context Roger Pau Monne
2015-11-18 16:37 ` [PATCH v3 1/4] xen/save: pass a size parameter to the HVM compat functions Roger Pau Monne
2015-11-20 14:17   ` Andrew Cooper
2015-11-20 15:37   ` Jan Beulich
2015-11-24 12:54     ` Roger Pau Monné
2015-11-24 13:06       ` Jan Beulich
2015-11-24 13:11         ` Roger Pau Monné
2015-11-18 16:37 ` [PATCH v3 2/4] xen/save: allow the usage of zeroextend and a fixup function Roger Pau Monne
2015-11-20 14:32   ` Andrew Cooper
2015-11-20 15:41   ` Jan Beulich
2015-11-18 16:37 ` [PATCH v3 3/4] xen/hvm: introduce a fpu_uninitialised field to the CPU save record Roger Pau Monne
2015-11-20 14:35   ` Andrew Cooper
2015-11-20 15:49   ` Jan Beulich
2015-11-24 13:10     ` Roger Pau Monné
2015-11-24 13:34       ` Jan Beulich
2015-11-24 14:38         ` Roger Pau Monné
2015-11-24 14:48           ` Jan Beulich [this message]
2015-11-18 16:37 ` [PATCH v3 4/4] Revert "libxc: create an initial FPU state for HVM guests" Roger Pau Monne

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=565486D402000078000B87D6@prv-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=roger.pau@citrix.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.