[v3,2/6] x86 / p2m: remove page_list check in p2m_alloc_table

Commit Message

[e-mail] March 5, 2020, 12:45 p.m. UTC

From: Paul Durrant <[e-mail]>

There does not seem to be any justification for refusing to create the
domain's p2m table simply because it may have assigned pages. Particularly
it prevents the prior allocation of PGC_extra pages.

Signed-off-by: Paul Durrant <[e-mail]>
---
Cc: Jan Beulich <[e-mail]>
Cc: Andrew Cooper <[e-mail]>
Cc: George Dunlap <[e-mail]>
Cc: Wei Liu <[e-mail]>
Cc: "Roger Pau Monné" <[e-mail]>

v2:
 - New in v2
---
 xen/arch/x86/mm/p2m.c | 8 --------
 1 file changed, 8 deletions(-)

Comments

Jan Beulich March 6, 2020, 11:45 a.m. UTC | #1

On 05.03.2020 13:45, [e-mail] wrote:
> From: Paul Durrant <[e-mail]>
> 
> There does not seem to be any justification for refusing to create the
> domain's p2m table simply because it may have assigned pages.

I think there is: If any such allocation had happened before, how
would it be represented in the domain's p2m?

> Particularly
> it prevents the prior allocation of PGC_extra pages.

That's unfortunate, but will need taking care of differently then:

> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -695,14 +695,6 @@ int p2m_alloc_table(struct p2m_domain *p2m)
>  
>      p2m_lock(p2m);
>  
> -    if ( p2m_is_hostp2m(p2m)
> -         && !page_list_empty(&d->page_list) )
> -    {
> -        P2M_ERROR("dom %d already has memory allocated\n", d->domain_id);
> -        p2m_unlock(p2m);
> -        return -EINVAL;
> -    }

Instead of checking the list to be empty, how about checking
domain_tot_pages() to return zero?

Jan

Durrant, Paul March 6, 2020, 12:07 p.m. UTC | #2

> -----Original Message-----
> From: Jan Beulich <[e-mail]>
> Sent: 06 March 2020 11:46
> To: [e-mail]
> Cc: [e-mail]; Durrant, Paul <[e-mail]>; Andrew Cooper
> <[e-mail]>; George Dunlap <[e-mail]>; Wei Liu <[e-mail]>; Roger Pau
> Monné <[e-mail]>
> Subject: Re: [PATCH v3 2/6] x86 / p2m: remove page_list check in p2m_alloc_table
> 
> On 05.03.2020 13:45, [e-mail] wrote:
> > From: Paul Durrant <[e-mail]>
> >
> > There does not seem to be any justification for refusing to create the
> > domain's p2m table simply because it may have assigned pages.
> 
> I think there is: If any such allocation had happened before, how
> would it be represented in the domain's p2m?

Insertion into the p2m is a separate action from page allocation. Why should they be linked?

> 
> > Particularly
> > it prevents the prior allocation of PGC_extra pages.
> 
> That's unfortunate, but will need taking care of differently then:
> 
> > --- a/xen/arch/x86/mm/p2m.c
> > +++ b/xen/arch/x86/mm/p2m.c
> > @@ -695,14 +695,6 @@ int p2m_alloc_table(struct p2m_domain *p2m)
> >
> >      p2m_lock(p2m);
> >
> > -    if ( p2m_is_hostp2m(p2m)
> > -         && !page_list_empty(&d->page_list) )
> > -    {
> > -        P2M_ERROR("dom %d already has memory allocated\n", d->domain_id);
> > -        p2m_unlock(p2m);
> > -        return -EINVAL;
> > -    }
> 
> Instead of checking the list to be empty, how about checking
> domain_tot_pages() to return zero?

I could do that, and in fact my original code did, but with more consideration the whole test just didn't make sense to me. Yes, clearly the p2m has to be there before pages can be added into it, but I can't see any reason why you couldn't even allocate the entire guest RAM, then create the p2m and then add the pages into it.

  Paul

> 
> Jan

Jan Beulich March 6, 2020, 12:46 p.m. UTC | #3

