All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Cc: Keir Fraser <keir@xen.org>
Subject: Re: [PATCH 1/3] x86: drop is_pv_32on64_vcpu()
Date: Wed, 24 Jun 2015 21:08:59 -0400	[thread overview]
Message-ID: <558B54AB.1010804@oracle.com> (raw)
In-Reply-To: <558B4211.80207@citrix.com>

On 06/24/2015 07:49 PM, Andrew Cooper wrote:
> On 24/06/2015 22:35, Boris Ostrovsky wrote:
>> On 06/23/2015 11:18 AM, Jan Beulich wrote:
>>> ... as being identical to is_pv_32bit_vcpu() after the x86-32 removal.
>>>
>>> In a few cases this includes an additional is_pv_32bit_vcpu() ->
>>> is_pv_32bit_domain() conversion.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> We have
>> struct arch_domain
>> {
>>      ...
>>      /* Is a 32-bit PV (non-HVM) guest? */
>>      bool_t is_32bit_pv;
>>      /* Is shared-info page in 32-bit format? */
>>      bool_t has_32bit_shinfo;
>>     ...
>> }
>>
>> and currently both of these fields are set/unset together (except for
>> one HVM case --- hvm_latch_shinfo_size()). Why not have a single 'bool
>> is_32bit' and then replace macros at the top of
>> include/asm-x86/domain.h with is_32bit_vcpu/domain()?
>>
>> I think in majority of places when we test for
>> is_pv_32bit_vcpu/domain() we already know that we are PV so it
>> shouldn't add any additional tests.
> For the PV case, the two are equivalent.  For HVM, they are not.
>
> HVM domains have shared info, but may be latched as either 32 or 64bit,
> depending on the mode they were running in when they most recently wrote
> a hypercall page.  Sadly, the shared info layout is width-dependent
> which is why such hacks need to exist.

Why can't we latch the mode into is_32bit field? I am essentially 
suggesting to drop is_32bit_pv and rename has_32bit_shinfo to is_32bit. 
Then is_pv_32bit_vcpu() becomes '(is_pv_vcpu() && domain->is_32bit)' (or 
simply domain->is_32bit, depending on context) and has_32bit_shinfo()  
becomes domain->is_32bit.

The reason I am asking is because for the 32b PVH I will need to switch 
a few places from using is_pv_32bit_vcpu() to has_32bit_shinfo() and 
that would look strange: asking whether the guest is 32-bit looks more 
natural than asking whether its shared info is 32-bit. At least it's 
more natural to my eye.

-boris

  reply	other threads:[~2015-06-25  1:09 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-23 15:14 [PATCH 0/3] x86: further is_..._...() adjustments Jan Beulich
2015-06-23 15:18 ` [PATCH 1/3] x86: drop is_pv_32on64_vcpu() Jan Beulich
2015-06-23 15:39   ` Andrew Cooper
2015-06-24 21:35   ` Boris Ostrovsky
2015-06-24 23:49     ` Andrew Cooper
2015-06-25  1:08       ` Boris Ostrovsky [this message]
2015-06-25  7:55         ` Jan Beulich
2015-06-23 15:19 ` [PATCH 2/3] x86: drop is_pv_32on64_domain() Jan Beulich
2015-06-23 15:43   ` Andrew Cooper
2015-06-23 16:25   ` George Dunlap
2015-07-06 16:01   ` Ian Campbell
2015-06-23 15:20 ` [PATCH 3/3] x86/mm: use is_..._vcpu() instead of open coding it Jan Beulich
2015-06-23 15:45   ` Andrew Cooper
2015-06-23 16:13   ` George Dunlap

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=558B54AB.1010804@oracle.com \
    --to=boris.ostrovsky@oracle.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=keir@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.