Pulling out this one comment for the attention on the core Xen/Linux
maintainers.
On Thu, 2014-03-06 at 21:48 +, Zoltan Kiss wrote:
[...]
> @@ -343,8 +347,26 @@ struct xenvif *xenvif_alloc(struct device *parent,
> domid_t domid,
> vif->pending_prod = MAX_PENDING_REQS;
> for (i =
a
> huge perfomance penalty. The classic kernel version of netback used grant
> mapping, and to get notified when the page can be unmapped, it used page
> destructors. Unfortunately that destructor is not an upstreamable solution.
> Ian Campbell's skb fragment destructor patch seri
perfomance penalty. The classic kernel version of netback used grant
mapping, and to get notified when the page can be unmapped, it used page
destructors. Unfortunately that destructor is not an upstreamable solution.
Ian Campbell's skb fragment destructor patch series [1] tried to solve this
problem
Pulling out this one comment for the attention on the core Xen/Linux
maintainers.
On Thu, 2014-03-06 at 21:48 +, Zoltan Kiss wrote:
[...]
@@ -343,8 +347,26 @@ struct xenvif *xenvif_alloc(struct device *parent,
domid_t domid,
vif-pending_prod = MAX_PENDING_REQS;
for (i = 0; i
];
/* Coalescing tx requests before copying makes number of grant
* copy ops greater or equal to number of slots required. In
* worst case a tx request consumes 2 gnttab_copy.
*/
struct gnttab_copy tx_copy_ops[2*MAX_PENDING_REQS];
-
+ struct
On Wed, 2014-03-12 at 15:40 +, Ian Campbell wrote:
On Sat, 2014-03-08 at 18:57 -0500, David Miller wrote:
From: Zoltan Kiss zoltan.k...@citrix.com
Date: Sat, 8 Mar 2014 14:37:50 +
Maybe you mixed up mine with that? But that's also not eligible to be
applied yet.
I can
grant_tx_handle[MAX_PENDING_REQS];
/* Coalescing tx requests before copying makes number of grant
* copy ops greater or equal to number of slots required. In
* worst case a tx request consumes 2 gnttab_copy.
*/
struct gnttab_copy tx_copy_ops[2*MAX_PENDING_REQS
pending_tx_info[MAX_PENDING_REQS];
+ grant_handle_t grant_tx_handle[MAX_PENDING_REQS];
/* Coalescing tx requests before copying makes number of grant
* copy ops greater or equal to number of slots required. In
* worst case a tx request consumes 2 gnttab_copy
[MAX_PENDING_REQS];
struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
+ grant_handle_t grant_tx_handle[MAX_PENDING_REQS];
/* Coalescing tx requests before copying makes number of grant
* copy ops greater or equal to number of slots required. In
* worst case a tx request consumes 2
pending_cons;
u16 pending_ring[MAX_PENDING_REQS];
struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
+grant_handle_t grant_tx_handle[MAX_PENDING_REQS];
/* Coalescing tx requests before copying makes number of grant
* copy ops greater
On 13/03/14 10:17, Ian Campbell wrote:
Pulling out this one comment for the attention on the core Xen/Linux
maintainers.
On Thu, 2014-03-06 at 21:48 +, Zoltan Kiss wrote:
[...]
@@ -343,8 +347,26 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t
domid,
vif-pending_prod
];
+ grant_handle_t grant_tx_handle[MAX_PENDING_REQS];
/* Coalescing tx requests before copying makes number of grant
* copy ops greater or equal to number of slots required. In
* worst case a tx request consumes 2 gnttab_copy.
*/
struct gnttab_copy tx_copy_ops[2
pending_tx_info[MAX_PENDING_REQS];
+ grant_handle_t grant_tx_handle[MAX_PENDING_REQS];
/* Coalescing tx requests before copying makes number of grant
* copy ops greater or equal to number of slots required. In
* worst case a tx request consumes 2 gnttab_copy
On 13/03/14 13:56, Ian Campbell wrote:
On Thu, 2014-03-13 at 13:17 +, Zoltan Kiss wrote:
On 13/03/14 10:33, Ian Campbell wrote:
On Thu, 2014-03-06 at 21:48 +, Zoltan Kiss wrote:
+ netdev_err(vif-dev,
+ Page still
NICs, and generally it's a
huge perfomance penalty. The classic kernel version of netback used grant
mapping, and to get notified when the page can be unmapped, it used page
destructors. Unfortunately that destructor is not an upstreamable solution.
Ian Campbell's skb fragment destructor patch series
On 12/03/14 15:40, Ian Campbell wrote:
On Sat, 2014-03-08 at 18:57 -0500, David Miller wrote:
From: Zoltan Kiss
Date: Sat, 8 Mar 2014 14:37:50 +
Maybe you mixed up mine with that? But that's also not eligible to be
applied yet.
I can always revert the series if there are major
On Sat, 2014-03-08 at 18:57 -0500, David Miller wrote:
> From: Zoltan Kiss
> Date: Sat, 8 Mar 2014 14:37:50 +
>
> > Maybe you mixed up mine with that? But that's also not eligible to be
> > applied yet.
>
> I can always revert the series if there are major objections.
Zoltan -- does this
On Sat, 2014-03-08 at 18:57 -0500, David Miller wrote:
From: Zoltan Kiss zoltan.k...@citrix.com
Date: Sat, 8 Mar 2014 14:37:50 +
Maybe you mixed up mine with that? But that's also not eligible to be
applied yet.
I can always revert the series if there are major objections.
Zoltan
On 12/03/14 15:40, Ian Campbell wrote:
On Sat, 2014-03-08 at 18:57 -0500, David Miller wrote:
From: Zoltan Kiss zoltan.k...@citrix.com
Date: Sat, 8 Mar 2014 14:37:50 +
Maybe you mixed up mine with that? But that's also not eligible to be
applied yet.
I can always revert the series if
On 27/02/14 15:55, Zoltan Kiss wrote:
> (This is a continuation of "[PATCH v9] xen/grant-table: Avoid m2p_override
> during mapping")
>
> The grant mapping API does m2p_override unnecessarily: only gntdev needs it,
> for blkback and future netback patches it jus
David/Stefano, can you take a look, and ack if you are happy with this?
I could build it on ARM and a backported version on 3.10 have seen quite
a lot of testing recently.
Zoli
On 27/02/14 15:55, Zoltan Kiss wrote:
(This is a continuation of "[PATCH v9] xen/grant-table: Avoid m2p_ove
On Sat, Mar 08, 2014 at 06:57:59PM -0500, David Miller wrote:
> From: Zoltan Kiss
> Date: Sat, 8 Mar 2014 14:37:50 +
>
> > Maybe you mixed up mine with that? But that's also not eligible to be
> > applied yet.
>
> I can always revert the series if there are major objections.
David, I
On Sat, Mar 08, 2014 at 06:57:59PM -0500, David Miller wrote:
From: Zoltan Kiss zoltan.k...@citrix.com
Date: Sat, 8 Mar 2014 14:37:50 +
Maybe you mixed up mine with that? But that's also not eligible to be
applied yet.
I can always revert the series if there are major objections.
David/Stefano, can you take a look, and ack if you are happy with this?
I could build it on ARM and a backported version on 3.10 have seen quite
a lot of testing recently.
Zoli
On 27/02/14 15:55, Zoltan Kiss wrote:
(This is a continuation of [PATCH v9] xen/grant-table: Avoid m2p_override
On 27/02/14 15:55, Zoltan Kiss wrote:
(This is a continuation of [PATCH v9] xen/grant-table: Avoid m2p_override
during mapping)
The grant mapping API does m2p_override unnecessarily: only gntdev needs it,
for blkback and future netback patches it just cause a lock contention, as
those pages
From: Zoltan Kiss
Date: Sat, 8 Mar 2014 14:37:50 +
> Maybe you mixed up mine with that? But that's also not eligible to be
> applied yet.
I can always revert the series if there are major objections.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
NICs, and generally it's a
huge perfomance penalty. The classic kernel version of netback used grant
mapping, and to get notified when the page can be unmapped, it used page
destructors. Unfortunately that destructor is not an upstreamable solution.
Ian Campbell's skb fragment destructor patch
a bottleneck with 10Gb NICs, and generally it's a
huge perfomance penalty. The classic kernel version of netback used grant
mapping, and to get notified when the page can be unmapped, it used page
destructors. Unfortunately that destructor is not an upstreamable solution.
Ian Campbell's skb fragment
From: Zoltan Kiss zoltan.k...@citrix.com
Date: Sat, 8 Mar 2014 14:37:50 +
Maybe you mixed up mine with that? But that's also not eligible to be
applied yet.
I can always revert the series if there are major objections.
--
To unsubscribe from this list: send the line unsubscribe
a
> huge perfomance penalty. The classic kernel version of netback used grant
> mapping, and to get notified when the page can be unmapped, it used page
> destructors. Unfortunately that destructor is not an upstreamable solution.
> Ian Campbell's skb fragment destructor patch seri
, and generally it's a
huge perfomance penalty. The classic kernel version of netback used grant
mapping, and to get notified when the page can be unmapped, it used page
destructors. Unfortunately that destructor is not an upstreamable solution.
Ian Campbell's skb fragment destructor patch series [1] tried
These became obsolete with grant mapping. I've left intentionally the
indentations in this way, to improve readability of previous patches.
NOTE: if bisect brought you here, you should apply the series up until
"xen-netback: Timeout packets in RX path", otherwise Windows guests
This patch introduces grant mapping on netback TX path. It replaces grant copy
operations, ditching grant copy coalescing along the way. Another solution for
copy coalescing is introduced in "xen-netback: Handle guests with too many
frags", older guests and Windows can broke before
grant
mapping, and to get notified when the page can be unmapped, it used page
destructors. Unfortunately that destructor is not an upstreamable solution.
Ian Campbell's skb fragment destructor patch series [1] tried to solve this
problem, however it seems to be very invasive on the network stack's code
grant
mapping, and to get notified when the page can be unmapped, it used page
destructors. Unfortunately that destructor is not an upstreamable solution.
Ian Campbell's skb fragment destructor patch series [1] tried to solve this
problem, however it seems to be very invasive on the network stack's code
This patch introduces grant mapping on netback TX path. It replaces grant copy
operations, ditching grant copy coalescing along the way. Another solution for
copy coalescing is introduced in xen-netback: Handle guests with too many
frags, older guests and Windows can broke before that patch
These became obsolete with grant mapping. I've left intentionally the
indentations in this way, to improve readability of previous patches.
NOTE: if bisect brought you here, you should apply the series up until
xen-netback: Timeout packets in RX path, otherwise Windows guests can't work
properly
requests before copying makes number of grant
* copy ops greater or equal to number of slots required. In
* worst case a tx request consumes 2 gnttab_copy.
*/
struct gnttab_copy tx_copy_ops[2*MAX_PENDING_REQS];
Forget to remove this?
No, it is removed in the next
On Tue, Mar 04, 2014 at 10:32:15PM +, Zoltan Kiss wrote:
> This patch introduces grant mapping on netback TX path. It replaces grant copy
> operations, ditching grant copy coalescing along the way. Another solution for
> copy coalescing is introduced in patch #7, older guests and Wi
On Tue, Mar 04, 2014 at 10:32:15PM +, Zoltan Kiss wrote:
This patch introduces grant mapping on netback TX path. It replaces grant copy
operations, ditching grant copy coalescing along the way. Another solution for
copy coalescing is introduced in patch #7, older guests and Windows can
requests before copying makes number of grant
* copy ops greater or equal to number of slots required. In
* worst case a tx request consumes 2 gnttab_copy.
*/
struct gnttab_copy tx_copy_ops[2*MAX_PENDING_REQS];
Forget to remove this?
No, it is removed in the next
On Mar 4, 2014 5:32 PM, Zoltan Kiss wrote:
>
> This patch introduces grant mapping on netback TX path. It replaces grant
> copy
> operations, ditching grant copy coalescing along the way. Another solution
> for
> copy coalescing is introduced in patch #7, older guests and
This patch introduces grant mapping on netback TX path. It replaces grant copy
operations, ditching grant copy coalescing along the way. Another solution for
copy coalescing is introduced in patch #7, older guests and Windows can broke
before that patch applies.
There is a callback
These became obsolete with grant mapping. I've left intentionally the
indentations in this way, to improve readability of previous patches.
NOTE: if bisect brought you here, you should apply the series up until #9,
otherwise Windows guests can't work properly and malicious guests can block
other
grant
mapping, and to get notified when the page can be unmapped, it used page
destructors. Unfortunately that destructor is not an upstreamable solution.
Ian Campbell's skb fragment destructor patch series [1] tried to solve this
problem, however it seems to be very invasive on the network stack's code
grant
mapping, and to get notified when the page can be unmapped, it used page
destructors. Unfortunately that destructor is not an upstreamable solution.
Ian Campbell's skb fragment destructor patch series [1] tried to solve this
problem, however it seems to be very invasive on the network stack's code
These became obsolete with grant mapping. I've left intentionally the
indentations in this way, to improve readability of previous patches.
NOTE: if bisect brought you here, you should apply the series up until #9,
otherwise Windows guests can't work properly and malicious guests can block
other
This patch introduces grant mapping on netback TX path. It replaces grant copy
operations, ditching grant copy coalescing along the way. Another solution for
copy coalescing is introduced in patch #7, older guests and Windows can broke
before that patch applies.
There is a callback
On Mar 4, 2014 5:32 PM, Zoltan Kiss zoltan.k...@citrix.com wrote:
This patch introduces grant mapping on netback TX path. It replaces grant
copy
operations, ditching grant copy coalescing along the way. Another solution
for
copy coalescing is introduced in patch #7, older guests
(This is a continuation of "[PATCH v9] xen/grant-table: Avoid m2p_override
during mapping")
The grant mapping API does m2p_override unnecessarily: only gntdev needs it,
for blkback and future netback patches it just cause a lock contention, as
those pages never go to userspace.
(This is a continuation of [PATCH v9] xen/grant-table: Avoid m2p_override
during mapping)
The grant mapping API does m2p_override unnecessarily: only gntdev needs it,
for blkback and future netback patches it just cause a lock contention, as
those pages never go to userspace. Therefore
On 22/02/14 22:33, Zoltan Kiss wrote:
On 18/02/14 17:40, Ian Campbell wrote:
+ */
+skb->pfmemalloc= false;
}
static int xenvif_get_extras(struct xenvif *vif,
@@ -1372,7 +1341,7 @@ static bool tx_credit_exceeded(struct xenvif
*vif, unsigned size)
@@ -1581,7 +1535,11 @@
NICs, and generally it's a
huge perfomance penalty. The classic kernel version of netback used grant
mapping, and to get notified when the page can be unmapped, it used page
destructors. Unfortunately that destructor is not an upstreamable solution.
Ian Campbell's skb fragment destructor patch series
On Fri, 2014-02-21 at 01:19 +, Zoltan Kiss wrote:
> I don't know if the guest expects that slots for the same packet
> comes back at the same time.
I don't think the guest is allowed to assume that. In particular they
aren't allowed to assume the the slots will be freed in the order they
On Fri, 2014-02-21 at 01:19 +, Zoltan Kiss wrote:
I don't know if the guest expects that slots for the same packet
comes back at the same time.
I don't think the guest is allowed to assume that. In particular they
aren't allowed to assume the the slots will be freed in the order they
were
NICs, and generally it's a
huge perfomance penalty. The classic kernel version of netback used grant
mapping, and to get notified when the page can be unmapped, it used page
destructors. Unfortunately that destructor is not an upstreamable solution.
Ian Campbell's skb fragment destructor patch series
On 22/02/14 22:33, Zoltan Kiss wrote:
On 18/02/14 17:40, Ian Campbell wrote:
+ */
+skb-pfmemalloc= false;
}
static int xenvif_get_extras(struct xenvif *vif,
@@ -1372,7 +1341,7 @@ static bool tx_credit_exceeded(struct xenvif
*vif, unsigned size)
@@ -1581,7 +1535,11 @@
On 18/02/14 17:40, Ian Campbell wrote:
On Mon, 2014-01-20 at 21:24 +, Zoltan Kiss wrote:
This patch changes the grant copy on the TX patch to grant mapping
Both this and the previous patch had a single sentence commit message (I
count them together since they are split weirdly
On 18/02/14 17:40, Ian Campbell wrote:
On Mon, 2014-01-20 at 21:24 +, Zoltan Kiss wrote:
This patch changes the grant copy on the TX patch to grant mapping
Both this and the previous patch had a single sentence commit message (I
count them together since they are split weirdly
contains the new definitions necessary for grant mapping.
Is this just adding a bunch of (currently) unused functions? That's a
slightly odd way to structure a series. They don't seem to be "generic
helpers" or anything so it would be more normal to introduce these as
they get used --
here:
>>>>>> use_ptemod = !xen_feature(XENFEAT_auto_translated_physmap);
>>>>>> So I think we can't rely on kmap_ops to decide whether we should
>>>>>> m2p_override
>>>>>> or not.
>>>>>>
>>>>>&
t;>>> or not.
> >>>>
> >>>>> Is it possible to realize if the mapping is a userspace mapping by
> >>>>> checking for GNTMAP_application_map in map_ops?
> >>>>> Otherwise I would keep the boolean and rename it to use
> or not.
>>>>
>>>>> Is it possible to realize if the mapping is a userspace mapping by
>>>>> checking for GNTMAP_application_map in map_ops?
>>>>> Otherwise I would keep the boolean and rename it to user_mapping.
>>>> So
y
> > > > checking for GNTMAP_application_map in map_ops?
> > > > Otherwise I would keep the boolean and rename it to user_mapping.
> > > Sounds better, but as far as I see gntdev set that flag in
> > > find_grant_ptes,
> > > which is called only
&
ted_physmap) we shouldn't need the
m2p_override.
So it's safe to assume that we need m2p_override only if kmap_ops !=
NULL, and we can avoid the extra bool parameter, is that correct? At
least with the current users of grant mapping it seems to be true.
In which case we don't need the wrappers
On Mon, 17 Feb 2014, Zoltan Kiss wrote:
> On 16/02/14 18:36, Stefano Stabellini wrote:
> > On Wed, 12 Feb 2014, Zoltan Kiss wrote:
> > > diff --git a/arch/arm/include/asm/xen/page.h
> > > b/arch/arm/include/asm/xen/page.h
> > > index e0965ab..4eaeb3f 100644
> > > ---
; >>>>This patch contains the new definitions necessary for grant mapping.
> >>>
> >>>Is this just adding a bunch of (currently) unused functions? That's a
> >>>slightly odd way to structure a series. They don't seem to be "generic
> >>&g
>>>> This patch contains the new definitions necessary for grant mapping.
> >>>
> >>> Is this just adding a bunch of (currently) unused functions? That's a
> >>> slightly odd way to structure a series. They don't seem to be "generic
> >>>
for grant mapping.
Is this just adding a bunch of (currently) unused functions? That's a
slightly odd way to structure a series. They don't seem to be generic
helpers or anything so it would be more normal to introduce these as
they get used -- it's a bit hard to review them out
necessary for grant mapping.
Is this just adding a bunch of (currently) unused functions? That's a
slightly odd way to structure a series. They don't seem to be generic
helpers or anything so it would be more normal to introduce these as
they get used -- it's a bit hard to review them out of context
On Mon, 17 Feb 2014, Zoltan Kiss wrote:
On 16/02/14 18:36, Stefano Stabellini wrote:
On Wed, 12 Feb 2014, Zoltan Kiss wrote:
diff --git a/arch/arm/include/asm/xen/page.h
b/arch/arm/include/asm/xen/page.h
index e0965ab..4eaeb3f 100644
--- a/arch/arm/include/asm/xen/page.h
+++
shouldn't need the
m2p_override.
So it's safe to assume that we need m2p_override only if kmap_ops !=
NULL, and we can avoid the extra bool parameter, is that correct? At
least with the current users of grant mapping it seems to be true.
In which case we don't need the wrappers for gnttab_[un]map_refs
, is that correct? At least with the
current users of grant mapping it seems to be true.
In which case we don't need the wrappers for gnttab_[un]map_refs as well.
Actually the most of m2p_add/remove_override takes effect only if there is a
kmap_op parameter, but what about the rest of the code
need the
m2p_override.
So it's safe to assume that we need m2p_override only if kmap_ops != NULL, and
we can avoid the extra bool parameter, is that correct? At least with the
current users of grant mapping it seems to be true.
In which case we don't need the wrappers for gnttab_[un
m2p_override only if kmap_ops != NULL,
and
we can avoid the extra bool parameter, is that correct? At least with the
current users of grant mapping it seems to be true.
In which case we don't need the wrappers for gnttab_[un]map_refs as well.
Actually the most of m2p_add/remove_override
!= NULL,
and
we can avoid the extra bool parameter, is that correct? At least with the
current users of grant mapping it seems to be true.
In which case we don't need the wrappers for gnttab_[un]map_refs as well.
Actually the most of m2p_add/remove_override takes effect only
contains the new definitions necessary for grant mapping.
Is this just adding a bunch of (currently) unused functions? That's a
slightly odd way to structure a series. They don't seem to be generic
helpers or anything so it would be more normal to introduce these as
they get used -- it's a bit hard
On 19/02/14 10:05, Ian Campbell wrote:
On Tue, 2014-02-18 at 20:36 +, Zoltan Kiss wrote:
On 18/02/14 17:06, Ian Campbell wrote:
On Mon, 2014-01-20 at 21:24 +, Zoltan Kiss wrote:
This patch contains the new definitions necessary for grant mapping.
Is this just adding a bunch
On 18/02/14 17:24, Ian Campbell wrote:
On Mon, 2014-01-20 at 21:24 +, Zoltan Kiss wrote:
+ spinlock_t dealloc_lock;
+ spinlock_t response_lock;
Please add comments to both of these describing what bits of the
datastructure they are locking.
You might find it is clearer to
On 19/02/14 09:54, Ian Campbell wrote:
> On Tue, 2014-02-18 at 18:46 +, David Vrabel wrote:
>> On 18/02/14 17:40, Ian Campbell wrote:
>>> On Mon, 2014-01-20 at 21:24 +, Zoltan Kiss wrote:
@@ -344,8 +346,26 @@ struct xenvif *xenvif_alloc(struct device *parent,
domid_t domid,
On Tue, 2014-02-18 at 20:36 +, Zoltan Kiss wrote:
> On 18/02/14 17:06, Ian Campbell wrote:
> > On Mon, 2014-01-20 at 21:24 +, Zoltan Kiss wrote:
> >> This patch contains the new definitions necessary for grant mapping.
> >
> > Is this just adding a bunch o
On Tue, 2014-02-18 at 18:46 +, David Vrabel wrote:
> On 18/02/14 17:40, Ian Campbell wrote:
> > On Mon, 2014-01-20 at 21:24 +, Zoltan Kiss wrote:
> >>
> >> @@ -344,8 +346,26 @@ struct xenvif *xenvif_alloc(struct device *parent,
> >> domid_t domid,
> >>vif->pending_prod =
a
> huge perfomance penalty. The classic kernel version of netback used grant
> mapping, and to get notified when the page can be unmapped, it used page
> destructors. Unfortunately that destructor is not an upstreamable solution.
> Ian Campbell's skb fragment destructor patch seri
perfomance penalty. The classic kernel version of netback used grant
mapping, and to get notified when the page can be unmapped, it used page
destructors. Unfortunately that destructor is not an upstreamable solution.
Ian Campbell's skb fragment destructor patch series [1] tried to solve this
problem
On Tue, 2014-02-18 at 18:46 +, David Vrabel wrote:
On 18/02/14 17:40, Ian Campbell wrote:
On Mon, 2014-01-20 at 21:24 +, Zoltan Kiss wrote:
@@ -344,8 +346,26 @@ struct xenvif *xenvif_alloc(struct device *parent,
domid_t domid,
vif-pending_prod = MAX_PENDING_REQS;
for
On Tue, 2014-02-18 at 20:36 +, Zoltan Kiss wrote:
On 18/02/14 17:06, Ian Campbell wrote:
On Mon, 2014-01-20 at 21:24 +, Zoltan Kiss wrote:
This patch contains the new definitions necessary for grant mapping.
Is this just adding a bunch of (currently) unused functions? That's
On 19/02/14 09:54, Ian Campbell wrote:
On Tue, 2014-02-18 at 18:46 +, David Vrabel wrote:
On 18/02/14 17:40, Ian Campbell wrote:
On Mon, 2014-01-20 at 21:24 +, Zoltan Kiss wrote:
@@ -344,8 +346,26 @@ struct xenvif *xenvif_alloc(struct device *parent,
domid_t domid,
On 18/02/14 17:24, Ian Campbell wrote:
On Mon, 2014-01-20 at 21:24 +, Zoltan Kiss wrote:
+ spinlock_t dealloc_lock;
+ spinlock_t response_lock;
Please add comments to both of these describing what bits of the
datastructure they are locking.
You might find it is clearer to
On 19/02/14 10:05, Ian Campbell wrote:
On Tue, 2014-02-18 at 20:36 +, Zoltan Kiss wrote:
On 18/02/14 17:06, Ian Campbell wrote:
On Mon, 2014-01-20 at 21:24 +, Zoltan Kiss wrote:
This patch contains the new definitions necessary for grant mapping.
Is this just adding a bunch
On 18/02/14 17:06, Ian Campbell wrote:
On Mon, 2014-01-20 at 21:24 +, Zoltan Kiss wrote:
This patch contains the new definitions necessary for grant mapping.
Is this just adding a bunch of (currently) unused functions? That's a
slightly odd way to structure a series. They don't seem
On 18/02/14 17:40, Ian Campbell wrote:
> On Mon, 2014-01-20 at 21:24 +, Zoltan Kiss wrote:
>>
>> @@ -344,8 +346,26 @@ struct xenvif *xenvif_alloc(struct device *parent,
>> domid_t domid,
>> vif->pending_prod = MAX_PENDING_REQS;
>> for (i = 0; i < MAX_PENDING_REQS; i++)
>>
On Mon, 2014-01-20 at 21:24 +, Zoltan Kiss wrote:
> This patch changes the grant copy on the TX patch to grant mapping
Both this and the previous patch had a single sentence commit message (I
count them together since they are split weirdly and are a single
logical change to my eyes).
Rea
On Mon, 2014-01-20 at 21:24 +, Zoltan Kiss wrote:
>
> + spinlock_t dealloc_lock;
> + spinlock_t response_lock;
Please add comments to both of these describing what bits of the
datastructure they are locking.
You might find it is clearer to group the locks and the things they
On Mon, 2014-01-20 at 21:24 +, Zoltan Kiss wrote:
> This patch contains the new definitions necessary for grant mapping.
Is this just adding a bunch of (currently) unused functions? That's a
slightly odd way to structure a series. They don't seem to be "generic
helpers" o
On Mon, 2014-01-20 at 21:24 +, Zoltan Kiss wrote:
This patch contains the new definitions necessary for grant mapping.
Is this just adding a bunch of (currently) unused functions? That's a
slightly odd way to structure a series. They don't seem to be generic
helpers or anything so it would
On Mon, 2014-01-20 at 21:24 +, Zoltan Kiss wrote:
+ spinlock_t dealloc_lock;
+ spinlock_t response_lock;
Please add comments to both of these describing what bits of the
datastructure they are locking.
You might find it is clearer to group the locks and the things they
On Mon, 2014-01-20 at 21:24 +, Zoltan Kiss wrote:
This patch changes the grant copy on the TX patch to grant mapping
Both this and the previous patch had a single sentence commit message (I
count them together since they are split weirdly and are a single
logical change to my eyes).
Really
On 18/02/14 17:40, Ian Campbell wrote:
On Mon, 2014-01-20 at 21:24 +, Zoltan Kiss wrote:
@@ -344,8 +346,26 @@ struct xenvif *xenvif_alloc(struct device *parent,
domid_t domid,
vif-pending_prod = MAX_PENDING_REQS;
for (i = 0; i MAX_PENDING_REQS; i++)
On 18/02/14 17:06, Ian Campbell wrote:
On Mon, 2014-01-20 at 21:24 +, Zoltan Kiss wrote:
This patch contains the new definitions necessary for grant mapping.
Is this just adding a bunch of (currently) unused functions? That's a
slightly odd way to structure a series. They don't seem
On 16/02/14 18:36, Stefano Stabellini wrote:
On Wed, 12 Feb 2014, Zoltan Kiss wrote:
diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index e0965ab..4eaeb3f 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -97,16 +97,15 @@
801 - 900 of 1633 matches
Mail list logo