On 06.03.2020 13:07, Durrant, Paul wrote:
>> -----Original Message-----
>> From: Jan Beulich <[e-mail]>
>> Sent: 06 March 2020 11:46
>> To: [e-mail]
>> Cc: [e-mail]; Durrant, Paul <[e-mail]>; Andrew Cooper
>> <[e-mail]>; George Dunlap <[e-mail]>; Wei Liu <[e-mail]>; Roger Pau
>> Monné <[e-mail]>
>> Subject: Re: [PATCH v3 2/6] x86 / p2m: remove page_list check in p2m_alloc_table
>>
>> On 05.03.2020 13:45, [e-mail] wrote:
>>> From: Paul Durrant <[e-mail]>
>>>
>>> There does not seem to be any justification for refusing to create the
>>> domain's p2m table simply because it may have assigned pages.
>>
>> I think there is: If any such allocation had happened before, how
>> would it be represented in the domain's p2m?
> 
> Insertion into the p2m is a separate action from page allocation. Why should they be linked?

They are, because of how XENMEM_populate_physmap works. Yes,
they _could_ be separate steps, but that's only a theoretical
consideration.

>>> Particularly
>>> it prevents the prior allocation of PGC_extra pages.
>>
>> That's unfortunate, but will need taking care of differently then:
>>
>>> --- a/xen/arch/x86/mm/p2m.c
>>> +++ b/xen/arch/x86/mm/p2m.c
>>> @@ -695,14 +695,6 @@ int p2m_alloc_table(struct p2m_domain *p2m)
>>>
>>>      p2m_lock(p2m);
>>>
>>> -    if ( p2m_is_hostp2m(p2m)
>>> -         && !page_list_empty(&d->page_list) )
>>> -    {
>>> -        P2M_ERROR("dom %d already has memory allocated\n", d->domain_id);
>>> -        p2m_unlock(p2m);
>>> -        return -EINVAL;
>>> -    }
>>
>> Instead of checking the list to be empty, how about checking
>> domain_tot_pages() to return zero?
> 
> I could do that, and in fact my original code did, but with more
> consideration the whole test just didn't make sense to me. Yes,
> clearly the p2m has to be there before pages can be added into it,
> but I can't see any reason why you couldn't even allocate the
> entire guest RAM, then create the p2m and then add the pages into
> it.

Right - more hypercalls (XENMEM_increase_reservation + operations
like XENMAPSPACE_gmfn), and hence slower overall domain creation.
Plus - XENMEM_increase_reservation is not very useful for
translated domains, as it won't return the MFNs allocated, and
there's no way to specify where they should appear in GFN space.
Hence in practice I don't see how this whole operation could
work without XENMEM_populate_physmap.

Jan

Durrant, Paul March 6, 2020, 12:50 p.m. UTC | #4

> -----Original Message-----
> From: Jan Beulich <[e-mail]>
> Sent: 06 March 2020 12:47
> To: Durrant, Paul <[e-mail]>
> Cc: [e-mail]; [e-mail]; Andrew Cooper <[e-mail]>;
> George Dunlap <[e-mail]>; Wei Liu <[e-mail]>; Roger Pau Monné <[e-mail]>
> Subject: Re: [PATCH v3 2/6] x86 / p2m: remove page_list check in p2m_alloc_table
> 
> On 06.03.2020 13:07, Durrant, Paul wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <[e-mail]>
> >> Sent: 06 March 2020 11:46
> >> To: [e-mail]
> >> Cc: [e-mail]; Durrant, Paul <[e-mail]>; Andrew Cooper
> >> <[e-mail]>; George Dunlap <[e-mail]>; Wei Liu <[e-mail]>; Roger
> Pau
> >> Monné <[e-mail]>
> >> Subject: Re: [PATCH v3 2/6] x86 / p2m: remove page_list check in p2m_alloc_table
> >>
> >> On 05.03.2020 13:45, [e-mail] wrote:
> >>> From: Paul Durrant <[e-mail]>
> >>>
> >>> There does not seem to be any justification for refusing to create the
> >>> domain's p2m table simply because it may have assigned pages.
> >>
> >> I think there is: If any such allocation had happened before, how
> >> would it be represented in the domain's p2m?
> >
> > Insertion into the p2m is a separate action from page allocation. Why should they be linked?
> 
> They are, because of how XENMEM_populate_physmap works. Yes,
> they _could_ be separate steps, but that's only a theoretical
> consideration.

Then surely the check should be in the XENMEM_populate_physmap code?

