Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1501115 > unrolled thread

[PATCH 6/8] xen/pvh: Initialize grant table for PVH guests

Started byBoris Ostrovsky <boris.ostrovsky@oracle.com>
First post2016-10-14 20:20 +0200
Last post2016-10-19 07:50 +0200
Articles 8 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-10-14 20:20 +0200
    Re: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH  guests Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> - 2016-10-14 21:30 +0200
      Re: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH  guests Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-10-14 21:50 +0200
        Re: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH  guests Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> - 2016-10-14 22:00 +0200
          Re: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH  guests Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-10-14 22:10 +0200
            Re: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH  guests Juergen Gross <jgross@suse.com> - 2016-10-18 18:10 +0200
              Re: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH  guests Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-10-18 18:40 +0200
                Re: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH  guests Juergen Gross <jgross@suse.com> - 2016-10-19 07:50 +0200

#1501115 — [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests

FromBoris Ostrovsky <boris.ostrovsky@oracle.com>
Date2016-10-14 20:20 +0200
Subject[PATCH 6/8] xen/pvh: Initialize grant table for PVH guests
Message-ID<ssffk-4Pd-15@gated-at.bofh.it>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 drivers/xen/grant-table.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bb36b1e..d6786b8 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -1146,13 +1146,13 @@ int gnttab_init(void)
 
 static int __gnttab_init(void)
 {
+	if (!xen_domain())
+		return -ENODEV;
+
 	/* Delay grant-table initialization in the PV on HVM case */
-	if (xen_hvm_domain())
+	if (xen_hvm_domain() && !xen_pvh_domain())
 		return 0;
 
-	if (!xen_pv_domain())
-		return -ENODEV;
-
 	return gnttab_init();
 }
 /* Starts after core_initcall so that xen_pvh_gnttab_setup can be called
-- 
1.8.3.1

[toc] | [next] | [standalone]


#1501161 — Re: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests

FromKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date2016-10-14 21:30 +0200
SubjectRe: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests
Message-ID<ssgl3-5wE-3@gated-at.bofh.it>
In reply to#1501115
On Fri, Oct 14, 2016 at 02:05:16PM -0400, Boris Ostrovsky wrote:

Perhaps add in here:

PVH is like PV in that there are no PCI devices - which HVM
code would piggyback on to find the Xen PCI platform device and
use its MMIO space to stash the grants in.

For PVH we balloon out memory and stash the grants in there.

(Which begs the next question - where and when do we balloon out the
normal memory back in?)

> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>  drivers/xen/grant-table.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index bb36b1e..d6786b8 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -1146,13 +1146,13 @@ int gnttab_init(void)
>  
>  static int __gnttab_init(void)
>  {
> +	if (!xen_domain())
> +		return -ENODEV;
> +
>  	/* Delay grant-table initialization in the PV on HVM case */
> -	if (xen_hvm_domain())
> +	if (xen_hvm_domain() && !xen_pvh_domain())
>  		return 0;
>  
> -	if (!xen_pv_domain())
> -		return -ENODEV;
> -
>  	return gnttab_init();
>  }
>  /* Starts after core_initcall so that xen_pvh_gnttab_setup can be called
> -- 
> 1.8.3.1
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

[toc] | [prev] | [next] | [standalone]


#1501169 — Re: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests

FromBoris Ostrovsky <boris.ostrovsky@oracle.com>
Date2016-10-14 21:50 +0200
SubjectRe: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests
Message-ID<ssgEp-5Iq-5@gated-at.bofh.it>
In reply to#1501161
On 10/14/2016 03:19 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 14, 2016 at 02:05:16PM -0400, Boris Ostrovsky wrote:
>
> Perhaps add in here:
>
> PVH is like PV in that there are no PCI devices - which HVM
> code would piggyback on to find the Xen PCI platform device and
> use its MMIO space to stash the grants in.
>
> For PVH we balloon out memory and stash the grants in there.
>
> (Which begs the next question - where and when do we balloon out the
> normal memory back in?)

Are you saying that we should get back memory that we gave to grant tables?

-boris


>
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> ---
>>  drivers/xen/grant-table.c | 8 ++++----
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
>> index bb36b1e..d6786b8 100644
>> --- a/drivers/xen/grant-table.c
>> +++ b/drivers/xen/grant-table.c
>> @@ -1146,13 +1146,13 @@ int gnttab_init(void)
>>  
>>  static int __gnttab_init(void)
>>  {
>> +	if (!xen_domain())
>> +		return -ENODEV;
>> +
>>  	/* Delay grant-table initialization in the PV on HVM case */
>> -	if (xen_hvm_domain())
>> +	if (xen_hvm_domain() && !xen_pvh_domain())
>>  		return 0;
>>  
>> -	if (!xen_pv_domain())
>> -		return -ENODEV;
>> -
>>  	return gnttab_init();
>>  }
>>  /* Starts after core_initcall so that xen_pvh_gnttab_setup can be called
>> -- 
>> 1.8.3.1
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> https://lists.xen.org/xen-devel

[toc] | [prev] | [next] | [standalone]


#1501173 — Re: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests

FromKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date2016-10-14 22:00 +0200
SubjectRe: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests
Message-ID<ssgOa-5LV-3@gated-at.bofh.it>
In reply to#1501169
On Fri, Oct 14, 2016 at 03:43:19PM -0400, Boris Ostrovsky wrote:
> On 10/14/2016 03:19 PM, Konrad Rzeszutek Wilk wrote:
> > On Fri, Oct 14, 2016 at 02:05:16PM -0400, Boris Ostrovsky wrote:
> >
> > Perhaps add in here:
> >
> > PVH is like PV in that there are no PCI devices - which HVM
> > code would piggyback on to find the Xen PCI platform device and
> > use its MMIO space to stash the grants in.
> >
> > For PVH we balloon out memory and stash the grants in there.
> >
> > (Which begs the next question - where and when do we balloon out the
> > normal memory back in?)
> 
> Are you saying that we should get back memory that we gave to grant tables?

Yes.

In pure HVM that area is MMIO - which hvmloader has balloonned out.

The hvmloader then balloons that number of pages back  at the end of
guest memory (after 4GB).

[toc] | [prev] | [next] | [standalone]


#1501175 — Re: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests

FromBoris Ostrovsky <boris.ostrovsky@oracle.com>
Date2016-10-14 22:10 +0200
SubjectRe: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests
Message-ID<ssgXL-64U-1@gated-at.bofh.it>
In reply to#1501173
On 10/14/2016 03:51 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 14, 2016 at 03:43:19PM -0400, Boris Ostrovsky wrote:
>> On 10/14/2016 03:19 PM, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Oct 14, 2016 at 02:05:16PM -0400, Boris Ostrovsky wrote:
>>>
>>> Perhaps add in here:
>>>
>>> PVH is like PV in that there are no PCI devices - which HVM
>>> code would piggyback on to find the Xen PCI platform device and
>>> use its MMIO space to stash the grants in.
>>>
>>> For PVH we balloon out memory and stash the grants in there.
>>>
>>> (Which begs the next question - where and when do we balloon out the
>>> normal memory back in?)
>> Are you saying that we should get back memory that we gave to grant tables?
> Yes.
>
> In pure HVM that area is MMIO - which hvmloader has balloonned out.
>
> The hvmloader then balloons that number of pages back  at the end of
> guest memory (after 4GB).

We don't do this for PV though, do we?

-boris

[toc] | [prev] | [next] | [standalone]


#1503181 — Re: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests

FromJuergen Gross <jgross@suse.com>
Date2016-10-18 18:10 +0200
SubjectRe: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests
Message-ID<stF7I-42I-39@gated-at.bofh.it>
In reply to#1501175
On 14/10/16 22:02, Boris Ostrovsky wrote:
> On 10/14/2016 03:51 PM, Konrad Rzeszutek Wilk wrote:
>> On Fri, Oct 14, 2016 at 03:43:19PM -0400, Boris Ostrovsky wrote:
>>> On 10/14/2016 03:19 PM, Konrad Rzeszutek Wilk wrote:
>>>> On Fri, Oct 14, 2016 at 02:05:16PM -0400, Boris Ostrovsky wrote:
>>>>
>>>> Perhaps add in here:
>>>>
>>>> PVH is like PV in that there are no PCI devices - which HVM
>>>> code would piggyback on to find the Xen PCI platform device and
>>>> use its MMIO space to stash the grants in.
>>>>
>>>> For PVH we balloon out memory and stash the grants in there.
>>>>
>>>> (Which begs the next question - where and when do we balloon out the
>>>> normal memory back in?)
>>> Are you saying that we should get back memory that we gave to grant tables?
>> Yes.
>>
>> In pure HVM that area is MMIO - which hvmloader has balloonned out.
>>
>> The hvmloader then balloons that number of pages back  at the end of
>> guest memory (after 4GB).
> 
> We don't do this for PV though, do we?

Uuh, kind of. We try to allocate granted pages from the ballooned area.
See gnttab_alloc_pages().

So for PV(H) we don't need to balloon this memory back in as it was
never shadowed by a grant.


Juergen

[toc] | [prev] | [next] | [standalone]


#1503206 — Re: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests

FromBoris Ostrovsky <boris.ostrovsky@oracle.com>
Date2016-10-18 18:40 +0200
SubjectRe: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests
Message-ID<stFAJ-4gM-1@gated-at.bofh.it>
In reply to#1503181
On 10/18/2016 12:08 PM, Juergen Gross wrote:
> On 14/10/16 22:02, Boris Ostrovsky wrote:
>> On 10/14/2016 03:51 PM, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Oct 14, 2016 at 03:43:19PM -0400, Boris Ostrovsky wrote:
>>>> On 10/14/2016 03:19 PM, Konrad Rzeszutek Wilk wrote:
>>>>> On Fri, Oct 14, 2016 at 02:05:16PM -0400, Boris Ostrovsky wrote:
>>>>>
>>>>> Perhaps add in here:
>>>>>
>>>>> PVH is like PV in that there are no PCI devices - which HVM
>>>>> code would piggyback on to find the Xen PCI platform device and
>>>>> use its MMIO space to stash the grants in.
>>>>>
>>>>> For PVH we balloon out memory and stash the grants in there.
>>>>>
>>>>> (Which begs the next question - where and when do we balloon out the
>>>>> normal memory back in?)
>>>> Are you saying that we should get back memory that we gave to grant tables?
>>> Yes.
>>>
>>> In pure HVM that area is MMIO - which hvmloader has balloonned out.
>>>
>>> The hvmloader then balloons that number of pages back  at the end of
>>> guest memory (after 4GB).
>> We don't do this for PV though, do we?
> Uuh, kind of. We try to allocate granted pages from the ballooned area.
> See gnttab_alloc_pages().


I meant that we don't give memory back for PV.


>
> So for PV(H) we don't need to balloon this memory back in as it was
> never shadowed by a grant.


Is it *never* or *may or may not be* shadowed? (I assume "shadowed"
means "used for" here.)

-boris

[toc] | [prev] | [next] | [standalone]


#1503568 — Re: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests

FromJuergen Gross <jgross@suse.com>
Date2016-10-19 07:50 +0200
SubjectRe: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests
Message-ID<stRVf-58A-3@gated-at.bofh.it>
In reply to#1503206
On 18/10/16 18:40, Boris Ostrovsky wrote:
> On 10/18/2016 12:08 PM, Juergen Gross wrote:
>> On 14/10/16 22:02, Boris Ostrovsky wrote:
>>> On 10/14/2016 03:51 PM, Konrad Rzeszutek Wilk wrote:
>>>> On Fri, Oct 14, 2016 at 03:43:19PM -0400, Boris Ostrovsky wrote:
>>>>> On 10/14/2016 03:19 PM, Konrad Rzeszutek Wilk wrote:
>>>>>> On Fri, Oct 14, 2016 at 02:05:16PM -0400, Boris Ostrovsky wrote:
>>>>>>
>>>>>> Perhaps add in here:
>>>>>>
>>>>>> PVH is like PV in that there are no PCI devices - which HVM
>>>>>> code would piggyback on to find the Xen PCI platform device and
>>>>>> use its MMIO space to stash the grants in.
>>>>>>
>>>>>> For PVH we balloon out memory and stash the grants in there.
>>>>>>
>>>>>> (Which begs the next question - where and when do we balloon out the
>>>>>> normal memory back in?)
>>>>> Are you saying that we should get back memory that we gave to grant tables?
>>>> Yes.
>>>>
>>>> In pure HVM that area is MMIO - which hvmloader has balloonned out.
>>>>
>>>> The hvmloader then balloons that number of pages back  at the end of
>>>> guest memory (after 4GB).
>>> We don't do this for PV though, do we?
>> Uuh, kind of. We try to allocate granted pages from the ballooned area.
>> See gnttab_alloc_pages().
> 
> 
> I meant that we don't give memory back for PV.

That's right AFAIK.

>> So for PV(H) we don't need to balloon this memory back in as it was
>> never shadowed by a grant.
> 
> 
> Is it *never* or *may or may not be* shadowed? (I assume "shadowed"
> means "used for" here.)

"shadowed" means a pte is being used for a granted page which was
referencing a RAM page before. So the RAM page is unusable as long as
the grant is active.

A page is shadowed by a grant only if there is no ballooning space
available, so ballooning that page out would serve no purpose as we
would have no way to balloon it in at another address.


Juergen

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web