All of lore.kernel.org
 help / color / mirror / Atom feed
From: Malcolm Crossley <malcolm.crossley@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: "Tim (Xen.org)" <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH] [RFC] xen: Fix memory hotplug end limit test for updating compat M2P table
Date: Tue, 24 Apr 2012 17:02:02 +0100	[thread overview]
Message-ID: <4F96CE7A.2030906@citrix.com> (raw)
In-Reply-To: <4F967099020000780007F81F@nat28.tlf.novell.com>

On 24/04/12 08:21, Jan Beulich wrote:
>>>> On 23.04.12 at 20:07, Malcolm Crossley<malcolm.crossley@citrix.com>  wrote:
>> The memory hotplug code was masking the hotplugged memory start address and
>> comparing to a shifted version of COMPAT MPT size but not doing the same for
>> the end address.
>> This patch applies the same shifting and masking to the end address and
>> reapplies the mask if the end address has been clamped.
> This lacks a Signed-off-by tag in any case.
>
> I'm not, however, seeing what is being fixed here:
> RDWR_COMPAT_MPT_VIRT_{START,END} are both aligned to a
> 1Gb boundary, so I'm not immediately seeing how the adjustment
> would result in any changed behavior.
>
> Also, assuming I'm overlooking something and the patch is indeed
> needed (and hence you'll resubmit), please fix the indentation to
> not use hard tabs, and adjust the lines you change anyway to
> match Xen's coding style.
>
> Jan
I didn't include a signed off by because it's an RFC patch and I wasn't completely sure the change was required.
I kept the code style of the existing code around the patch but I will update it to Xen coding style in the future
and it was my mistake for using hard tabs and my editor has been reconfigured so it won't happen in the future.

The key fix is the patch is that epfn is being compared to (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START)
without a 2 bit shift.

This means that epfn is being compared to the size of the RDWR_COMPAT_MPT table instead of the maximum number of
entries the RDWR_COMPAT_MPT table can contain. This could result in the end regions of hotplugged memory being
inaccessible when using the RDWR_COMPAT_MPT table.

I also moved the epfn masking to occur before the comparison to RDWR_COMPAT_MPT to be consistent with the
spfn comparison code.

I can split the patch for to make the changes clearer if you want?

Malcolm

>> diff -r 274e5accd62d -r 8470671d407f xen/arch/x86/x86_64/mm.c
>> --- a/xen/arch/x86/x86_64/mm.c
>> +++ b/xen/arch/x86/x86_64/mm.c
>> @@ -446,6 +446,8 @@ static int setup_compat_m2p_table(struct
>>       int err = 0;
>>
>>       smap = info->spfn&  (~((1UL<<  (L2_PAGETABLE_SHIFT - 2)) -1));
>> +    emap = ( (epfn + ((1UL<<  (L2_PAGETABLE_SHIFT - 2)) - 1 ))&
>> +                ~((1UL<<  (L2_PAGETABLE_SHIFT - 2)) - 1) );
>>
>>       /*
>>        * Notice: For hot-added memory, only range below m2p_compat_vstart
>> @@ -454,11 +456,11 @@ static int setup_compat_m2p_table(struct
>>       if   ((smap>  ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START)>>
>> 2)) )
>>           return 0;
>>
>> -    if (epfn>  (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START))
>> -        epfn = (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START)>>  2;
>> -
>> -    emap = ( (epfn + ((1UL<<  (L2_PAGETABLE_SHIFT - 2)) - 1 ))&
>> -                ~((1UL<<  (L2_PAGETABLE_SHIFT - 2)) - 1) );
>> +    if (emap>  ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START)>>  2))
>> +    {
>> +        emap = (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START)>>  2;
>> +    	emap = emap&  ~((1UL<<  (L2_PAGETABLE_SHIFT - 2)) - 1);
>> +    }
>>
>>       va = HIRO_COMPAT_MPT_VIRT_START +
>>            smap * sizeof(*compat_machine_to_phys_mapping);
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>

  reply	other threads:[~2012-04-24 16:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-23 18:07 [PATCH] [RFC] xen: Fix memory hotplug end limit test for updating compat M2P table Malcolm Crossley
2012-04-24  7:21 ` Jan Beulich
2012-04-24 16:02   ` Malcolm Crossley [this message]
2012-04-24 16:11     ` Jan Beulich

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=4F96CE7A.2030906@citrix.com \
    --to=malcolm.crossley@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.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.