> 
> >>> Particularly
> >>> it prevents the prior allocation of PGC_extra pages.
> >>
> >> That's unfortunate, but will need taking care of differently then:
> >>
> >>> --- a/xen/arch/x86/mm/p2m.c
> >>> +++ b/xen/arch/x86/mm/p2m.c
> >>> @@ -695,14 +695,6 @@ int p2m_alloc_table(struct p2m_domain *p2m)
> >>>
> >>>      p2m_lock(p2m);
> >>>
> >>> -    if ( p2m_is_hostp2m(p2m)
> >>> -         && !page_list_empty(&d->page_list) )
> >>> -    {
> >>> -        P2M_ERROR("dom %d already has memory allocated\n", d->domain_id);
> >>> -        p2m_unlock(p2m);
> >>> -        return -EINVAL;
> >>> -    }
> >>
> >> Instead of checking the list to be empty, how about checking
> >> domain_tot_pages() to return zero?
> >
> > I could do that, and in fact my original code did, but with more
> > consideration the whole test just didn't make sense to me. Yes,
> > clearly the p2m has to be there before pages can be added into it,
> > but I can't see any reason why you couldn't even allocate the
> > entire guest RAM, then create the p2m and then add the pages into
> > it.
> 
> Right - more hypercalls (XENMEM_increase_reservation + operations
> like XENMAPSPACE_gmfn), and hence slower overall domain creation.
> Plus - XENMEM_increase_reservation is not very useful for
> translated domains, as it won't return the MFNs allocated, and
> there's no way to specify where they should appear in GFN space.
> Hence in practice I don't see how this whole operation could
> work without XENMEM_populate_physmap.
> 

Oh, it would mean a big change in the tools etc. so I'm not saying it's a good idea or even possible at the moment. I was just pointing out that, as far as the lower layers of code in Xen go, page allocation and p2m insertion are distinct actions.

  Paul

Jan Beulich March 6, 2020, 1:06 p.m. UTC | #5

On 06.03.2020 13:50, Durrant, Paul wrote:
>> -----Original Message-----
>> From: Jan Beulich <[e-mail]>
>> Sent: 06 March 2020 12:47
>> To: Durrant, Paul <[e-mail]>
>> Cc: [e-mail]; [e-mail]; Andrew Cooper <[e-mail]>;
>> George Dunlap <[e-mail]>; Wei Liu <[e-mail]>; Roger Pau Monné <[e-mail]>
>> Subject: Re: [PATCH v3 2/6] x86 / p2m: remove page_list check in p2m_alloc_table
>>
>> On 06.03.2020 13:07, Durrant, Paul wrote:
>>>> -----Original Message-----
>>>> From: Jan Beulich <[e-mail]>
>>>> Sent: 06 March 2020 11:46
>>>> To: [e-mail]
>>>> Cc: [e-mail]; Durrant, Paul <[e-mail]>; Andrew Cooper
>>>> <[e-mail]>; George Dunlap <[e-mail]>; Wei Liu <[e-mail]>; Roger
>> Pau
>>>> Monné <[e-mail]>
>>>> Subject: Re: [PATCH v3 2/6] x86 / p2m: remove page_list check in p2m_alloc_table
>>>>
>>>> On 05.03.2020 13:45, [e-mail] wrote:
>>>>> From: Paul Durrant <[e-mail]>
>>>>>
>>>>> There does not seem to be any justification for refusing to create the
>>>>> domain's p2m table simply because it may have assigned pages.
>>>>
>>>> I think there is: If any such allocation had happened before, how
>>>> would it be represented in the domain's p2m?
>>>
>>> Insertion into the p2m is a separate action from page allocation. Why should they be linked?
>>
>> They are, because of how XENMEM_populate_physmap works. Yes,
>> they _could_ be separate steps, but that's only a theoretical
>> consideration.
> 
> Then surely the check should be in the XENMEM_populate_physmap code?

How that? populate-physmap can be called any number of times. We
can't refuse a 2nd call there just because a 1st one had happened
already. Or did you mean the inverse check (i.e. that there
already is a p2m)? This surely wouldn't be a bad idea, as
otherwise both ept_get_entry() and p2m_pt_get_entry() would
blindly map MFN 0. But adding such a check wouldn't eliminate
the reason to also have the check that you're proposing to drop.

Jan

Paul Durrant March 6, 2020, 1:11 p.m. UTC | #6

