All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@eu.citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>, Tim Deegan <tim@xen.org>
Cc: xen-devel@lists.xenproject.org, keir.xen@gmail.com,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [V8 PATCH 2/8] pvh dom0: construct_dom0 changes
Date: Mon, 7 Apr 2014 10:27:14 +0100	[thread overview]
Message-ID: <53426F72.4080206@eu.citrix.com> (raw)
In-Reply-To: <20140404175337.18aad83c@mantra.us.oracle.com>

On 04/05/2014 01:53 AM, Mukesh Rathor wrote:
> On Thu, 27 Mar 2014 16:30:37 +0100
> Tim Deegan <tim@xen.org> wrote:
>
>> At 15:04 +0000 on 27 Mar (1395929085), Jan Beulich wrote:
>>>>>> On 27.03.14 at 11:55, <george.dunlap@eu.citrix.com> wrote:
>>>> On 03/27/2014 10:14 AM, Jan Beulich wrote:
>>>>>>>> On 26.03.14 at 20:05, <george.dunlap@eu.citrix.com> wrote:
>>>>>> --- a/xen/arch/x86/mm/hap/hap.c
>>>>>> +++ b/xen/arch/x86/mm/hap/hap.c
>>>>>> @@ -589,6 +589,21 @@ int hap_domctl(struct domain *d,
>>>>>> xen_domctl_shadow_op_t
>>>> *sc,
>>>>>>         }
>>>>>>     }
>>>>>>     
>>>>>> +void __init hap_set_pvh_alloc_for_dom0(struct domain *d,
>>>>>> +                                       unsigned long num_pages)
>>>>>> +{
>>>>>> +    int rc;
>>>>>> +    unsigned long memkb = num_pages * (PAGE_SIZE / 1024);
>>>>>> +
>>>>>> +    /* Copied from: libxl_get_required_shadow_memory() */
>>>>>> +    memkb = 4 * (256 * d->max_vcpus + 2 * (memkb / 1024));
>>>>>> +    num_pages = ( (memkb + 1023) / 1024) << (20 - PAGE_SHIFT);
>>>>>> +    paging_lock(d);
>>>>>> +    rc = hap_set_allocation(d, num_pages, NULL);
>>>>>> +    paging_unlock(d);
>>>>>>
>>>>>>
>>>>>> The calculation for how many pages of shadow memory are needed
>>>>>> logically belongs in domain_build.c, not hap.c.
>>>>> Iirc it was me requesting it to be moved here, on the basis that
>>>>> the calculation should match the one for other domains, and
>>>>> hence be done alongside that for other domains. domain_build.c
>>>>> shouldn't carry HAP-specific knowledge imo.
>>>> I thought that might be the case, which is why I apologized in
>>>> advance for not reading the previous thread.
>>>>
>>>> The calculation should indeed match that done for other domains;
>>>> however, as the comment clearly says, this calculation is done in
>>>> libxl, not in Xen at all.  Everything done to build dom0 in Xen
>>>> which corresponds to things done by the toolstack to build a domU
>>>> logically belongs in domain_build.c.
>>>>
>>>> Putting it in hap.c would be wrong in any case; what would you do
>>>> when we enable shadow mode for HAP dom0?
>>> The function calls hap_set_allocation(), so it's already
>>> HAP-specific.
>> It really ought to be calling a paging_set_allocation() wrapper;
>> there's nothing _inherently_ HAP-specific about PVH.  Right now that
>> wrapper doesn't exist, because that path goes via paging_domctl() for
>> other domains.
> Correct, PVH requires HAP at present, and I like when the code makes
> that clear. In general, my approach is to make change in future when
> demanded, thus, when shadow is added, it can be rearranged with small
> effort.
>
> Anyways, I'm flexible. Jan, final word: Leave it as is (my first pref),
> move to domain_build.c, or put a wrapper(my last preference) ?

I'm fine with the code in domain_build.c calling hap_set_allocation() 
directly for the time being, and implementing a paging_set_allocation() 
wrapper later; but I think the code doing the calculation should be in 
domain_build.c.

  -George

  parent reply	other threads:[~2014-04-07  9:27 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-22  1:39 [V8 PATCH 0/8] pvh dom0 Mukesh Rathor
2014-03-22  1:39 ` [V8 PATCH 1/8] pvh dom0: move some pv specific code to static functions Mukesh Rathor
2014-03-22  1:39 ` [V8 PATCH 2/8] pvh dom0: construct_dom0 changes Mukesh Rathor
2014-03-26 19:05   ` George Dunlap
2014-03-27 10:14     ` Jan Beulich
2014-03-27 10:55       ` George Dunlap
2014-03-27 11:03         ` George Dunlap
2014-03-27 15:04         ` Jan Beulich
2014-03-27 15:30           ` Tim Deegan
2014-04-05  0:53             ` Mukesh Rathor
2014-04-07  7:30               ` Jan Beulich
2014-04-07  9:27               ` George Dunlap [this message]
2014-03-22  1:39 ` [V8 PATCH 3/8] pvh dom0: Introduce p2m_map_foreign Mukesh Rathor
2014-03-24  9:00   ` Jan Beulich
2014-03-27 12:29   ` George Dunlap
2014-04-05  0:57     ` Mukesh Rathor
2014-03-22  1:39 ` [V8 PATCH 4/8] pvh dom0: make xsm_map_gmfn_foreign available for x86 Mukesh Rathor
2014-03-25 17:53   ` Daniel De Graaf
2014-03-22  1:39 ` [V8 PATCH 5/8] pvh dom0: Add and remove foreign pages Mukesh Rathor
2014-03-24  9:26   ` Jan Beulich
2014-04-05  1:17     ` Mukesh Rathor
2014-04-07  6:57       ` Jan Beulich
2014-04-08  1:11         ` Mukesh Rathor
2014-04-08  7:36           ` Jan Beulich
2014-04-08 14:01             ` Tim Deegan
2014-04-08 14:07               ` Jan Beulich
2014-04-08 14:18                 ` Tim Deegan
2014-04-08 15:40                   ` George Dunlap
2014-04-11  1:33     ` Mukesh Rathor
2014-04-11  8:02       ` Jan Beulich
2014-03-22  1:39 ` [V8 PATCH 6/8] pvh dom0: allow get_pg_owner for translated domains Mukesh Rathor
2014-03-24  9:31   ` Jan Beulich
2014-04-01 14:31     ` George Dunlap
2014-04-05  0:59       ` Mukesh Rathor
2014-03-22  1:39 ` [V8 PATCH 7/8] pvh dom0: add check for pvh in vioapic_range Mukesh Rathor
2014-03-24  9:34   ` Jan Beulich
2014-04-01 14:40     ` George Dunlap
2014-04-01 15:09       ` Jan Beulich
2014-04-05  1:00         ` Mukesh Rathor
2014-04-07  6:59           ` Jan Beulich
2014-04-07  9:28             ` George Dunlap
2014-04-08  1:00               ` Mukesh Rathor
2014-04-08  8:21                 ` Jan Beulich
2014-03-22  1:39 ` [V8 PATCH 8/8] pvh dom0: add opt_dom0pvh to setup.c Mukesh Rathor
2014-03-24  9:35   ` Jan Beulich
2014-03-24  8:57 ` [V8 PATCH 0/8] pvh dom0 Jan Beulich
2014-03-24 21:36   ` Mukesh Rathor
2014-03-28 17:36 ` Roger Pau Monné
2014-03-28 19:48   ` Mukesh Rathor
2014-04-01 16:04 ` George Dunlap
2014-04-02  1:22   ` Mukesh Rathor

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=53426F72.4080206@eu.citrix.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=keir.xen@gmail.com \
    --cc=mukesh.rathor@oracle.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.