flight 157867 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157867/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
flight 157854 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157854/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
flight 157852 qemu-mainline real [real]
flight 157861 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157852/
http://logs.test-lab.xenproject.org/osstest/logs/157861/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
Hi Dario,
Thank you for your reply
This issue is made much worse with:
https://github.com/QubesOS/qubes-vmm-xen/commit/c28754bdb458281a22e9a9779213c941531b6dff#diff-d98b01176d360f55f58c25d2dfbfadc115718806181ef40d1838d2efa6b2bea1
Reverting `xen: credit2: limit the max number of CPUs in a
On Dec 17, 2020, at 07:13, Jean-Philippe Ouellet wrote:
> On Wed, Dec 16, 2020 at 2:37 PM Christopher Clark
> wrote:
>> Hi all,
>>
>> I have written a page for the OpenXT wiki describing a proposal for
>> initial development towards the VirtIO-Argo transport driver, and the
>> related system
LBR, C-state MSRs should correspond to Ice Lake desktop according to
External Design Specification vol.2 for both models.
Ice Lake-X is known to expose IF_PSCHANGE_MC_NO in IA32_ARCH_CAPABILITIES MSR
(confirmed on Whitley SDP) which means the erratum is fixed in hardware for
that model and
flight 157856 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157856/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e2747dbb5a44f4a463ecc6dd0f7fd113ee57bd67
baseline version:
ovmf
On Wed, 23 Dec 2020, Andrew Cooper wrote:
> On 23/12/2020 19:45, Stefano Stabellini wrote:
> > On Wed, 23 Dec 2020, no-re...@patchew.org wrote:
> >> Hi,
> >>
> >> Patchew automatically ran gitlab-ci pipeline with this patch (series)
> >> applied, but the job failed. Maybe there's a bug in the
On 23/12/2020 19:45, Stefano Stabellini wrote:
> On Wed, 23 Dec 2020, no-re...@patchew.org wrote:
>> Hi,
>>
>> Patchew automatically ran gitlab-ci pipeline with this patch (series)
>> applied, but the job failed. Maybe there's a bug in the patches?
>>
>> You can find the link to the pipeline near
On Wed, 23 Dec 2020, no-re...@patchew.org wrote:
> Hi,
>
> Patchew automatically ran gitlab-ci pipeline with this patch (series)
> applied, but the job failed. Maybe there's a bug in the patches?
>
> You can find the link to the pipeline near the end of the report below:
>
> Type: series
>
On Sun, 2020-12-20 at 13:01 -0500, boris.ostrov...@oracle.com wrote:
> On 12/19/20 3:05 AM, David Woodhouse wrote:
> > On Fri, 2020-12-18 at 17:20 -0500, boris.ostrov...@oracle.com wrote:
> > > Are there other cases where this would be useful? If it's just to
> > > test a hypervisor under
flight 157847 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157847/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-arm64-libvirt-xsm 19 guest-start.2fail in 157837 pass in 157847
test-armhf-armhf-xl-rtds 18
Hi Jan,
On 23/12/2020 17:02, Jan Beulich wrote:
On 23.12.2020 17:54, Julien Grall wrote:
On 23/12/2020 16:46, Jan Beulich wrote:
On 23.12.2020 17:29, Julien Grall wrote:
On 23/12/2020 16:24, Jan Beulich wrote:
On 23.12.2020 17:16, Julien Grall wrote:
On 23/12/2020 16:11, Jan Beulich
On 22/12/2020 07:42, Jan Beulich wrote:
> On 21.12.2020 19:07, Andrew Cooper wrote:
>> On 21/12/2020 16:50, Jan Beulich wrote:
>>> Its expansion shouldn't be tied to NDEBUG - down the road we may want to
>>> allow enabling assertions independently of CONFIG_DEBUG.
>> I'm not sure I agree that
On 23.12.2020 17:54, Julien Grall wrote:
>
>
> On 23/12/2020 16:46, Jan Beulich wrote:
>> On 23.12.2020 17:29, Julien Grall wrote:
>>> On 23/12/2020 16:24, Jan Beulich wrote:
On 23.12.2020 17:16, Julien Grall wrote:
> On 23/12/2020 16:11, Jan Beulich wrote:
>> On 23.12.2020 16:16,
On 23/12/2020 16:59, Jan Beulich wrote:
> On 23.12.2020 17:53, Andrew Cooper wrote:
>> On 23/12/2020 16:05, Jan Beulich wrote:
>>> Its expansion shouldn't be tied to NDEBUG - down the road we may want to
>>> allow enabling assertions independently of CONFIG_DEBUG. Replace the few
>>> uses by a new
On 23.12.2020 17:53, Andrew Cooper wrote:
> On 23/12/2020 16:05, Jan Beulich wrote:
>> Its expansion shouldn't be tied to NDEBUG - down the road we may want to
>> allow enabling assertions independently of CONFIG_DEBUG. Replace the few
>> uses by a new xen_build_info() helper, subsuming
check if a GNU date that supports the '-u -d @...' options and syntax or
a BSD date are available. If so, use the appropriate options for the
date command to produce a custom date if SOURCE_DATE_EPOCH is defined.
If SOURCE_DATE_EPOCH is not defined or no suitable date command was
found, use the
On 23/12/2020 16:46, Jan Beulich wrote:
On 23.12.2020 17:29, Julien Grall wrote:
On 23/12/2020 16:24, Jan Beulich wrote:
On 23.12.2020 17:16, Julien Grall wrote:
On 23/12/2020 16:11, Jan Beulich wrote:
On 23.12.2020 16:16, Julien Grall wrote:
On 23/12/2020 15:00, Jan Beulich wrote:
On
On 23/12/2020 16:05, Jan Beulich wrote:
> Its expansion shouldn't be tied to NDEBUG - down the road we may want to
> allow enabling assertions independently of CONFIG_DEBUG. Replace the few
> uses by a new xen_build_info() helper, subsuming gcov_string at the same
> time (while replacing the stale
On 23.12.2020 17:29, Julien Grall wrote:
> On 23/12/2020 16:24, Jan Beulich wrote:
>> On 23.12.2020 17:16, Julien Grall wrote:
>>> On 23/12/2020 16:11, Jan Beulich wrote:
On 23.12.2020 16:16, Julien Grall wrote:
> On 23/12/2020 15:00, Jan Beulich wrote:
>> On 23.12.2020 15:56, Julien
On 23.12.2020 17:34, Andrew Cooper wrote:
> --- /dev/null
> +++ b/tools/misc/xen-fault-ttl.c
> @@ -0,0 +1,56 @@
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +int main(int argc, char **argv)
> +{
> +int rc;
> +xc_interface *xch = xc_interface_open(NULL, NULL,
On 23.12.2020 17:19, Julien Grall wrote:
> On 23/12/2020 16:15, Jan Beulich wrote:
>> On 23.12.2020 17:07, Julien Grall wrote:
>>> I think I prefer the small race introduced (the pages will still be
>>> freed) over this solution.
>>
>> The "will still be freed" is because of the 2nd round of
This was not the christmas hacking project that I was planning to do, but it
has had some exciting results.
After some discussion on an earlier thread, Tamas has successfully got fuzzing
of Xen working via kfx, and this series is a prototype for providing better
testing infrastructure.
And to
This causes memory allocations to be tied to domain in question.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Tamas K Lengyel
RFC: Likely more to convert. This is just a minimal
To inject a simulated resource failure, for testing purposes.
Given a specific set of hypercall parameters, the failure is in a repeatable
position, for the currently booted Xen. The exact position of failures is
highly dependent on the build of Xen, and hardware support.
Signed-off-by: Andrew
Wrappers for xmalloc() and friends, which track allocations tied to a specific
domain.
Check for any leaked memory at domain destruction time.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC:
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Tamas K Lengyel
RFC: This wants expanding to a few more "default" configurations, and then
some thought needs putting torwards automating it.
On 23/12/2020 16:24, Jan Beulich wrote:
On 23.12.2020 17:16, Julien Grall wrote:
On 23/12/2020 16:11, Jan Beulich wrote:
On 23.12.2020 16:16, Julien Grall wrote:
On 23/12/2020 15:00, Jan Beulich wrote:
On 23.12.2020 15:56, Julien Grall wrote:
On 23/12/2020 14:12, Jan Beulich wrote:
On
On 23.12.2020 17:16, Julien Grall wrote:
> On 23/12/2020 16:11, Jan Beulich wrote:
>> On 23.12.2020 16:16, Julien Grall wrote:
>>> On 23/12/2020 15:00, Jan Beulich wrote:
On 23.12.2020 15:56, Julien Grall wrote:
> On 23/12/2020 14:12, Jan Beulich wrote:
>> On 22.12.2020 16:43, Julien
On 23/12/2020 16:15, Jan Beulich wrote:
On 23.12.2020 17:07, Julien Grall wrote:
On 23/12/2020 14:34, Jan Beulich wrote:
On 22.12.2020 16:43, Julien Grall wrote:
From: Julien Grall
The new IOMMU page-tables allocator will release the pages when
relinquish the domain resources. However,
Hi,
On 23/12/2020 16:11, Jan Beulich wrote:
On 23.12.2020 16:16, Julien Grall wrote:
On 23/12/2020 15:00, Jan Beulich wrote:
On 23.12.2020 15:56, Julien Grall wrote:
On 23/12/2020 14:12, Jan Beulich wrote:
On 22.12.2020 16:43, Julien Grall wrote:
This is an RFC because it would break AMD
On 23.12.2020 17:07, Julien Grall wrote:
> On 23/12/2020 14:34, Jan Beulich wrote:
>> On 22.12.2020 16:43, Julien Grall wrote:
>>> From: Julien Grall
>>>
>>> The new IOMMU page-tables allocator will release the pages when
>>> relinquish the domain resources. However, this is not sufficient in two
On 23.12.2020 16:16, Julien Grall wrote:
> On 23/12/2020 15:00, Jan Beulich wrote:
>> On 23.12.2020 15:56, Julien Grall wrote:
>>> On 23/12/2020 14:12, Jan Beulich wrote:
On 22.12.2020 16:43, Julien Grall wrote:
> This is an RFC because it would break AMD IOMMU driver. One option would
On Montag, 21. Dezember 2020 10:01:14 CET Jan Beulich wrote:
> On 18.12.2020 21:42, Maximilian Engelhardt wrote:
> > --- a/docs/Makefile
> > +++ b/docs/Makefile
> > @@ -3,7 +3,13 @@ include $(XEN_ROOT)/Config.mk
> >
> > -include $(XEN_ROOT)/config/Docs.mk
> >
> > VERSION:= $(shell
On 23/12/2020 14:34, Jan Beulich wrote:
On 22.12.2020 16:43, Julien Grall wrote:
From: Julien Grall
The new IOMMU page-tables allocator will release the pages when
relinquish the domain resources. However, this is not sufficient in two
cases:
1) domain_relinquish_resources() is not
Its expansion shouldn't be tied to NDEBUG - down the road we may want to
allow enabling assertions independently of CONFIG_DEBUG. Replace the few
uses by a new xen_build_info() helper, subsuming gcov_string at the same
time (while replacing the stale CONFIG_GCOV used there) and also adding
On Wed, 2020-12-23 at 10:59 +0100, Jan Beulich wrote:
> On 23.12.2020 00:04, Dylanger Daly wrote:
> > I think I've narrowed down what could be the issue.
> >
> > I think disabling SMT on any AMD Zen 2 CPU is breaking Xen's
> > Credit2 scheduler, I can only test on AMD Ryzen 4000 based Mobile
> >
Hi Jan,
On 23/12/2020 15:00, Jan Beulich wrote:
On 23.12.2020 15:56, Julien Grall wrote:
On 23/12/2020 14:12, Jan Beulich wrote:
On 22.12.2020 16:43, Julien Grall wrote:
This is an RFC because it would break AMD IOMMU driver. One option would
be to move the call to the teardown callback
On Wed, Dec 23, 2020 at 9:44 AM Julien Grall wrote:
>
>
>
> On 23/12/2020 13:41, Jan Beulich wrote:
> > On 23.12.2020 14:33, Julien Grall wrote:
> >> On 23/12/2020 13:12, Jan Beulich wrote:
> >>> From the input by both of you I still can't
> >>> conclude whether this patch should remain as is in
Hi,
Interesting situation (so to speak... :-O)
On Thu, 2020-10-15 at 11:20 +0200, Jan Beulich wrote:
> On 15.10.2020 11:14, Dylanger Daly wrote:
> > Indeed this is for dom0, I only recently tried limiting a domU to 1
> > core and observed absolutely no softlocks, UI animations are smooth
> > as
This array can be large when many grant frames are permitted; avoid
allocating it when it's not going to be used anyway, by doing this only
in gnttab_populate_status_frames().
Signed-off-by: Jan Beulich
---
v2: Defer allocation to when a domain actually switches to the v2 grant
API.
---
On 30.11.2020 14:02, Jan Beulich wrote:
> On 24.11.2020 12:04, Jan Beulich wrote:
>> On 23.11.2020 17:14, Andrew Cooper wrote:
>>> On 23/11/2020 16:07, Roger Pau Monné wrote:
On Mon, Nov 23, 2020 at 04:30:05PM +0100, Jan Beulich wrote:
> On 23.11.2020 16:24, Roger Pau Monné wrote:
>>
Hi Jan,
On 23/12/2020 14:56, Jan Beulich wrote:
On 23.12.2020 15:44, Julien Grall wrote:
On 23/12/2020 13:41, Jan Beulich wrote:
On 23.12.2020 14:33, Julien Grall wrote:
On 23/12/2020 13:12, Jan Beulich wrote:
From the input by both of you I still can't
conclude whether this patch should
On 23.12.2020 15:56, Julien Grall wrote:
> On 23/12/2020 14:12, Jan Beulich wrote:
>> On 22.12.2020 16:43, Julien Grall wrote:
>>> This is an RFC because it would break AMD IOMMU driver. One option would
>>> be to move the call to the teardown callback earlier on. Any opinions?
>>
>> We already
On 23.12.2020 15:51, Julien Grall wrote:
> On 23/12/2020 13:59, Jan Beulich wrote:
>> On 23.12.2020 14:50, Julien Grall wrote:
>>> On 23/12/2020 13:27, Jan Beulich wrote:
And finally "we assume" is in at least latent conflict with
->platform_ops getting set only after
Hi Jan,
On 23/12/2020 14:12, Jan Beulich wrote:
On 22.12.2020 16:43, Julien Grall wrote:
From: Julien Grall
The new per-domain IOMMU page-table allocator will now free the
page-tables when domain's resources are relinquished. However, the root
page-table (i.e. hd->arch.pg_maddr) will not be
On 23.12.2020 15:44, Julien Grall wrote:
> On 23/12/2020 13:41, Jan Beulich wrote:
>> On 23.12.2020 14:33, Julien Grall wrote:
>>> On 23/12/2020 13:12, Jan Beulich wrote:
From the input by both of you I still can't
conclude whether this patch should remain as is in v4, or revert
Hi Jan,
On 23/12/2020 13:59, Jan Beulich wrote:
On 23.12.2020 14:50, Julien Grall wrote:
On 23/12/2020 13:27, Jan Beulich wrote:
On 22.12.2020 16:43, Julien Grall wrote:
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -226,7 +226,15 @@ static void
On 23/12/2020 13:41, Jan Beulich wrote:
On 23.12.2020 14:33, Julien Grall wrote:
On 23/12/2020 13:12, Jan Beulich wrote:
From the input by both of you I still can't
conclude whether this patch should remain as is in v4, or revert
back to its v2 version. Please can we get this settled so I
On 22.12.2020 16:43, Julien Grall wrote:
> From: Julien Grall
>
> The new IOMMU page-tables allocator will release the pages when
> relinquish the domain resources. However, this is not sufficient in two
> cases:
> 1) domain_relinquish_resources() is not called when the domain
> creation
On 23.12.2020 15:01, Julien Grall wrote:
> Hi Jan,
>
> On 23/12/2020 13:48, Jan Beulich wrote:
>> On 22.12.2020 16:43, Julien Grall wrote:
>>> From: Julien Grall
>>>
>>> The pgtables.lock is protecting access to the page list pgtables.list.
>>> However, iommu_free_pgtables() will not held it. I
On 22.12.2020 16:43, Julien Grall wrote:
> From: Julien Grall
>
> The new per-domain IOMMU page-table allocator will now free the
> page-tables when domain's resources are relinquished. However, the root
> page-table (i.e. hd->arch.pg_maddr) will not be cleared.
>
> Xen may access the IOMMU
Hi Jan,
On 23/12/2020 13:48, Jan Beulich wrote:
On 22.12.2020 16:43, Julien Grall wrote:
From: Julien Grall
The pgtables.lock is protecting access to the page list pgtables.list.
However, iommu_free_pgtables() will not held it. I guess it was assumed
that page-tables cannot be allocated
On 23.12.2020 14:50, Julien Grall wrote:
> On 23/12/2020 13:27, Jan Beulich wrote:
>> On 22.12.2020 16:43, Julien Grall wrote:
>>> --- a/xen/drivers/passthrough/iommu.c
>>> +++ b/xen/drivers/passthrough/iommu.c
>>> @@ -226,7 +226,15 @@ static void iommu_teardown(struct domain *d)
>>>
>>> void
Hi Jan,
On 23/12/2020 13:27, Jan Beulich wrote:
On 22.12.2020 16:43, Julien Grall wrote:
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -226,7 +226,15 @@ static void iommu_teardown(struct domain *d)
void iommu_domain_destroy(struct domain *d)
{
-if (
On 22.12.2020 16:43, Julien Grall wrote:
> From: Julien Grall
>
> The pgtables.lock is protecting access to the page list pgtables.list.
> However, iommu_free_pgtables() will not held it. I guess it was assumed
> that page-tables cannot be allocated while the domain is dying.
>
> Unfortunately,
flight 157848 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157848/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d15d0d3d8aee1c7d5dab7b636601370061b32612
baseline version:
ovmf
On 23.12.2020 14:33, Julien Grall wrote:
> On 23/12/2020 13:12, Jan Beulich wrote:
>> From the input by both of you I still can't
>> conclude whether this patch should remain as is in v4, or revert
>> back to its v2 version. Please can we get this settled so I can get
>> v4 out?
>
> I haven't had
On 23.12.2020 14:19, Julien Grall wrote:
> On 23/12/2020 12:57, Jan Beulich wrote:
>> On 23.12.2020 12:22, Julien Grall wrote:
1) Neither evtchn_status() nor domain_dump_evtchn_info() appear to
have a real need to acquire the per-domain lock. They could as well
acquire the
On 23/12/2020 13:12, Jan Beulich wrote:
On 07.12.2020 18:35, Tamas K Lengyel wrote:
On Mon, Dec 7, 2020 at 12:30 PM Julien Grall wrote:
Hi Jan,
On 07/12/2020 15:28, Jan Beulich wrote:
On 04.12.2020 20:15, Tamas K Lengyel wrote:
On Fri, Dec 4, 2020 at 10:29 AM Julien Grall wrote:
On
On 22.12.2020 16:43, Julien Grall wrote:
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -226,7 +226,15 @@ static void iommu_teardown(struct domain *d)
>
> void iommu_domain_destroy(struct domain *d)
> {
> -if ( !is_iommu_enabled(d) )
> +struct
On 23/12/2020 12:57, Jan Beulich wrote:
On 23.12.2020 12:22, Julien Grall wrote:
1) Neither evtchn_status() nor domain_dump_evtchn_info() appear to
have a real need to acquire the per-domain lock. They could as well
acquire the per-channel ones. (In the latter case this will then
also allow
On 07.12.2020 18:35, Tamas K Lengyel wrote:
> On Mon, Dec 7, 2020 at 12:30 PM Julien Grall wrote:
>>
>> Hi Jan,
>>
>> On 07/12/2020 15:28, Jan Beulich wrote:
>>> On 04.12.2020 20:15, Tamas K Lengyel wrote:
On Fri, Dec 4, 2020 at 10:29 AM Julien Grall wrote:
> On 04/12/2020 15:21, Tamas
On 23.12.2020 12:22, Julien Grall wrote:
> Hi Jan,
>
> On 22/12/2020 09:46, Jan Beulich wrote:
>> On 21.12.2020 18:45, Julien Grall wrote:
>>> On 14/12/2020 09:40, Jan Beulich wrote:
On 11.12.2020 11:57, Julien Grall wrote:
> On 11/12/2020 10:32, Jan Beulich wrote:
>> On 09.12.2020
flight 157842 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157842/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
Hi Juergen,
On 15/12/2020 10:20, Jürgen Groß wrote:
On 15.12.20 08:27, Jürgen Groß wrote:
On 14.12.20 22:25, Julien Grall wrote:
Hi Juergen,
When testing Linux 5.10 dom0, I could reliably hit the following
warning with using event 2L ABI:
[ 589.591737] Interrupt for port 34, but
Hi Jan,
On 22/12/2020 09:46, Jan Beulich wrote:
On 21.12.2020 18:45, Julien Grall wrote:
On 14/12/2020 09:40, Jan Beulich wrote:
On 11.12.2020 11:57, Julien Grall wrote:
On 11/12/2020 10:32, Jan Beulich wrote:
On 09.12.2020 12:54, Julien Grall wrote:
On 23/11/2020 13:29, Jan Beulich wrote:
flight 157844 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157844/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
flight 157838 qemu-mainline real [real]
flight 157851 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157838/
http://logs.test-lab.xenproject.org/osstest/logs/157851/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
On 22.12.2020 18:05, Andrew Cooper wrote:
> On 22/12/2020 16:49, Jan Beulich wrote:
>> First and foremost do away with the use of plain int for sizes or size-
>> derived values. Use size_t, despite this requiring some adjustment to
>> the logic. Also replace u32 by uint32_t.
>>
>> While not
flight 157850 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157850/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 98d4d6d8a6329ea3a8dcf8aab65acdd70c6397fc
baseline version:
xen
On 23.12.2020 00:04, Dylanger Daly wrote:
> I think I've narrowed down what could be the issue.
>
> I think disabling SMT on any AMD Zen 2 CPU is breaking Xen's Credit2
> scheduler, I can only test on AMD Ryzen 4000 based Mobile CPUs, but I think
> this is what is causing issues with
73 matches
Mail list logo