> -----Original Message-----
> From: Jan Beulich <[e-mail]>
> Sent: 06 March 2020 13:07
> To: Durrant, Paul <[e-mail]>
> Cc: [e-mail]; [e-mail]; Andrew Cooper <[e-mail]>;
> George Dunlap <[e-mail]>; Wei Liu <[e-mail]>; Roger Pau Monné <[e-mail]>
> Subject: RE: [EXTERNAL][PATCH v3 2/6] x86 / p2m: remove page_list check in p2m_alloc_table
> 
> CAUTION: This email originated from outside of the organization. Do not click links or open
> attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> On 06.03.2020 13:50, Durrant, Paul wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <[e-mail]>
> >> Sent: 06 March 2020 12:47
> >> To: Durrant, Paul <[e-mail]>
> >> Cc: [e-mail]; [e-mail]; Andrew Cooper <[e-mail]>;
> >> George Dunlap <[e-mail]>; Wei Liu <[e-mail]>; Roger Pau Monné
> <[e-mail]>
> >> Subject: Re: [PATCH v3 2/6] x86 / p2m: remove page_list check in p2m_alloc_table
> >>
> >> On 06.03.2020 13:07, Durrant, Paul wrote:
> >>>> -----Original Message-----
> >>>> From: Jan Beulich <[e-mail]>
> >>>> Sent: 06 March 2020 11:46
> >>>> To: [e-mail]
> >>>> Cc: [e-mail]; Durrant, Paul <[e-mail]>; Andrew Cooper
> >>>> <[e-mail]>; George Dunlap <[e-mail]>; Wei Liu <[e-mail]>;
> Roger
> >> Pau
> >>>> Monné <[e-mail]>
> >>>> Subject: Re: [PATCH v3 2/6] x86 / p2m: remove page_list check in p2m_alloc_table
> >>>>
> >>>> On 05.03.2020 13:45, [e-mail] wrote:
> >>>>> From: Paul Durrant <[e-mail]>
> >>>>>
> >>>>> There does not seem to be any justification for refusing to create the
> >>>>> domain's p2m table simply because it may have assigned pages.
> >>>>
> >>>> I think there is: If any such allocation had happened before, how
> >>>> would it be represented in the domain's p2m?
> >>>
> >>> Insertion into the p2m is a separate action from page allocation. Why should they be linked?
> >>
> >> They are, because of how XENMEM_populate_physmap works. Yes,
> >> they _could_ be separate steps, but that's only a theoretical
> >> consideration.
> >
> > Then surely the check should be in the XENMEM_populate_physmap code?
> 
> How that? populate-physmap can be called any number of times. We
> can't refuse a 2nd call there just because a 1st one had happened
> already. Or did you mean the inverse check (i.e. that there
> already is a p2m)?

Yes, I mean check the p2m has been initialized there.

> This surely wouldn't be a bad idea, as
> otherwise both ept_get_entry() and p2m_pt_get_entry() would
> blindly map MFN 0. But adding such a check wouldn't eliminate
> the reason to also have the check that you're proposing to drop.
> 

Why not? Anywhere assuming the existence of a p2m ought to check for it; I still can't see why initialising the p2m after having allocated pages (PGC_extra or otherwise) is inherently wrong.

  Paul

> Jan

Jan Beulich March 6, 2020, 1:19 p.m. UTC | #7

