From: Julien Grall <julien.grall@citrix.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
Date: Wed, 29 Jul 2015 11:25:58 +0000 [thread overview]
Message-ID: <55B8B846.2060103@citrix.com> (raw)
In-Reply-To: <55B7D40B.5080903@oracle.com>
Hi Boris,
On 28/07/15 20:12, Boris Ostrovsky wrote:
> On 07/28/2015 11:02 AM, Julien Grall wrote:
>> Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
>> is meant, I suspect this is because the first support for Xen was for
>> PV. This brough some misimplementation of helpers on ARM and make the
>> developper confused the expected behavior.
>>
>> For instance, with pfn_to_mfn, we expect to get an MFN based on the name.
>> Although, if we look at the implementation on x86, it's returning a GFN.
>>
>> For clarity and avoid new confusion, replace any reference of mfn into
>> gnf in any helpers used by PV drivers.
>
>
>
>
>> @@ -730,7 +730,7 @@ static void xen_do_pin(unsigned level, unsigned
>> long pfn)
>> struct mmuext_op op;
>>
>> op.cmd = level;
>> - op.arg1.mfn = pfn_to_mfn(pfn);
>> + op.arg1.mfn = pfn_to_gfn(pfn);
>
>
> This looks slightly odd. It is correct but given that purpose of this
> series is to make things more clear perhaps we can add another union
> member (gfn) to mmuext_op.arg1?
>
> (Of course, the hypervisor will continue referring to mfn which could
> still be confusing)
This operation is only used for PV guests, right?
IHMO re-introducing pfn_to_mfn for PV-guests only (i.e with a BUG_ON to
ensure no usage for auto-translated guest) would be the best solution.
It would avoid to have different name than the hypersivor one in the
hypercall interface. It will also make clear that virt_to_machine & co
is only PV specific.
I though doing this but I preferred to defer it to x86 expert as my
knowledge for x86 Xen is very limited. I don't know where it's more
suitable to use MFN or GFN. I guess this file (mmu.c) is mostly PV specific?
Would something like below fine for you?
static inline unsigned long pfn_to_mfn(unsigned long pfn)
{
unsigned long mfn;
BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
mfn = __pfn_to_mfn(pfn);
if (mfn != INVALID_P2M_ENTRY)
mfn &= ~(FOREIGN_FRAME_BIT | IDENTITY_FRAME_BIT);
return mfn;
}
static inline unsigned long pfn_to_gfn(unsigned long pfn)
{
if (xen_feature(XENFEAT_autotranslated_physmap))
return pfn;
else
return pfn_to_mfn(pfn);
}
Similar splitting would be done for gfn_to_pfn and mfn_to_pfn.
Regards,
--
Julien Grall
WARNING: multiple messages have this Message-ID (diff)
From: Julien Grall <julien.grall@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
xen-devel@lists.xenproject.org
Cc: linux-fbdev@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
"Jiri Slaby" <jslaby@suse.com>,
stefano.stabellini@eu.citrix.com,
"Russell King" <linux@arm.linux.org.uk>,
linux-scsi@vger.kernel.org, x86@kernel.org,
"Tomi Valkeinen" <tomi.valkeinen@ti.com>,
linux-input@vger.kernel.org,
"Jean-Christophe Plagniol-Villard" <plagnioj@jcrosoft.com>,
ian.campbell@citrix.com,
"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
"James E.J. Bottomley" <JBottomley@odin.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
linux-arm-kernel@lists.infradead.org,
"Juergen Gross" <jgross@suse.com>,
"Wei Liu" <wei.liu2@citrix.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
linux-kernel@vger.kernel.org,
"David Vrabel" <david.vrabel@citrix.com>,
netdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
Date: Wed, 29 Jul 2015 12:25:58 +0100 [thread overview]
Message-ID: <55B8B846.2060103@citrix.com> (raw)
In-Reply-To: <55B7D40B.5080903@oracle.com>
Hi Boris,
On 28/07/15 20:12, Boris Ostrovsky wrote:
> On 07/28/2015 11:02 AM, Julien Grall wrote:
>> Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
>> is meant, I suspect this is because the first support for Xen was for
>> PV. This brough some misimplementation of helpers on ARM and make the
>> developper confused the expected behavior.
>>
>> For instance, with pfn_to_mfn, we expect to get an MFN based on the name.
>> Although, if we look at the implementation on x86, it's returning a GFN.
>>
>> For clarity and avoid new confusion, replace any reference of mfn into
>> gnf in any helpers used by PV drivers.
>
>
>
>
>> @@ -730,7 +730,7 @@ static void xen_do_pin(unsigned level, unsigned
>> long pfn)
>> struct mmuext_op op;
>>
>> op.cmd = level;
>> - op.arg1.mfn = pfn_to_mfn(pfn);
>> + op.arg1.mfn = pfn_to_gfn(pfn);
>
>
> This looks slightly odd. It is correct but given that purpose of this
> series is to make things more clear perhaps we can add another union
> member (gfn) to mmuext_op.arg1?
>
> (Of course, the hypervisor will continue referring to mfn which could
> still be confusing)
This operation is only used for PV guests, right?
IHMO re-introducing pfn_to_mfn for PV-guests only (i.e with a BUG_ON to
ensure no usage for auto-translated guest) would be the best solution.
It would avoid to have different name than the hypersivor one in the
hypercall interface. It will also make clear that virt_to_machine & co
is only PV specific.
I though doing this but I preferred to defer it to x86 expert as my
knowledge for x86 Xen is very limited. I don't know where it's more
suitable to use MFN or GFN. I guess this file (mmu.c) is mostly PV specific?
Would something like below fine for you?
static inline unsigned long pfn_to_mfn(unsigned long pfn)
{
unsigned long mfn;
BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
mfn = __pfn_to_mfn(pfn);
if (mfn != INVALID_P2M_ENTRY)
mfn &= ~(FOREIGN_FRAME_BIT | IDENTITY_FRAME_BIT);
return mfn;
}
static inline unsigned long pfn_to_gfn(unsigned long pfn)
{
if (xen_feature(XENFEAT_autotranslated_physmap))
return pfn;
else
return pfn_to_mfn(pfn);
}
Similar splitting would be done for gfn_to_pfn and mfn_to_pfn.
Regards,
--
Julien Grall
WARNING: multiple messages have this Message-ID (diff)
From: Julien Grall <julien.grall@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
<xen-devel@lists.xenproject.org>
Cc: linux-fbdev@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
"Jiri Slaby" <jslaby@suse.com>,
stefano.stabellini@eu.citrix.com,
"Russell King" <linux@arm.linux.org.uk>,
linux-scsi@vger.kernel.org, x86@kernel.org,
"Tomi Valkeinen" <tomi.valkeinen@ti.com>,
linux-input@vger.kernel.org,
"Jean-Christophe Plagniol-Villard" <plagnioj@jcrosoft.com>,
ian.campbell@citrix.com,
"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
"James E.J. Bottomley" <JBottomley@odin.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
linux-arm-kernel@lists.infradead.org,
"Juergen Gross" <jgross@suse.com>,
"Wei Liu" <wei.liu2@citrix.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
linux-kernel@vger.kernel.org,
"David Vrabel" <david.vrabel@citrix.com>,
netdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
Date: Wed, 29 Jul 2015 12:25:58 +0100 [thread overview]
Message-ID: <55B8B846.2060103@citrix.com> (raw)
In-Reply-To: <55B7D40B.5080903@oracle.com>
Hi Boris,
On 28/07/15 20:12, Boris Ostrovsky wrote:
> On 07/28/2015 11:02 AM, Julien Grall wrote:
>> Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
>> is meant, I suspect this is because the first support for Xen was for
>> PV. This brough some misimplementation of helpers on ARM and make the
>> developper confused the expected behavior.
>>
>> For instance, with pfn_to_mfn, we expect to get an MFN based on the name.
>> Although, if we look at the implementation on x86, it's returning a GFN.
>>
>> For clarity and avoid new confusion, replace any reference of mfn into
>> gnf in any helpers used by PV drivers.
>
>
>
>
>> @@ -730,7 +730,7 @@ static void xen_do_pin(unsigned level, unsigned
>> long pfn)
>> struct mmuext_op op;
>>
>> op.cmd = level;
>> - op.arg1.mfn = pfn_to_mfn(pfn);
>> + op.arg1.mfn = pfn_to_gfn(pfn);
>
>
> This looks slightly odd. It is correct but given that purpose of this
> series is to make things more clear perhaps we can add another union
> member (gfn) to mmuext_op.arg1?
>
> (Of course, the hypervisor will continue referring to mfn which could
> still be confusing)
This operation is only used for PV guests, right?
IHMO re-introducing pfn_to_mfn for PV-guests only (i.e with a BUG_ON to
ensure no usage for auto-translated guest) would be the best solution.
It would avoid to have different name than the hypersivor one in the
hypercall interface. It will also make clear that virt_to_machine & co
is only PV specific.
I though doing this but I preferred to defer it to x86 expert as my
knowledge for x86 Xen is very limited. I don't know where it's more
suitable to use MFN or GFN. I guess this file (mmu.c) is mostly PV specific?
Would something like below fine for you?
static inline unsigned long pfn_to_mfn(unsigned long pfn)
{
unsigned long mfn;
BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
mfn = __pfn_to_mfn(pfn);
if (mfn != INVALID_P2M_ENTRY)
mfn &= ~(FOREIGN_FRAME_BIT | IDENTITY_FRAME_BIT);
return mfn;
}
static inline unsigned long pfn_to_gfn(unsigned long pfn)
{
if (xen_feature(XENFEAT_autotranslated_physmap))
return pfn;
else
return pfn_to_mfn(pfn);
}
Similar splitting would be done for gfn_to_pfn and mfn_to_pfn.
Regards,
--
Julien Grall
WARNING: multiple messages have this Message-ID (diff)
From: julien.grall@citrix.com (Julien Grall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
Date: Wed, 29 Jul 2015 12:25:58 +0100 [thread overview]
Message-ID: <55B8B846.2060103@citrix.com> (raw)
In-Reply-To: <55B7D40B.5080903@oracle.com>
Hi Boris,
On 28/07/15 20:12, Boris Ostrovsky wrote:
> On 07/28/2015 11:02 AM, Julien Grall wrote:
>> Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
>> is meant, I suspect this is because the first support for Xen was for
>> PV. This brough some misimplementation of helpers on ARM and make the
>> developper confused the expected behavior.
>>
>> For instance, with pfn_to_mfn, we expect to get an MFN based on the name.
>> Although, if we look at the implementation on x86, it's returning a GFN.
>>
>> For clarity and avoid new confusion, replace any reference of mfn into
>> gnf in any helpers used by PV drivers.
>
>
>
>
>> @@ -730,7 +730,7 @@ static void xen_do_pin(unsigned level, unsigned
>> long pfn)
>> struct mmuext_op op;
>>
>> op.cmd = level;
>> - op.arg1.mfn = pfn_to_mfn(pfn);
>> + op.arg1.mfn = pfn_to_gfn(pfn);
>
>
> This looks slightly odd. It is correct but given that purpose of this
> series is to make things more clear perhaps we can add another union
> member (gfn) to mmuext_op.arg1?
>
> (Of course, the hypervisor will continue referring to mfn which could
> still be confusing)
This operation is only used for PV guests, right?
IHMO re-introducing pfn_to_mfn for PV-guests only (i.e with a BUG_ON to
ensure no usage for auto-translated guest) would be the best solution.
It would avoid to have different name than the hypersivor one in the
hypercall interface. It will also make clear that virt_to_machine & co
is only PV specific.
I though doing this but I preferred to defer it to x86 expert as my
knowledge for x86 Xen is very limited. I don't know where it's more
suitable to use MFN or GFN. I guess this file (mmu.c) is mostly PV specific?
Would something like below fine for you?
static inline unsigned long pfn_to_mfn(unsigned long pfn)
{
unsigned long mfn;
BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
mfn = __pfn_to_mfn(pfn);
if (mfn != INVALID_P2M_ENTRY)
mfn &= ~(FOREIGN_FRAME_BIT | IDENTITY_FRAME_BIT);
return mfn;
}
static inline unsigned long pfn_to_gfn(unsigned long pfn)
{
if (xen_feature(XENFEAT_autotranslated_physmap))
return pfn;
else
return pfn_to_mfn(pfn);
}
Similar splitting would be done for gfn_to_pfn and mfn_to_pfn.
Regards,
--
Julien Grall
WARNING: multiple messages have this Message-ID (diff)
From: Julien Grall <julien.grall@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
<xen-devel@lists.xenproject.org>
Cc: linux-fbdev@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
"Jiri Slaby" <jslaby@suse.com>,
stefano.stabellini@eu.citrix.com,
"Russell King" <linux@arm.linux.org.uk>,
linux-scsi@vger.kernel.org, x86@kernel.org,
"Tomi Valkeinen" <tomi.valkeinen@ti.com>,
linux-input@vger.kernel.org,
"Jean-Christophe Plagniol-Villard" <plagnioj@jcrosoft.com>,
ian.campbell@citrix.com,
"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
"James E.J. Bottomley" <JBottomley@odin.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
linux-arm-kernel@lists.infradead.org,
"Juergen Gross" <jgross@suse.com>,
"Wei Liu" <wei.liu2@citrix.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
linux-kernel@vger.kernel.org,
"David Vrabel" <david.vrabel@citrix.com>,
netdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
Date: Wed, 29 Jul 2015 12:25:58 +0100 [thread overview]
Message-ID: <55B8B846.2060103@citrix.com> (raw)
In-Reply-To: <55B7D40B.5080903@oracle.com>
Hi Boris,
On 28/07/15 20:12, Boris Ostrovsky wrote:
> On 07/28/2015 11:02 AM, Julien Grall wrote:
>> Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
>> is meant, I suspect this is because the first support for Xen was for
>> PV. This brough some misimplementation of helpers on ARM and make the
>> developper confused the expected behavior.
>>
>> For instance, with pfn_to_mfn, we expect to get an MFN based on the name.
>> Although, if we look at the implementation on x86, it's returning a GFN.
>>
>> For clarity and avoid new confusion, replace any reference of mfn into
>> gnf in any helpers used by PV drivers.
>
>
>
>
>> @@ -730,7 +730,7 @@ static void xen_do_pin(unsigned level, unsigned
>> long pfn)
>> struct mmuext_op op;
>>
>> op.cmd = level;
>> - op.arg1.mfn = pfn_to_mfn(pfn);
>> + op.arg1.mfn = pfn_to_gfn(pfn);
>
>
> This looks slightly odd. It is correct but given that purpose of this
> series is to make things more clear perhaps we can add another union
> member (gfn) to mmuext_op.arg1?
>
> (Of course, the hypervisor will continue referring to mfn which could
> still be confusing)
This operation is only used for PV guests, right?
IHMO re-introducing pfn_to_mfn for PV-guests only (i.e with a BUG_ON to
ensure no usage for auto-translated guest) would be the best solution.
It would avoid to have different name than the hypersivor one in the
hypercall interface. It will also make clear that virt_to_machine & co
is only PV specific.
I though doing this but I preferred to defer it to x86 expert as my
knowledge for x86 Xen is very limited. I don't know where it's more
suitable to use MFN or GFN. I guess this file (mmu.c) is mostly PV specific?
Would something like below fine for you?
static inline unsigned long pfn_to_mfn(unsigned long pfn)
{
unsigned long mfn;
BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
mfn = __pfn_to_mfn(pfn);
if (mfn != INVALID_P2M_ENTRY)
mfn &= ~(FOREIGN_FRAME_BIT | IDENTITY_FRAME_BIT);
return mfn;
}
static inline unsigned long pfn_to_gfn(unsigned long pfn)
{
if (xen_feature(XENFEAT_autotranslated_physmap))
return pfn;
else
return pfn_to_mfn(pfn);
}
Similar splitting would be done for gfn_to_pfn and mfn_to_pfn.
Regards,
--
Julien Grall
next prev parent reply other threads:[~2015-07-29 11:25 UTC|newest]
Thread overview: 153+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-28 15:02 [PATCH 0/8] Use correctly the Xen memory terminologies in Linux Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` [PATCH 1/8] arm/xen: Remove helpers which are PV specific Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-31 10:44 ` Stefano Stabellini
2015-07-31 10:44 ` Stefano Stabellini
2015-07-31 10:44 ` Stefano Stabellini
2015-07-31 10:55 ` Ian Campbell
2015-07-31 10:55 ` Ian Campbell
2015-08-04 16:36 ` Julien Grall
2015-08-04 16:36 ` [Xen-devel] " Julien Grall
2015-08-04 16:36 ` Julien Grall
2015-07-31 10:55 ` Ian Campbell
2015-07-28 15:02 ` [PATCH 2/8] xen: Make clear that swiotlb and biomerge are dealing with DMA address Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:52 ` David Vrabel
2015-07-28 15:52 ` [Xen-devel] " David Vrabel
2015-07-28 15:52 ` David Vrabel
2015-07-28 16:06 ` Julien Grall
2015-07-28 16:06 ` Julien Grall
2015-07-28 16:06 ` Julien Grall
2015-07-31 10:54 ` [Xen-devel] " Stefano Stabellini
2015-07-31 10:54 ` Stefano Stabellini
2015-07-31 10:54 ` Stefano Stabellini
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` [PATCH 3/8] arm/xen: implement correctly pfn_to_mfn Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` [PATCH 4/8] xen: Use the correctly the Xen memory terminologies Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 17:16 ` [Xen-devel] " David Vrabel
2015-07-28 17:16 ` David Vrabel
2015-07-28 17:16 ` David Vrabel
2015-07-28 17:16 ` David Vrabel
2015-07-28 17:16 ` David Vrabel
2015-07-29 11:06 ` Julien Grall
2015-07-29 11:06 ` Julien Grall
2015-07-29 11:06 ` Julien Grall
2015-07-29 11:06 ` Julien Grall
2015-07-29 11:06 ` Julien Grall
2015-07-29 11:06 ` Julien Grall
2015-07-28 17:16 ` David Vrabel
2015-07-28 19:12 ` Boris Ostrovsky
2015-07-28 19:12 ` Boris Ostrovsky
2015-07-28 19:12 ` Boris Ostrovsky
2015-07-28 19:12 ` Boris Ostrovsky
2015-07-28 19:12 ` Boris Ostrovsky
2015-07-29 11:25 ` Julien Grall
2015-07-29 11:25 ` Julien Grall [this message]
2015-07-29 11:25 ` Julien Grall
2015-07-29 11:25 ` Julien Grall
2015-07-29 11:25 ` Julien Grall
2015-07-29 11:25 ` Julien Grall
2015-07-29 14:14 ` Boris Ostrovsky
2015-07-29 14:14 ` Boris Ostrovsky
2015-07-29 14:14 ` Boris Ostrovsky
2015-07-29 14:14 ` Boris Ostrovsky
2015-07-29 14:23 ` Julien Grall
2015-07-29 14:23 ` Julien Grall
2015-07-29 14:23 ` Julien Grall
2015-07-29 14:23 ` Julien Grall
2015-07-29 14:23 ` Julien Grall
2015-07-29 14:23 ` Julien Grall
2015-07-29 14:51 ` Boris Ostrovsky
2015-07-29 14:51 ` Boris Ostrovsky
2015-07-29 14:51 ` Boris Ostrovsky
2015-07-29 14:51 ` Boris Ostrovsky
2015-07-29 14:51 ` Boris Ostrovsky
2015-07-29 14:14 ` Boris Ostrovsky
2015-07-28 19:39 ` Chris (Christopher) Brand
2015-07-28 19:39 ` [Xen-devel] " Chris (Christopher) Brand
2015-07-28 19:39 ` Chris (Christopher) Brand
2015-07-28 19:39 ` Chris (Christopher) Brand
2015-07-28 19:39 ` Chris (Christopher) Brand
2015-07-28 19:39 ` Chris (Christopher) Brand
2015-07-28 19:39 ` Chris (Christopher) Brand
2015-07-29 11:27 ` Julien Grall
2015-07-29 11:27 ` [Xen-devel] " Julien Grall
2015-07-29 11:27 ` Julien Grall
2015-07-29 11:27 ` Julien Grall
2015-07-29 11:27 ` Julien Grall
2015-07-29 11:27 ` Julien Grall
2015-07-29 10:13 ` Wei Liu
2015-07-29 10:13 ` Wei Liu
2015-07-29 10:13 ` Wei Liu
2015-07-29 10:13 ` Wei Liu
2015-07-29 11:35 ` [Xen-devel] " Julien Grall
2015-07-29 11:35 ` Julien Grall
2015-07-29 11:35 ` Julien Grall
2015-07-29 11:35 ` Julien Grall
2015-07-29 11:35 ` Julien Grall
2015-07-29 11:38 ` David Vrabel
2015-07-29 11:38 ` David Vrabel
2015-07-29 11:38 ` David Vrabel
2015-07-29 11:38 ` David Vrabel
2015-07-29 11:38 ` David Vrabel
2015-07-29 11:39 ` Wei Liu
2015-07-29 11:39 ` [Xen-devel] " Wei Liu
2015-07-29 11:39 ` Wei Liu
2015-07-29 11:39 ` Wei Liu
2015-07-29 11:39 ` Wei Liu
2015-07-29 11:39 ` Wei Liu
2015-07-29 11:35 ` Julien Grall
2015-07-29 10:13 ` Wei Liu
2015-07-31 11:02 ` Stefano Stabellini
2015-07-31 11:02 ` Stefano Stabellini
2015-07-31 11:02 ` Stefano Stabellini
2015-07-31 11:02 ` Stefano Stabellini
2015-07-31 11:02 ` Stefano Stabellini
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` [PATCH 5/8] xen/tmem: Use page_to_gfn rather than pfn_to_gfn Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` [PATCH 6/8] video/xen-fbfront: Further s/MFN/GFN clean-up Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 17:16 ` [Xen-devel] " David Vrabel
2015-07-28 17:16 ` David Vrabel
2015-07-28 17:16 ` David Vrabel
2015-07-28 15:02 ` [PATCH 7/8] hvc/xen: " Julien Grall
2015-07-28 17:17 ` [Xen-devel] " David Vrabel
2015-07-28 17:17 ` David Vrabel
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` [PATCH 8/8] xen/privcmd: Further s/MFN/GFN/ clean-up Julien Grall
2015-07-28 15:02 ` Julien Grall
2015-07-28 15:02 ` Julien Grall
[not found] ` <1438095769-2560-9-git-send-email-julien.grall-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
2015-07-28 17:19 ` [Xen-devel] " David Vrabel
2015-07-28 17:19 ` David Vrabel
2015-07-28 17:19 ` David Vrabel
2015-07-28 17:19 ` David Vrabel
2015-07-28 21:06 ` [PATCH 0/8] Use correctly the Xen memory terminologies in Linux H. Peter Anvin
2015-07-28 21:06 ` H. Peter Anvin
2015-07-28 21:06 ` H. Peter Anvin
2015-07-28 21:06 ` H. Peter Anvin
2015-07-28 21:06 ` H. Peter Anvin
2015-07-28 21:12 ` [Xen-devel] " Andrew Cooper
2015-07-28 21:12 ` Andrew Cooper
2015-07-28 21:12 ` Andrew Cooper
2015-07-28 21:12 ` Andrew Cooper
2015-07-28 21:12 ` Andrew Cooper
2015-07-28 21:12 ` Andrew Cooper
2015-07-29 11:02 ` Julien Grall
2015-07-29 11:02 ` Julien Grall
2015-07-29 11:02 ` Julien Grall
2015-07-29 11:02 ` Julien Grall
2015-07-29 11:02 ` Julien Grall
2015-07-29 11:02 ` Julien Grall
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=55B8B846.2060103@citrix.com \
--to=julien.grall@citrix.com \
--cc=linux-arm-kernel@lists.infradead.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.