xes: ad4f15dc2c70 ("xen/netfront: don't bug in case of too many frags")
Signed-off-by: Dongli Zhang
---
drivers/net/xen-netfront.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 8d33970..5f5722b 100644
fixed in
commit 00b368502d18 ("xen-netfront: do not assume sk_buff_head list is
empty in error handling").
This patch uses an extra argument to help return if there is error in
xennet_fill_frags().
Fixes: ad4f15dc2c70 ("xen/netfront: don't bug in case of too many frags")
Signe
Ping?
Dongli Zhang
On 12/19/2018 09:23 PM, Dongli Zhang wrote:
> The xenstore 'ring-page-order' is used globally for each blkback queue and
> therefore should be read from xenstore only once. However, it is obtained
> in read_per_ring_refs() which might be called multip
As 'be->blkif' is used for many times in connect_ring(), the stack variable
'blkif' is added to substitute 'be-blkif'.
Suggested-by: Paul Durrant
Signed-off-by: Dongli Zhang
---
drivers/block/xen-blkback/xenbus.c | 27 ++-
1 file change
ing() to read xenstore 'ring-page-order' only
once.
Signed-off-by: Dongli Zhang
---
Changed since v1:
* change the order of xenstore read in read_per_ring_refs
* use xenbus_read_unsigned() in connect_ring()
Changed since v2:
* simplify the condition check as "(err != 1 &
On 01/07/2019 08:01 PM, Roger Pau Monné wrote:
> On Mon, Jan 07, 2019 at 01:35:59PM +0800, Dongli Zhang wrote:
>> The xenstore 'ring-page-order' is used globally for each blkback queue and
>> therefore should be read from xenstore only once. However, it is obtained
On 01/07/2019 10:05 PM, Dongli Zhang wrote:
>
>
> On 01/07/2019 08:01 PM, Roger Pau Monné wrote:
>> On Mon, Jan 07, 2019 at 01:35:59PM +0800, Dongli Zhang wrote:
>>> The xenstore 'ring-page-order' is used globally for each blkback queue and
>>> there
As 'be->blkif' is used for many times in connect_ring(), the stack variable
'blkif' is added to substitute 'be-blkif'.
Suggested-by: Paul Durrant
Signed-off-by: Dongli Zhang
Reviewed-by: Paul Durrant
Reviewed-by: Roger Pau Monné
---
driver
ing() to read xenstore 'ring-page-order' only
once.
Signed-off-by: Dongli Zhang
---
Changed since v1:
* change the order of xenstore read in read_per_ring_refs
* use xenbus_read_unsigned() in connect_ring()
Changed since v2:
* simplify the condition check as "(err != 1 &
oops. Please ignore this v5 patch.
I just realized Linus suggested in an old email not use BUG()/BUG_ON() in the
code.
I will switch to the WARN() solution and resend again.
Sorry for the junk email.
Dongli Zhang
On 2019/1/8 下午4:15, Dongli Zhang wrote:
> The xenstore 'ring-page-o
Hi Roger,
On 01/07/2019 11:27 PM, Roger Pau Monné wrote:
> On Mon, Jan 07, 2019 at 10:07:34PM +0800, Dongli Zhang wrote:
>>
>>
>> On 01/07/2019 10:05 PM, Dongli Zhang wrote:
>>>
>>>
>>> On 01/07/2019 08:01 PM, Roger Pau Monné wrote:
>>>
ing() to read xenstore 'ring-page-order' only
once.
Signed-off-by: Dongli Zhang
---
Changed since v1:
* change the order of xenstore read in read_per_ring_refs
* use xenbus_read_unsigned() in connect_ring()
Changed since v2:
* simplify the condition check as "(err != 1 &
As 'be->blkif' is used for many times in connect_ring(), the stack variable
'blkif' is added to substitute 'be-blkif'.
Suggested-by: Paul Durrant
Signed-off-by: Dongli Zhang
Reviewed-by: Paul Durrant
Reviewed-by: Roger Pau Monné
---
driver
There is no need to wake up xen_blkif_schedule() as kthread_stop() is able
to already wake up the kernel thread.
Signed-off-by: Dongli Zhang
---
drivers/block/xen-blkback/xenbus.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/block/xen-blkback/xenbus.c
b
On 2019/1/17 上午12:32, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 08, 2019 at 04:24:32PM +0800, Dongli Zhang wrote:
>> oops. Please ignore this v5 patch.
>>
>> I just realized Linus suggested in an old email not use BUG()/BUG_ON() in
>> the code.
>>
>> I
Hi Roger,
On 2019/1/16 下午10:52, Roger Pau Monné wrote:
> On Wed, Jan 16, 2019 at 09:47:41PM +0800, Dongli Zhang wrote:
>> There is no need to wake up xen_blkif_schedule() as kthread_stop() is able
>> to already wake up the kernel thread.
>>
>> Signed-off-by: Dongli Zhan
Hi Roger,
On 01/17/2019 04:20 PM, Roger Pau Monné wrote:
> On Thu, Jan 17, 2019 at 10:10:00AM +0800, Dongli Zhang wrote:
>> Hi Roger,
>>
>> On 2019/1/16 下午10:52, Roger Pau Monné wrote:
>>> On Wed, Jan 16, 2019 at 09:47:41PM +0800, Dongli Zhang wrote:
&g
r_frags >= MAX_SKB_FRAGS)), but not
just "==". Perhaps __pskb_pull_tail() may fail although pull_to is less than
skb_headlen(skb).
Thank you very much!
Dongli Zhang
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hi Juergen,
On 8/27/19 2:13 PM, Juergen Gross wrote:
> On 18.08.19 10:31, Dongli Zhang wrote:
>> Hi,
>>
>> Would you please help confirm why the condition at line 908 is ">="?
>>
>> In my opinion, we would only hit "skb_shinfo(skb)->nr_frag
I/O hang can be affected by the
lack of grant entry.
If to increase the max frame to 64 takes effect, it is weird why the I/O would
hang when there are still 512 entries available.
Dongli Zhang
>
>> With Xen 4.8, you can add gnttab_max_frames=64 (or another number, but
>> higher t
On 02/12/2019 06:10 AM, Samuel Thibault wrote:
> Hans van Kranenburg, le lun. 11 févr. 2019 22:59:11 +0100, a ecrit:
>> On 2/11/19 2:37 AM, Dongli Zhang wrote:
>>>
>>> On 2/10/19 12:35 AM, Samuel Thibault wrote:
>>>>
>>>> Hans van Kranen
On 2/18/19 5:29 AM, Samuel Thibault wrote:
> Hello,
>
> Dongli Zhang, le mar. 12 févr. 2019 12:11:20 +0800, a ecrit:
>> On 02/12/2019 06:10 AM, Samuel Thibault wrote:
>>> Hans van Kranenburg, le lun. 11 févr. 2019 22:59:11 +0100, a ecrit:
>>>> On
Hi Konrad,
On 1/17/19 11:29 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 15, 2019 at 09:20:36AM +0100, Roger Pau Monné wrote:
>> On Tue, Jan 15, 2019 at 12:41:44AM +0800, Dongli Zhang wrote:
>>> The xenstore 'ring-page-order' is used globally for each blkback queue
emove generic asm headers").
This is not reasonable for stable branch as the patch set involves
lots of changes.
Would you please let me know if there is any suggestion on this issue?
Thank you very much!
Dongli Zhang
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hi Juergen,
On 3/4/19 4:14 PM, Juergen Gross wrote:
> On 01/03/2019 03:35, Dongli Zhang wrote:
>> This issue is only for stable 4.9.x (e.g., 4.9.160), while the root cause is
>> still in the lasted mainline kernel.
>>
>> This is obviated by new feature patch set ended w
Hi Thomas,
On 3/2/19 7:43 AM, Thomas Gleixner wrote:
> On Thu, 28 Feb 2019, Dongli Zhang wrote:
>>
>> The root cause is that the return type of jiffies_to_usecs() is 'unsigned
>> int',
>> but not 'unsigned long'. As a result, the leading 32 bits
This version applies to the v4.9 series.
Link: https://lkml.org/lkml/2019/2/28/1373
Suggested-by: Juergen Gross
Signed-off-by: Dongli Zhang
---
include/linux/jiffies.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h
ind
ue is reproduced on
xen?
This would help synchronize stable with mainline better.
Thank you very much!
Dongli Zhang
On 3/5/19 3:59 PM, Dongli Zhang wrote:
> [ Not relevant upstream, therefore no upstream commit. ]
>
> To fix, use jiffies64_to_nsecs() directly instead of deriv
On 3/12/19 8:56 PM, Greg KH wrote:
> On Wed, Mar 06, 2019 at 03:35:40PM +0800, Dongli Zhang wrote:
>> Thanks to Joe Jin's reminding, this patch is applicable to mainline linux
>> kernel, although there is no issue due to this kind of bug in mainline
>> kernel.
&g
callstack of xenwatch (e.g., netback_remove()
or frontend_changed()).
This patch adds a reference from xenvif to backend_info so that it would be
much more easier to obtain backend_info during coredump analysis.
Signed-off-by: Dongli Zhang
---
drivers/net/xen-netback/common.h | 18
> Another topic is the question whether we should really call
> xen_destroy_contiguous_region() when freeing the memory if there was no
> need to use xen_create_contiguous_region() when allocating it.
What would happen if guest domain is malicious?
That is, guest (including dom0) my allocate unlimited MFN continuous memory and
never exchange them back to xen.
Would MFN continuous memory be used up? As a result, xen may not be able to boot
new VM. Is this a sort of DoS attack?
Dongli Zhang
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Print log at level XENLOG_ERR (instead XENLOG_INFO) as domain_crash()
indicates there is fatal error.
Signed-off-by: Dongli Zhang
---
xen/common/grant_table.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 80728ea
Hi Andrew,
On 04/23/2019 06:37 PM, Andrew Cooper wrote:
> On 22/04/2019 13:39, Dongli Zhang wrote:
>> Print log at level XENLOG_ERR (instead XENLOG_INFO) as domain_crash()
>> indicates there is fatal error.
>>
>> Signed-off-by: Dongli Zhang
>> ---
>> xen
ad4f15dc2c70 ("xen/netfront: don't bug in case of too many frags")
Signed-off-by: Dongli Zhang
---
Changed since v1:
- Always update queue->rx.rsp_cons inside xennet_fill_frags() so we do
not need to add extra argument to xennet_fill_frags().
drivers/net/xen-netfro
mq(), we
>> might hit it in setup_blkring() as well.
>> We should add the similar change to blkif_sring struct as well.
>
>
> Won't you have a similar issue with other frontends, say, netfront?
I think the kmalloc is failed not because of OOM.
In fact, the size of "blkfront_ring_info" is large. When domU have 4
queues/rings, the size of 4 blkfront_ring_info can be about 300+ KB.
There is chance that kmalloc() 300+ KB would fail.
About netfront, to kmalloc() 8 'struct netfront_queue' seems consumes <70 KB?
Dongli Zhang
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hi Manjunath,
On 12/04/2018 10:49 AM, Manjunath Patil wrote:
> On 12/3/2018 6:16 PM, Boris Ostrovsky wrote:
>
>> On 12/3/18 8:14 PM, Dongli Zhang wrote:
>>> Hi Boris,
>>>
>>> On 12/04/2018 12:07 AM, Boris Ostrovsky wrote:
>>>> On 12/2/18 3:31
ing() to read xenstore 'ring-page-order' only
once.
Signed-off-by: Dongli Zhang
---
drivers/block/xen-blkback/xenbus.c | 49 --
1 file changed, 31 insertions(+), 18 deletions(-)
diff --git a/drivers/block/xen-blkback/xenbus.c
b/drivers/block/xen-blk
Hi Paul,
On 12/07/2018 05:39 PM, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of Dongli Zhang
>> Sent: 07 December 2018 04:18
>> To: linux-ker...@vger.kernel.org; xen-devel@list
On 12/07/2018 11:15 PM, Paul Durrant wrote:
>> -Original Message-
>> From: Dongli Zhang [mailto:dongli.zh...@oracle.com]
>> Sent: 07 December 2018 15:10
>> To: Paul Durrant ; linux-ker...@vger.kernel.org;
>> xen-devel@lists.xenproject.org; linux-b
ing() to read xenstore 'ring-page-order' only
once.
Signed-off-by: Dongli Zhang
---
Changed since v1:
* change the order of xenstore read in read_per_ring_refs(suggested by Roger
Pau Monne)
* use xenbus_read_unsigned() in connect_ring() (suggested by Roger Pau Monne
Hi Roger,
On 12/18/2018 05:33 PM, Roger Pau Monné wrote:
> On Tue, Dec 18, 2018 at 08:55:38AM +0800, Dongli Zhang wrote:
>> The xenstore 'ring-page-order' is used globally for each blkback queue and
>> therefore should be read from xenstore only once. Howe
On 12/18/2018 11:13 PM, Roger Pau Monné wrote:
> On Tue, Dec 18, 2018 at 07:31:59PM +0800, Dongli Zhang wrote:
>> Hi Roger,
>>
>> On 12/18/2018 05:33 PM, Roger Pau Monné wrote:
>>> On Tue, Dec 18, 2018 at 08:55:38AM +0800, Dongli Zhang wrote:
>>>> The x
ing() to read xenstore 'ring-page-order' only
once.
Signed-off-by: Dongli Zhang
---
Changed since v1:
* change the order of xenstore read in read_per_ring_refs
* use xenbus_read_unsigned() in connect_ring()
Changed since v2:
* simplify the condition check as "(err != 1 &
the same node is
removed from xenstore as the last xenstore operation during the domU
destroy. The corresponding watch callback would create or destroy the
per-domU mtwatch thread.
Signed-off-by: Dongli Zhang
---
tools/libxl/libxl_create.c | 12
tools/libxl/libxl_domain.c | 26 +
y default if
'xen_mtwatch' is not set in grub.
Signed-off-by: Dongli Zhang
---
Documentation/admin-guide/kernel-parameters.txt | 3 +
drivers/xen/xenbus/xenbus_probe.c | 39 ++-
drivers/xen/xenbus/xenbus_probe_backend.c | 55
dri
is one linux patch and one xen patch following this RFC to help
understand the idea:
[RFC PATCH linux 1/2] xenbus: introduce xenwatch multithreading to dom0 linux
kernel
[RFC PATCH xen 2/2] libxl: introduce xenwatch multithreading to xen toolstack
Below patch can help reproduce the issue on purpose:
https://github.com/finallyjustice/patchset/blob/master/xenwatch-stall-by-vif.patch
Please let me know your input on this RFC. Thank you very much!
Dongli Zhang
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hi Juergen,
On 04/07/2018 07:59 PM, Juergen Gross wrote:
> On 07/04/18 13:25, Dongli Zhang wrote:
>> This is to introduce "xenwatch multithreading" (or "multithreaded xenwatch",
>> abbreviated as 'mtwatch'). The implementation of xen mtwatch involves b
Hi Wei,
On 04/23/2018 10:09 PM, Wei Liu wrote:
> On Sat, Apr 07, 2018 at 07:25:53PM +0800, Dongli Zhang wrote:
>> About per-domU xenwatch thread create/destroy, a new type of xenstore node is
>> introduced: '/local/domain/0/mtwatch/'.
>>
>> Suppose the new
Hi Juergen,
On 04/24/2018 01:22 PM, Juergen Gross wrote:
> On 24/04/18 01:55, Dongli Zhang wrote:
>> Hi Wei,
>>
>> On 04/23/2018 10:09 PM, Wei Liu wrote:
>>> On Sat, Apr 07, 2018 at 07:25:53PM +0800, Dongli Zhang wrote:
>>>> About per-domU xenwatch thr
On 04/24/2018 02:03 PM, Juergen Gross wrote:
> On 24/04/18 07:52, Dongli Zhang wrote:
>> Hi Juergen,
>>
>> On 04/24/2018 01:22 PM, Juergen Gross wrote:
>>> On 24/04/18 01:55, Dongli Zhang wrote:
>>>> Hi Wei,
>>>>
>>>> On 04/23
lp me understand the objective of the below patch introduced
in Dec 2009?
https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=de7c9106c1a22c0fd759cefcecf2c428e5a76a00
Thank you very much for your help!
Dongli Zhang
___
Xen-devel mailing list
Xen-de
n = 352;
skb->tail = 98;
skb->end = 384;
dev->netdev_ops->ndo_start_xmit(skb, dev);
This patch stops processing sk_buff immediately if it is detected as
malformed, that is, pkt->frag_iter is NULL but there is still remaining
pkt->remaining_len.
Signed-off-by: Dongli Zhang
---
driver
dev->netdev_ops->ndo_start_xmit(skb, dev);
return 0;
}
static void __exit test_skb_exit(void)
{
}
MODULE_LICENSE("GPL");
module_init(test_skb_init);
module_exit(test_skb_exit);
Dongli Zhang
On 03/28/2018 07:42 AM, Dongli Zhang wrote:
> The "BUG_ON(!
n = 352;
skb->tail = 98;
skb->end = 384;
skb_shinfo(skb)->nr_frags = 0;
dev->netdev_ops->ndo_start_xmit(skb, dev);
This patch stops processing sk_buff immediately if it is detected as
malformed, that is, pkt->frag_iter is NULL but there is still remaining
pkt->remaining_le
Hi Eric,
On 03/29/2018 12:03 PM, Eric Dumazet wrote:
>
>
> On 03/28/2018 08:51 PM, Dongli Zhang wrote:
>> The "BUG_ON(!frag_iter)" in function xenvif_rx_next_chunk() is triggered if
>> the received sk_buff is malformed, that is, when the sk_buff has pattern
>&
The design session was primarily lead by Dongli Zhang, Paul Durant and Wei iu.
Problem to solve
xenwatch kernel thread is blocked in 'D' state if any xs_watch_event callback
function is stalled. As a result, dom0 is not able to create/destroy guest VMs
or hotplug dev
is replaced? Or would you please
help and let me know the chapter/page of AMD reference manual showing the
correct equation?
Thank you very much!
Dongli Zhang
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
do with AMD's doc, but only with maths: To split
> a multiplication x * y when considering x = xh + xl (high and low parts)
> and y = yh + yl you get x * y = xh * yh + xh * yl + xl * yh + xl * xl.
> Width constraints make it unnecessary to calculate the xh * yh part
> here. The original
On 05/29/2018 06:23 PM, Dongli Zhang wrote:
>
>
> On 05/29/2018 05:56 PM, Jan Beulich wrote:
>>>>> On 28.05.18 at 14:25, wrote:
>>> I am writing to ask about below patch as I am not familiar with AMD tsc
>>> scaling:
>>>
>>>
Isn't the page https://wiki.xen.org/wiki/Reporting_Bugs_against_Xen_Project
Dongli Zhang
- Original Message -
From: sc...@viviotech.net
To: xen-de...@lists.xen.org
Sent: Thursday, June 7, 2018 1:30:47 PM GMT +08:00 Beijing / Chongqing / Hong
Kong / Urumqi
Subject: [Xen-devel] X
page_list_add(page, &in_chunk_list);
652 put_gfn(d, gmfn + k);
653 }
654 }
Dongli Zhang
On 09/05/2018 02:16 AM, Joe Jin wrote:
> xen_swiotlb_{alloc,free}_coherent() actually allocate/free size by order
> but used the required size to check if address is phys
ub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=93065ac753e4443840a057bfef4be71ec766fde9
The issue is fixed by below commit in linux-next:
xen/gntdev: fix up blockable calls to mn_invl_range_start
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=7
The backtrace of the BUG is quite similar to a hang I encountered:
https://lists.xenproject.org/archives/html/xen-devel/2018-09/msg00454.html
No sure if they are related.
Dongli Zhang
On 09/10/2018 08:37 PM, Olaf Hering wrote:
> While preparing another variant of the fix for the bug
f existing thread.
Xenwatch multithreading might be enabled for more xen backend pv drivers in
the future.
Signed-off-by: Dongli Zhang
---
drivers/block/xen-blkback/xenbus.c | 3 ++-
drivers/net/xen-netback/xenbus.c | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers
This is the 5th patch of a (6-patch) patch set.
With this patch, watch event in relative path pattern
'backend//i/...' can be processed in per-domU xenwatch
thread.
Signed-off-by: Dongli Zhang
---
drivers/xen/xenbus/xenbus_probe.c | 2 +-
drivers/xen/xenbus/xenbus_probe_back
uctures to maintain the status of each per-domU
xenwatch thread. The status of each xenwatch thread (except the default
one) is maintained by a mtwatch domain.
The feature is available only on dom0.
Signed-off-by: Dongli Zhang
---
Documentation/admin-guide/kernel-parameters.txt | 3 ++
tml/xen-devel/2018-07/msg00017.html
http://www.donglizhang.org/xenwatch_multithreading.pdf
----
Dongli Zhang (6):
xenbus: prepare data structures and parameter for xenwatch multithreading
xenbus: implement the xenwatch multi
This is the 4th patch of a (6-patch) patch set.
With this patch, watch event in absolute path pattern
'/local/domain//device///state' can be processed in
per-domU xenwatch thread.
Signed-off-by: Dongli Zhang
---
drivers/xen/xenbus/xenbus_probe.c | 16
1 file c
xenwatch thread (mtwatch domain) available for the domid
obtained from get_domid() method.
3. The xenwatch thread is forked successfully by kthread_run() during
initialization and therefore its state should be MTWATCH_DOMAIN_UP.
Signed-off-by: Dongli Zhang
---
drivers/xen/xenbus/xenbus_xs.c | 53
when its owner_id field
is non-zero.
Signed-off-by: Dongli Zhang
---
drivers/xen/xenbus/xenbus_probe.c | 6 +
drivers/xen/xenbus/xenbus_xs.c| 273 ++
include/xen/xenbus.h | 3 +
3 files changed, 282 insertions(+)
diff --git a/driver
Hi Paul,
On 09/14/2018 04:11 PM, Paul Durrant wrote:
>> -Original Message-
>> From: Dongli Zhang [mailto:dongli.zh...@oracle.com]
>> Sent: 14 September 2018 08:34
>> To: xen-devel@lists.xenproject.org; linux-ker...@vger.kernel.org
>> Cc: boris.ostrov...@ora
Hi Juergen and Paul,
On 09/14/2018 04:32 PM, Juergen Gross wrote:
> On 14/09/18 09:34, Dongli Zhang wrote:
>> This is the 1st patch of a (6-patch) patch set.
>>
>> This patch set of six patches introduces xenwatch multithreading (or
>> multithreaded xenwatch, abbrev
On 09/14/2018 04:45 PM, Paul Durrant wrote:
>> -Original Message-
>> From: Dongli Zhang [mailto:dongli.zh...@oracle.com]
>> Sent: 14 September 2018 08:34
>> To: xen-devel@lists.xenproject.org; linux-ker...@vger.kernel.org
>> Cc: boris.ostrov...@oracle.com;
Hi Juergen,
On 09/14/2018 05:12 PM, Juergen Gross wrote:
> On 14/09/18 09:34, Dongli Zhang wrote:
>> This is the 5th patch of a (6-patch) patch set.
>>
>> With this patch, watch event in relative path pattern
>> 'backend//i/...' can be processed in
Hi Juergen,
On 09/14/2018 10:26 PM, Juergen Gross wrote:
> On 14/09/18 16:18, Dongli Zhang wrote:
>> Hi Juergen,
>>
>> On 09/14/2018 05:12 PM, Juergen Gross wrote:
>>> On 14/09/18 09:34, Dongli Zhang wrote:
>>>> This is the 5th patch of a (6-patch) p
Hi Juergen,
On 09/14/2018 05:12 PM, Juergen Gross wrote:
> On 14/09/18 09:34, Dongli Zhang wrote:
>> This is the 5th patch of a (6-patch) patch set.
>>
>> With this patch, watch event in relative path pattern
>> 'backend//i/...' can be processed in
Hi Boris,
On 09/17/2018 04:17 AM, Boris Ostrovsky wrote:
>
>
> On 9/14/18 3:34 AM, Dongli Zhang wrote:
>
>> +
>> +struct mtwatch_info {
>> +/*
>> + * The mtwatch_domain is put on both a hash table and a list.
>> + * domain_list is use
Hi Boris,
On 09/17/2018 05:20 AM, Boris Ostrovsky wrote:
>
>
> On 9/14/18 3:34 AM, Dongli Zhang wrote:
>>
>> +
>> +/* Running in the context of default xenwatch kthread. */
>> +void mtwatch_create_domain(domid_t domid)
>> +{
>> +struct mt
Hi Juergen,
On 09/14/2018 10:44 PM, Juergen Gross wrote:
> On 14/09/18 16:29, Dongli Zhang wrote:
>> Hi Juergen,
>>
>> On 09/14/2018 10:26 PM, Juergen Gross wrote:
>>> On 14/09/18 16:18, Dongli Zhang wrote:
>>>> Hi Juergen,
>>>>
>>>&
Hi Juergen,
On 09/19/2018 04:01 PM, Juergen Gross wrote:
> On 19/09/18 08:15, Dongli Zhang wrote:
>> Hi Juergen,
>>
>> On 09/14/2018 10:44 PM, Juergen Gross wrote:
>>> On 14/09/18 16:29, Dongli Zhang wrote:
>>>> Hi Juergen,
>>>>
>>>&
Hi Boris,
On 09/18/2018 03:08 AM, Boris Ostrovsky wrote:
> On 9/16/18 9:20 PM, Dongli Zhang wrote:
>> Hi Boris,
>>
>> On 09/17/2018 04:17 AM, Boris Ostrovsky wrote:
>>>
>>> On 9/14/18 3:34 AM, Dongli Zhang wrote:
>>>
>>>> +
>>>
Hi Boris,
On 09/26/2018 04:19 AM, Boris Ostrovsky wrote:
> On 9/25/18 1:14 AM, Dongli Zhang wrote:
>>
>> So far we have: (1) domain hash table, (2) domain list (where duplicate
>> entries
>> may exist) and (3) purge list.
>>
>> Can I assume you would like t
ll the
continuously dma pages be used up (sort of DoS attack)?
I am not sure if there is anything in xen hypervisor to prevent such behavior?
Dongli Zhang
>
> Is there any way to figure out based on an address if the exchange
> operation happened?
>
>> For #2, I'm was not
.g. if
> limitations of shim implementations change or xen 4.8 and 4.9 get PVHv2
> backported, it has to change again etc...)
>
> Nice to have: If you have everything checked in the right way, show a
> "code" (like A3-B1-C5-D6... or
u have everything checked in the right way, show a
> "code" (like A3-B1-C5-D6... or something more clever) that expresses the
> exact combination, so you can save it and put it back in later to reset
> the page to that state. And, you can share that code/sequence to explain
> your exact situation to someone else.
>
> Now we would have something that's easier to work with than hearing a
> user out with 14 questions on IRC and then trying to explain everything
> in words. Any change you make on the page refreshes the outcome immediately.
>
> So, who has a better idea than this, or knows why this is a bad idea and
> we shouldn't do this, or who wants to help creating it?
>
> Hans
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
>
Dongli Zhang
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
future, or this is deprecated?
I assume the following link is deprecated as 'vscsi' is not supported by xl
command in config file:
https://wiki.xenproject.org/wiki/Paravirtualized_SCSI
Thank you very much!
Dongli Zhang
___
Xen-devel ma
old
design, the scope of domid_t is shared by a cluster of server in new design?
That is, the domid should be unique in the cluster of all servers if we expect
non-cooperative migration always succeed?
Thank you very much!
Dongli Zhang
oe Jin
Cc: Boris Ostrovsky
Signed-off-by: Dongli Zhang
---
drivers/xen/manage.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
index cd046684e0d1..3190d0ecb52e 100644
--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -204,6 +204,13 @@ s
p_radix+0x6/0x60
The "while" is changed to "do while" so that wait_event() is used as a
barrier.
Signed-off-by: Dongli Zhang
---
drivers/xen/xenbus/xenbus_comms.c | 2 ++
drivers/xen/xenbus/xenbus_xs.c| 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --g
This patch adds the barrier to guarantee that req->err is always updated
before req->state.
Otherwise, read_reply() would not return ERR_PTR(req->err) but
req->body, when process_writes()->xb_write() is failed.
Signed-off-by: Dongli Zhang
---
drivers/xen/xenbus/xenbus_comms.c
On 3/3/20 1:40 AM, Julien Grall wrote:
> Hi,
>
> On 03/03/2020 01:58, Dongli Zhang wrote:
>> The req->body should be updated before req->state is updated and the
>> order should be guaranteed by a barrier.
>>
>> Otherwise, read_reply() might return
p_radix+0x6/0x60
The barrier() in test_reply() is changed to virt_rmb(). The "while" is
changed to "do while" so that test_reply() is used as a read memory
barrier.
Signed-off-by: Dongli Zhang
---
Changed since v1:
- change "barrier()" to "virt_rmb()&q
This patch adds the barrier to guarantee that req->err is always updated
before req->state.
Otherwise, read_reply() would not return ERR_PTR(req->err) but
req->body, when process_writes()->xb_write() is failed.
Signed-off-by: Dongli Zhang
---
drivers/xen/xenbus/xenbus_comms.c
On 3/3/20 11:37 AM, Julien Grall wrote:
> Hi,
>
> On 03/03/2020 18:47, Dongli Zhang wrote:
>> The req->body should be updated before req->state is updated and the
>> order should be guaranteed by a barrier.
>>
>> Otherwise, read_reply() might return
p_radix+0x6/0x60
The virt_rmb() is added in the 'true' path of test_reply(). The "while"
is changed to "do while" so that test_reply() is used as a read memory
barrier.
Signed-off-by: Dongli Zhang
---
Changed since v1:
- change "barrier()" to "virt_
This patch adds the barrier to guarantee that req->err is always updated
before req->state.
Otherwise, read_reply() would not return ERR_PTR(req->err) but
req->body, when process_writes()->xb_write() is failed.
Signed-off-by: Dongli Zhang
---
drivers/xen/xenbus/xenbus_comms.c
tead of reading 'ring-ref', xen-blkback will read the stale
> 'ring-ref0' left around by the previous frontend will try to map the wrong
> grant reference.
>
> This patch restores the original behaviour.
>
> Fixes: 4a8c31a1c6f5 ("xen/blkback: re
en/blkback: rework connect_ring() to avoid
> inconsistent xenstore 'ring-page-order' set by malicious blkfront")
> Signed-off-by: Paul Durrant
> ---
> Cc: Konrad Rzeszutek Wilk
> Cc: "Roger Pau Monné"
> Cc: Jens Axboe
> Cc: Dongli Zhang
>
> v2:
On 1/29/21 12:13 AM, Paul Durrant wrote:
>> -Original Message-
>> From: Jürgen Groß
>> Sent: 29 January 2021 07:35
>> To: Dongli Zhang ; Paul Durrant ; xen-
>> de...@lists.xenproject.org; linux-bl...@vger.kernel.org;
>> linux-ker...@vger.ker
This is just to define new enumerated type without functional change.
The 'SWIOTLB_LO' is to index legacy 32-bit swiotlb buffer, while the
'SWIOTLB_HI' is to index the 64-bit buffer.
This is to prepare to enable 64-bit swiotlb.
Cc: Joe Jin
Signed-off-by: Dongli Zhang
1 - 100 of 146 matches
Mail list logo