On 06.03.2020 14:11, Paul Durrant wrote:
>> -----Original Message-----
>> From: Jan Beulich <[e-mail]>
>> Sent: 06 March 2020 13:07
>> To: Durrant, Paul <[e-mail]>
>> Cc: [e-mail]; [e-mail]; Andrew Cooper <[e-mail]>;
>> George Dunlap <[e-mail]>; Wei Liu <[e-mail]>; Roger Pau Monné <[e-mail]>
>> Subject: RE: [EXTERNAL][PATCH v3 2/6] x86 / p2m: remove page_list check in p2m_alloc_table
>>
>> CAUTION: This email originated from outside of the organization. Do not click links or open
>> attachments unless you can confirm the sender and know the content is safe.
>>
>>
>>
>> On 06.03.2020 13:50, Durrant, Paul wrote:
>>>> -----Original Message-----
>>>> From: Jan Beulich <[e-mail]>
>>>> Sent: 06 March 2020 12:47
>>>> To: Durrant, Paul <[e-mail]>
>>>> Cc: [e-mail]; [e-mail]; Andrew Cooper <[e-mail]>;
>>>> George Dunlap <[e-mail]>; Wei Liu <[e-mail]>; Roger Pau Monné
>> <[e-mail]>
>>>> Subject: Re: [PATCH v3 2/6] x86 / p2m: remove page_list check in p2m_alloc_table
>>>>
>>>> On 06.03.2020 13:07, Durrant, Paul wrote:
>>>>>> -----Original Message-----
>>>>>> From: Jan Beulich <[e-mail]>
>>>>>> Sent: 06 March 2020 11:46
>>>>>> To: [e-mail]
>>>>>> Cc: [e-mail]; Durrant, Paul <[e-mail]>; Andrew Cooper
>>>>>> <[e-mail]>; George Dunlap <[e-mail]>; Wei Liu <[e-mail]>;
>> Roger
>>>> Pau
>>>>>> Monné <[e-mail]>
>>>>>> Subject: Re: [PATCH v3 2/6] x86 / p2m: remove page_list check in p2m_alloc_table
>>>>>>
>>>>>> On 05.03.2020 13:45, [e-mail] wrote:
>>>>>>> From: Paul Durrant <[e-mail]>
>>>>>>>
>>>>>>> There does not seem to be any justification for refusing to create the
>>>>>>> domain's p2m table simply because it may have assigned pages.
>>>>>>
>>>>>> I think there is: If any such allocation had happened before, how
>>>>>> would it be represented in the domain's p2m?
>>>>>
>>>>> Insertion into the p2m is a separate action from page allocation. Why should they be linked?
>>>>
>>>> They are, because of how XENMEM_populate_physmap works. Yes,
>>>> they _could_ be separate steps, but that's only a theoretical
>>>> consideration.
>>>
>>> Then surely the check should be in the XENMEM_populate_physmap code?
>>
>> How that? populate-physmap can be called any number of times. We
>> can't refuse a 2nd call there just because a 1st one had happened
>> already. Or did you mean the inverse check (i.e. that there
>> already is a p2m)?
> 
> Yes, I mean check the p2m has been initialized there.
> 
>> This surely wouldn't be a bad idea, as
>> otherwise both ept_get_entry() and p2m_pt_get_entry() would
>> blindly map MFN 0. But adding such a check wouldn't eliminate
>> the reason to also have the check that you're proposing to drop.
>>
> 
> Why not? Anywhere assuming the existence of a p2m ought to check
> for it;

As said - I agree this wouldn't be a bad thing to do. It would
be a requirement if paging_enable() wasn't called from
hvm_domain_initialise(), but via a distinct domctl. But since
it is, there's no way to invoke populate-physmap on a domain
without its p2m root table already allocated.

> I still can't see why initialising the p2m after having allocated
> pages (PGC_extra or otherwise) is inherently wrong.

"inherently" as in "from an abstract pov" - yes. But within the
constraints of the hypercalls available - no. Yet what gets
checked has to be of practical use, not just of theoretical one.
I.e. I'd be fine to see the check go away when a viable
alternative mechanism to allocate and _then_ populate p2m gets
introduced.

Jan

Paul Durrant March 6, 2020, 1:25 p.m. UTC | #8

