On 2/28/23 2:24 AM, Anthony PERARD wrote:
> On Tue, Feb 28, 2023 at 10:37:00AM +0100, Jan Beulich wrote:
>> On 28.02.2023 07:44, Joe Jin wrote:
>>> We encountered a vcpu-set issue on old xen, when I tried to confirm
>>> if xen upstream xen has the same issue I fin
On 2/28/23 12:49 AM, Andrew Cooper wrote:
> On 28/02/2023 6:44 am, Joe Jin wrote:
>> Hi,
>>
>> We encountered a vcpu-set issue on old xen, when I tried to confirm
>> if xen upstream xen has the same issue I find neither my upstream build
>> nor ubuntu 22.04 xen-
Hi,
We encountered a vcpu-set issue on old xen, when I tried to confirm
if xen upstream xen has the same issue I find neither my upstream build
nor ubuntu 22.04 xen-hypervisor-4.16 work.
I can add vcpus(8->16) to my guest but I can not reduce vcpu number:
root@ubuntu2204:~/vm# xl list
Name
On 4/28/20 10:25 AM, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 28, 2020 at 12:19:41PM +0200, Jürgen Groß wrote:
>> On 28.04.20 10:25, Peng Fan wrote:
>
> Adding Joe Jin.
>
> Joe, didn't you have some ideas on how this could be implemented?
>
>>>> Subje
us PIR won't be synced into IRR.
>
> Fix this by making sure PIR is always synced to IRR in
> hvm_vcpu_has_pending_irq regardless of what interrupts are pending.
>
> Reported-by: Joe Jin
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Juergen Gross
Patch works for
he logic for
> IPIing other pCPUs, there's no need to check v->processor since the
> IPI should be sent as long as the vCPU is not the current one and it's
> running.
>
> Reported-by: Joe Jin
> Signed-off-by: Roger Pau Monné
> ---
> Cc:
On 11/15/19 6:06 AM, Roger Pau Monné wrote:
> On Fri, Nov 15, 2019 at 05:23:51AM +, Tian, Kevin wrote:
>>> From: Roger Pau Monne [mailto:roger@citrix.com]
>>> Sent: Friday, November 8, 2019 9:34 PM
>>>
>>> When using posted interrupts and the guest migrates MSI from vCPUs Xen
>>> needs to
Ran same test and did not hit the issue.
Tested-by: Joe Jin
On 11/13/19 7:59 AM, Roger Pau Monne wrote:
> When using posted interrupts and the guest migrates MSI from vCPUs Xen
> needs to flush any pending PIRR vectors on the previous vCPU, or else
> those vectors could get wrongly
This patch synced PIRR with IRR when misx table updated, I ran same test
over 1.5 hours and did not reproduced it, without the patch, I could
reproduced within 10 minutes.
Tested-by: Joe Jin
Thanks,
Joe
On 11/8/19 5:34 AM, Roger Pau Monne wrote:
> When using posted interrupts and the gu
On 10/31/19 7:56 AM, Jan Beulich wrote:
> On 31.10.2019 15:52, Joe Jin wrote:
>> On 10/31/19 1:01 AM, Jan Beulich wrote:
>>> On 30.10.2019 19:01, Joe Jin wrote:
>>>> On 10/30/19 10:23 AM, Roger Pau Monné wrote:
>>>>> On Wed, Oct 30, 2019 at 09:38:16AM
On 10/31/19 1:01 AM, Jan Beulich wrote:
> On 30.10.2019 19:01, Joe Jin wrote:
>> On 10/30/19 10:23 AM, Roger Pau Monné wrote:
>>> On Wed, Oct 30, 2019 at 09:38:16AM -0700, Joe Jin wrote:
>>>> On 10/30/19 1:24 AM, Roger Pau Monné wrote:
>>>>> Can yo
On 10/30/19 10:23 AM, Roger Pau Monné wrote:
> On Wed, Oct 30, 2019 at 09:38:16AM -0700, Joe Jin wrote:
>> On 10/30/19 1:24 AM, Roger Pau Monné wrote:
>>> Can you try to add the following debug patch on top of the existing
>>> one and report the output that
On 10/30/19 1:24 AM, Roger Pau Monné wrote:
> Can you try to add the following debug patch on top of the existing
> one and report the output that you get on the Xen console?
Applied debug patch and run the test again, not of any log printed,
attached Xen log on serial console, seems
ted.
>
> Also store the vCPU ID in multi-destination mode when using posted
> interrupts and the interrupt is bound to a single vCPU in order for
> posted interrupts to be used.
>
> While there guard pi_update_irte with CONFIG_HVM since it's only used
> with HVM guests.
>
vCPU ID in multi-destination mode when using posted
>> interrupts and the interrupt is bound to a single vCPU in order for
>> posted interrupts to be used.
>>
>> While there guard pi_update_irte with CONFIG_HVM since it's only used
>> with HVM guests.
>>
>> R
On 10/1/19 9:01 AM, Roger Pau Monné wrote:
> Can you give a try to the patch above? I don't have the hardware to
> test any of this ATM, so your help would be appreciated.
I'd like to test this patch, but now there is hardware issue, once the
my test env is available I'll test it and update you
On 9/24/19 8:42 AM, Roger Pau Monné wrote:
> On Fri, Sep 13, 2019 at 09:50:34AM -0700, Joe Jin wrote:
>> On 9/13/19 3:33 AM, Roger Pau Monné wrote:
>>> On Thu, Sep 12, 2019 at 11:03:14AM -0700, Joe Jin wrote:
>>>> With below testcase, guest kernel reported "N
On 9/20/19 1:28 AM, Jan Beulich wrote:
> On 19.09.2019 23:38, Joe Jin wrote:
>> On 9/19/19 3:24 AM, Jan Beulich wrote:
>>> What's
>>> still missing is the further updating of pirq_dpci->gmsi.dest_vcpu_id
>>> (as explained before, still visible in
On 9/23/19 1:31 AM, Chao Gao wrote:
> On Wed, Sep 18, 2019 at 02:16:13PM -0700, Joe Jin wrote:
>> On 9/16/19 11:48 PM, Jan Beulich wrote:
>>> On 17.09.2019 00:20, Joe Jin wrote:
>>>> On 9/16/19 1:01 AM, Jan Beulich wrote:
>>>>> On 13.09.2019 18:38, J
On 9/19/19 3:24 AM, Jan Beulich wrote:
> On 18.09.2019 23:16, Joe Jin wrote:
>> On 9/16/19 11:48 PM, Jan Beulich wrote:
>>> On 17.09.2019 00:20, Joe Jin wrote:
>>>> On 9/16/19 1:01 AM, Jan Beulich wrote:
>>>>> On 13.09.2019 18:38, Joe Jin wrote:
On 9/16/19 11:48 PM, Jan Beulich wrote:
> On 17.09.2019 00:20, Joe Jin wrote:
>> On 9/16/19 1:01 AM, Jan Beulich wrote:
>>> On 13.09.2019 18:38, Joe Jin wrote:
>>>> On 9/13/19 12:14 AM, Jan Beulich wrote:
>>>>> On 12.09.2019 20:03, Joe Jin wro
On 9/16/19 1:01 AM, Jan Beulich wrote:
> On 13.09.2019 18:38, Joe Jin wrote:
>> Hi Jan,
>>
>> Thanks for your reply, see my reply in line please.
>>
>> On 9/13/19 12:14 AM, Jan Beulich wrote:
>>> On 12.09.2019 20:03, Joe Jin wrote:
>>>> With
On 9/13/19 3:33 AM, Roger Pau Monné wrote:
> On Thu, Sep 12, 2019 at 11:03:14AM -0700, Joe Jin wrote:
>> With below testcase, guest kernel reported "No irq handler for vector":
>> 1). Passthrough mlx ib VF to 2 pvhvm guests.
>> 2). Start rds-stress between
Hi Jan,
Thanks for your reply, see my reply in line please.
On 9/13/19 12:14 AM, Jan Beulich wrote:
> On 12.09.2019 20:03, Joe Jin wrote:
>> With below testcase, guest kernel reported "No irq handler for vector":
>> 1). Passthrough mlx ib VF to 2 pvhvm guests.
>>
rupt still
used old vector and dest cpu info, and when local IRQ enabled again,
interrupt been sent to wrong cpu and vector.
Looks sync PIR to IRR after MSI-X been updated is help for this issue.
BTW, I could not reproduced this issue if I disabled apicv.
Signed-off-by: Joe Jin
---
xen/drivers/
On 4/18/19 10:47 PM, Juergen Gross wrote:
> On 19/04/2019 00:31, Joe Jin wrote:
>> On 4/18/19 2:09 PM, Boris Ostrovsky wrote:
>>> On 4/18/19 3:36 AM, Juergen Gross wrote:
>>>> I'm currently investigating a problem related to swiotlb-xen. With a
>>>> specif
On 4/18/19 2:09 PM, Boris Ostrovsky wrote:
> On 4/18/19 3:36 AM, Juergen Gross wrote:
>> I'm currently investigating a problem related to swiotlb-xen. With a
>> specific driver a customer is capable to trigger a situation where a
>> MFN is mapped to multiple dom0 PFNs at the same time. There is no
On 10/30/18 7:21 AM, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of Joe Jin
>> Sent: 30 October 2018 14:13
>> To: Paul Durrant ; Boris Ostrovsky
>> ; Konrad Rzeszutek Wilk
&g
On 10/30/18 1:59 AM, Paul Durrant wrote:
>> On 10/25/18 11:56 AM, Joe Jin wrote:
>>> I just discussed this patch with Boris in private, his opinions(Boris,
>>> please correct me if any misunderstood) are:
>>>
>>> 1. With/without the check, both are incorre
On 10/25/18 11:56 AM, Joe Jin wrote:
> I just discussed this patch with Boris in private, his opinions(Boris,
> please correct me if any misunderstood) are:
>
> 1. With/without the check, both are incorrect, he thought we need to
>prevented unalloc'd free at here.
> 2. On
On 10/26/18 1:54 AM, Dongli Zhang wrote:
> If dom0 (or any domain) is happy, although it could try to exchange all its
> continuous dma pages back to xen hypervisor. From the perspective of each
> domain, they always would like to keep as much continuous dma page as
> possible.
>
> I am thinking
Hi Christoph,
On 10/26/18 12:48 AM, Christoph Helwig wrote:
> On Thu, Oct 25, 2018 at 11:56:02AM -0700, Joe Jin wrote:
>> I just discussed this patch with Boris in private, his opinions(Boris,
>> please correct me if any misunderstood) are:
>>
>> 1. With/without the ch
I did not realized range_straddles_page_boundary() only available
on xen-swiotlb, please ignore this patch.
Sorry for the bother.
Thanks,
Joe
On 10/25/18 5:16 PM, Joe Jin wrote:
> xen_destroy_contiguous_region() used to exchange physically
> contiguous memory with hypervisor, but i
xen_destroy_contiguous_region() used to exchange physically
contiguous memory with hypervisor, but it does not verify
that the memory is physically contiguous or no, passing
non-contiguous memory to xen_destroy_contiguous_region()
will lead kernel panic.
Signed-off-by: Joe Jin
Cc: Konrad
On 10/25/18 9:10 AM, Boris Ostrovsky wrote:
> On 10/25/18 10:23 AM, Joe Jin wrote:
>> On 10/25/18 4:45 AM, Boris Ostrovsky wrote:
>>> On 10/24/18 10:43 AM, Joe Jin wrote:
>>>> On 10/24/18 6:57 AM, Boris Ostrovsky wrote:
>>>>> On 10/24/18 9:02 AM, Konra
On 10/25/18 4:45 AM, Boris Ostrovsky wrote:
> On 10/24/18 10:43 AM, Joe Jin wrote:
>> On 10/24/18 6:57 AM, Boris Ostrovsky wrote:
>>> On 10/24/18 9:02 AM, Konrad Rzeszutek Wilk wrote:
>>>> On Tue, Oct 23, 2018 at 08:09:04PM -0700, Joe Jin wrote:
>>>>> C
ut.
Fixes: 4855c92dbb7 ("xen-swiotlb: fix the check condition for
xen_swiotlb_free_coherent"
Signed-off-by: Joe Jin
Reported-by: Boris Ostrovsky
Cc: Konrad Rzeszutek Wilk
Cc: Christoph Helwig
Cc: Dongli Zhang
Cc: John Sobecki
---
drivers/xen/swiotlb-xen.c | 4 ++--
1 file changed, 2 insert
On 10/24/18 6:02 AM, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 23, 2018 at 08:09:04PM -0700, Joe Jin wrote:
>> Commit 4855c92dbb7 "xen-swiotlb: fix the check condition for
>> xen_swiotlb_free_coherent" only fixed memory address check condition
>> on xen_swiot
On 10/24/18 6:57 AM, Boris Ostrovsky wrote:
> On 10/24/18 9:02 AM, Konrad Rzeszutek Wilk wrote:
>> On Tue, Oct 23, 2018 at 08:09:04PM -0700, Joe Jin wrote:
>>> Commit 4855c92dbb7 "xen-swiotlb: fix the check condition for
>>> xen_swiotlb_free_coherent" only
rnel panic.
The correct check condition should be memory is in DMA area and
physically contiguous.
Thank you Boris for pointing it out.
Signed-off-by: Joe Jin
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: Christoph Helwig
Cc: Dongli Zhang
Cc: John Sobecki
---
drivers/xen/swiotlb-xen.c |
On 10/19/18 6:43 AM, Konrad Rzeszutek Wilk wrote:
> I will fold in the stack trace in later tonight. Thanks!
Thank you very much!
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 10/18/18 4:52 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 16, 2018 at 03:21:16PM -0700, Joe Jin wrote:
>> xen_swiotlb_{alloc,free}_coherent() allocate/free memory by order,
>> but passed required size to range_straddles_page_boundary(),
>> when first pages ar
to
exchanged non-contiguous memory with Xen, then kernel panic.
Signed-off-by: Joe Jin
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: Christoph Helwig
Cc: Dongli Zhang
Cc: John Sobecki
---
drivers/xen/swiotlb-xen.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/xen/swiotlb-xen.c
Anybody would like to help review this patch?
Thanks,
Joe
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 physical cont
-by: Joe Jin
Cc: Konrad Rzeszutek Wilk
---
drivers/xen/swiotlb-xen.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index a6f9ba85dc4b..aa081f806728 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -303,6 +303,9
On 8/28/18 9:53 AM, Boris Ostrovsky wrote:
> On 08/28/2018 10:56 AM, Joe Jin wrote:
>> Export device state to sysfs to allow for easier get device state.
>>
>> Signed-off-by: Joe Jin
>> Cc: Boris Ostrovsky
>> Cc: Juergen Gross
>> Cc: Konrad Rzeszutek Wi
Export device state to sysfs to allow for easier get device state.
Signed-off-by: Joe Jin
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Konrad Rzeszutek Wilk
---
Documentation/ABI/stable/sysfs-bus-xen-backend | 9 +
drivers/xen/xenbus/xenbus_probe.c | 9 +
2 files
Export device state to sysfs to allow for easier get device state.
Signed-off-by: Joe Jin
Boris Ostrovsky
Juergen Gross
---
drivers/xen/xenbus/xenbus_probe.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/xen/xenbus/xenbus_probe.c
b/drivers/xen/xenbus/xenbus_probe.c
DMA heap.
This issue introduced by commit 6810df88dcfc2 "xen-swiotlb: When doing
coherent alloc/dealloc check before swizzling the MFNs.".
Signed-off-by: Joe Jin <joe@oracle.com>
Tested-by: John Sobecki <john.sobe...@oracle.com>
Reviewed-by: Rzeszutek Wilk <kon
On 5/17/18 12:10 PM, Greg KH wrote:
> On Thu, May 17, 2018 at 11:45:57AM -0700, Joe Jin wrote:
>> When run raidconfig from Dom0 we found that the Xen DMA heap is reduced,
>> but Dom Heap is increased by the same size. Tracing raidconfig we found
>> that the related io
DMA heap.
This issue introduced by commit 6810df88dcfc2 "xen-swiotlb: When doing
coherent alloc/dealloc check before swizzling the MFNs.".
Signed-off-by: Joe Jin <joe@oracle.com>
Tested-by: John Sobecki <john.sobe...@oracle.com>
Reviewed-by: Rzeszutek Wilk <kon
xenbaked.c -> dump_stats(), run_time = time(_time) - time(_time),
time() returns the value in seconds. If one cancels xenmon.py immediately
after started, run_time can be zero, and then xenbaked will hit divide by
zero fault.
Signed-off-by: Joe Jin <joe@oracle.com>
Reviewed-b
run_time on dump_stats() maybe zero if break xenmon.py immediately after it
started, then xenbaked hit divide by zero fault.
Signed-off-by: Joe Jin <joe@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
Cc: Wei Liu <wei.l...@citrix.com>
Cc: Ian C
53 matches
Mail list logo