> -----Original Message-----
> From: Jan Beulich <[e-mail]>
> Sent: 06 March 2020 13:19
> To: Paul Durrant <[e-mail]>
> Cc: [e-mail]; [e-mail]; 'Andrew Cooper' <[e-mail]>;
> 'George Dunlap' <[e-mail]>; 'Wei Liu' <[e-mail]>; 'Roger Pau Monné'
> <[e-mail]>
> Subject: Re: [EXTERNAL][PATCH v3 2/6] x86 / p2m: remove page_list check in p2m_alloc_table
> 
> On 06.03.2020 14:11, Paul Durrant wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <[e-mail]>
> >> Sent: 06 March 2020 13:07
> >> To: Durrant, Paul <[e-mail]>
> >> Cc: [e-mail]; [e-mail]; Andrew Cooper <[e-mail]>;
> >> George Dunlap <[e-mail]>; Wei Liu <[e-mail]>; Roger Pau Monné
> <[e-mail]>
> >> Subject: RE: [EXTERNAL][PATCH v3 2/6] x86 / p2m: remove page_list check in p2m_alloc_table
> >>
> >> CAUTION: This email originated from outside of the organization. Do not click links or open
> >> attachments unless you can confirm the sender and know the content is safe.
> >>
> >>
> >>
> >> On 06.03.2020 13:50, Durrant, Paul wrote:
> >>>> -----Original Message-----
> >>>> From: Jan Beulich <[e-mail]>
> >>>> Sent: 06 March 2020 12:47
> >>>> To: Durrant, Paul <[e-mail]>
> >>>> Cc: [e-mail]; [e-mail]; Andrew Cooper <[e-mail]>;
> >>>> George Dunlap <[e-mail]>; Wei Liu <[e-mail]>; Roger Pau Monné
> >> <[e-mail]>
> >>>> Subject: Re: [PATCH v3 2/6] x86 / p2m: remove page_list check in p2m_alloc_table
> >>>>
> >>>> On 06.03.2020 13:07, Durrant, Paul wrote:
> >>>>>> -----Original Message-----
> >>>>>> From: Jan Beulich <[e-mail]>
> >>>>>> Sent: 06 March 2020 11:46
> >>>>>> To: [e-mail]
> >>>>>> Cc: [e-mail]; Durrant, Paul <[e-mail]>; Andrew Cooper
> >>>>>> <[e-mail]>; George Dunlap <[e-mail]>; Wei Liu <[e-mail]>;
> >> Roger
> >>>> Pau
> >>>>>> Monné <[e-mail]>
> >>>>>> Subject: Re: [PATCH v3 2/6] x86 / p2m: remove page_list check in p2m_alloc_table
> >>>>>>
> >>>>>> On 05.03.2020 13:45, [e-mail] wrote:
> >>>>>>> From: Paul Durrant <[e-mail]>
> >>>>>>>
> >>>>>>> There does not seem to be any justification for refusing to create the
> >>>>>>> domain's p2m table simply because it may have assigned pages.
> >>>>>>
> >>>>>> I think there is: If any such allocation had happened before, how
> >>>>>> would it be represented in the domain's p2m?
> >>>>>
> >>>>> Insertion into the p2m is a separate action from page allocation. Why should they be linked?
> >>>>
> >>>> They are, because of how XENMEM_populate_physmap works. Yes,
> >>>> they _could_ be separate steps, but that's only a theoretical
> >>>> consideration.
> >>>
> >>> Then surely the check should be in the XENMEM_populate_physmap code?
> >>
> >> How that? populate-physmap can be called any number of times. We
> >> can't refuse a 2nd call there just because a 1st one had happened
> >> already. Or did you mean the inverse check (i.e. that there
> >> already is a p2m)?
> >
> > Yes, I mean check the p2m has been initialized there.
> >
> >> This surely wouldn't be a bad idea, as
> >> otherwise both ept_get_entry() and p2m_pt_get_entry() would
> >> blindly map MFN 0. But adding such a check wouldn't eliminate
> >> the reason to also have the check that you're proposing to drop.
> >>
> >
> > Why not? Anywhere assuming the existence of a p2m ought to check
> > for it;
> 
> As said - I agree this wouldn't be a bad thing to do. It would
> be a requirement if paging_enable() wasn't called from
> hvm_domain_initialise(), but via a distinct domctl. But since
> it is, there's no way to invoke populate-physmap on a domain
> without its p2m root table already allocated.
> 
> > I still can't see why initialising the p2m after having allocated
> > pages (PGC_extra or otherwise) is inherently wrong.
> 
> "inherently" as in "from an abstract pov" - yes. But within the
> constraints of the hypercalls available - no. Yet what gets
> checked has to be of practical use, not just of theoretical one.
> I.e. I'd be fine to see the check go away when a viable
> alternative mechanism to allocate and _then_ populate p2m gets
> introduced.
> 

OK... it still seems like the wrong place to me, but I'll leave the check and simply exclude PGG_extra pages.

  Paul

Patch

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 3719deae77..9fd4b115be 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -695,14 +695,6 @@  int p2m_alloc_table(struct p2m_domain *p2m)
 
     p2m_lock(p2m);
 
-    if ( p2m_is_hostp2m(p2m)
-         && !page_list_empty(&d->page_list) )
-    {
-        P2M_ERROR("dom %d already has memory allocated\n", d->domain_id);
-        p2m_unlock(p2m);
-        return -EINVAL;
-    }
-
     if ( pagetable_get_pfn(p2m_get_pagetable(p2m)) != 0 )
     {
         P2M_ERROR("p2m already allocated for this domain\n");