flight 166128 qemu-mainline real [real]
flight 166139 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/166128/
http://logs.test-lab.xenproject.org/osstest/logs/166139/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 166125 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166125/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 166118
build-i386-prev
flight 166122 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166122/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-coresched-amd64-xl 14 guest-start fail REGR. vs. 165976
flight 166133 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166133/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e1e7306b54147e65cb7347b060e94f336d4a82d2
baseline version:
ovmf
flight 166132 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166132/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Fri, Nov 12, 2021 at 11:00:54PM +, Julien Grall wrote:
> On Fri, 12 Nov 2021 at 22:32, Elliott Mitchell wrote:
> > > My preference is to introduce a per-platform quirk (I believe Stefano was
> > > happy
> > > with this). The advantage is we could get ACPI support for your board
> > >
flight 166130 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166130/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 455b0347a7c55d3842e87b20259659a22f7e62a5
baseline version:
ovmf
On Fri, 12 Nov 2021 at 22:32, Elliott Mitchell wrote:
> > My preference is to introduce a per-platform quirk (I believe Stefano was
> > happy
> > with this). The advantage is we could get ACPI support for your board
> > hopefully
> > merged quicker.
>
> This could be workable as a temporary
On Fri, Nov 12, 2021 at 10:08:54PM +, Julien Grall wrote:
>
> On Fri, 12 Nov 2021 at 21:15, Elliott Mitchell wrote:
> > > > I had been left with the impression the DSDT parsing was going to be
> > > > needed for Domain 0 to access the framebuffer. This was found
> > > > unnecessary for
Hi Elliott,
On Fri, 12 Nov 2021 at 21:15, Elliott Mitchell wrote:
> > > I had been left with the impression the DSDT parsing was going to be
> > > needed for Domain 0 to access the framebuffer. This was found
> > > unnecessary for framebuffer access for Domain 0?
> >
> > I thought you were
From: Stefano Stabellini
In case of errors in xenbus_init (e.g. missing xen_store_gfn parameter),
we goto out_error but we forget to reset xen_store_domain_type to
XS_UNKNOWN. As a consequence xenbus_probe_initcall and other initcalls
will still try to initialize xenstore resulting into a crash
On Fri, Nov 12, 2021 at 05:38:02PM +, Julien Grall wrote:
>
> On 12/11/2021 16:52, Elliott Mitchell wrote:
> > On Fri, Nov 12, 2021 at 04:02:36PM +, Julien Grall wrote:
> >>
> >> On 12/11/2021 15:44, Elliott Mitchell wrote:
> >>> Julien Grall and Stefano Stabellini had been proposing
On 10/21/21 11:15, Lucas De Marchi wrote:
Last user of PAGE_KERNEL_IO is the i915 driver. While removing it from
there as we seek to bring the driver to other architectures, Daniel
suggested that we could finish the cleanup and remove it altogether,
through the tip tree. So here I'm sending both
On 11/12/21 12:09 PM, Lucas De Marchi wrote:
> The intention was to merge this through the tip tree. Although now I'm
> not sure. Options:
>
> 1) take the first patch through the drm-intel tree and apply the
> second patch later
> 2) take everything through the drm tree
> 3)
flight 166131 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166131/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Fri, Nov 12, 2021 at 08:04:03PM +0100, Peter Zijlstra wrote:
On Thu, Oct 21, 2021 at 11:15:09AM -0700, Lucas De Marchi wrote:
Last user of PAGE_KERNEL_IO is the i915 driver. While removing it from
there as we seek to bring the driver to other architectures, Daniel
suggested that we could
On Fri, Nov 12, 2021 at 1:51 PM Andrew Cooper wrote:
>
> On 10/11/2021 09:19, Jane Malalane wrote:
> > Before, user would change turbo status but this had no effect: boolean
> > was set but policy wasn't reevaluated. Policy must be reevaluated so
> > that CPU frequency is chosen according to the
On Thu, Oct 21, 2021 at 11:15:09AM -0700, Lucas De Marchi wrote:
> Last user of PAGE_KERNEL_IO is the i915 driver. While removing it from
> there as we seek to bring the driver to other architectures, Daniel
> suggested that we could finish the cleanup and remove it altogether,
> through the tip
On 10/11/2021 09:19, Jane Malalane wrote:
> Before, user would change turbo status but this had no effect: boolean
> was set but policy wasn't reevaluated. Policy must be reevaluated so
> that CPU frequency is chosen according to the turbo status and the
> current governor.
>
> Therefore, add
Varios bits of cleanup uncovered while looking in to the Intel Turbo issues.
Andrew Cooper (3):
x86/cpufreq: Clean up powernow registration
x86/cpufreq: Rework APERF/MPERF handling
x86/cpufreq: Drop opencoded CPUID handling from powernow
tools/misc/xen-cpuid.c | 3 +-
powernow_register_driver() is currently written with a K type definition;
I'm surprised that compilers don't object to a mismatch with its declaration,
which is written in an ANSI-C compatible way.
Furthermore, its sole caller is cpufreq_driver_init() which is a pre-smp
initcall. There are no
Xen already collects CPUID.0x8007.edx by default, meaning that we can
refer to per-cpu data directly. This also avoids the need IPI the onlining
CPU to identify whether Core Performance Boost is available.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
Currently, each feature_detect() (called on CPU add) hook for both cpufreq
drivers duplicates cpu_has_aperfmperf in a per-cpu datastructure, and edits
cpufreq_driver.getavg to point at get_measured_perf().
As all parts of this are vendor-neutral, drop the function pointer and
duplicated boolean,
Hi,
On 12/11/2021 16:52, Elliott Mitchell wrote:
On Fri, Nov 12, 2021 at 04:02:36PM +, Julien Grall wrote:
Hi Elliott,
On 12/11/2021 15:44, Elliott Mitchell wrote:
On Fri, Nov 12, 2021 at 05:54:08AM +, Henry Wang wrote:
-Original Message-
From: Xen-devel On Behalf Of
On Fri, Nov 12, 2021 at 04:02:36PM +, Julien Grall wrote:
> Hi Elliott,
>
> On 12/11/2021 15:44, Elliott Mitchell wrote:
> > On Fri, Nov 12, 2021 at 05:54:08AM +, Henry Wang wrote:
> >>
> >>> -Original Message-
> >>> From: Xen-devel On Behalf Of
> >>> Elliott Mitchell
> >>>
> >>>
flight 166127 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166127/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
Hi Elliott,
On 12/11/2021 15:44, Elliott Mitchell wrote:
On Fri, Nov 12, 2021 at 05:54:08AM +, Henry Wang wrote:
-Original Message-
From: Xen-devel On Behalf Of
Elliott Mitchell
I've been busy with another part of this project, so I've lost track of
progress on ACPI/UEFI
flight 166121 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166121/
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-arm64-libvirt
On Fri, Nov 12, 2021 at 05:54:08AM +, Henry Wang wrote:
>
> > -Original Message-
> > From: Xen-devel On Behalf Of
> > Elliott Mitchell
> >
> > I've been busy with another part of this project, so I've lost track of
> > progress on ACPI/UEFI support on ARM.
> >
> > Last I'd read
On 12/11/2021 15:16, Roger Pau Monné wrote:
> On Fri, Nov 12, 2021 at 02:48:21PM +, Jane Malalane wrote:
>> Previously, we checked that we could map 40 pages with nothing
>> complaining. Now we're adding extra logic to check that those 40
>> frames are "correct".
>>
>> Suggested-by: Andrew
On Fri, Nov 12, 2021 at 02:48:21PM +, Jane Malalane wrote:
> Previously, we checked that we could map 40 pages with nothing
> complaining. Now we're adding extra logic to check that those 40
> frames are "correct".
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Jane Malalane
>
flight 166126 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166126/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 466ebdd2e0919c1538d03cd59833704bd5e1c028
baseline version:
ovmf
Previously, we checked that we could map 40 pages with nothing
complaining. Now we're adding extra logic to check that those 40
frames are "correct".
Suggested-by: Andrew Cooper
Signed-off-by: Jane Malalane
Release-Acked-by: Ian Jackson
---
CC: Ian Jackson
CC: Roger Pau Monné
CC: Wei Liu
On Fri, Nov 12, 2021 at 02:45:14PM +0100, Jan Beulich wrote:
> On 12.11.2021 14:42, Roger Pau Monné wrote:
> > On Fri, Nov 12, 2021 at 10:48:43AM +0100, Jan Beulich wrote:
> >> While domain_context_mapping() invokes domain_context_unmap() in a sub-
> >> case of handling DEV_TYPE_PCI when
On Thu, Nov 11, 2021 at 11:46:36AM -0800, Vikram Garhwal wrote:
> On Thu, Nov 11, 2021 at 04:54:25PM +, Anthony PERARD wrote:
> Hi Anthony,
> > On Mon, Nov 08, 2021 at 11:02:25PM -0800, Vikram Garhwal wrote:
> > > +SRCS-$(CONFIG_OVERLAY_DTB) += xc_overlay.c
> >
> > So, this patch seems to
On 18/10/2021 12:01, Jan Beulich wrote:
> On 18.10.2021 12:08, Jane Malalane wrote:
>
>> /*
>> * Failure here with E2BIG indicates Xen is missing the bugfix to map
>> * resources larger than 32 frames.
>> */
>> if ( !res )
>> -return fail("Fail: Map %d -
On 12.11.2021 14:42, Roger Pau Monné wrote:
> On Fri, Nov 12, 2021 at 10:48:43AM +0100, Jan Beulich wrote:
>> While domain_context_mapping() invokes domain_context_unmap() in a sub-
>> case of handling DEV_TYPE_PCI when encountering an error, thus avoiding
>> a leak, individual calls to
On Fri, Nov 12, 2021 at 10:48:43AM +0100, Jan Beulich wrote:
> While domain_context_mapping() invokes domain_context_unmap() in a sub-
> case of handling DEV_TYPE_PCI when encountering an error, thus avoiding
> a leak, individual calls to domain_context_mapping_one() aren't
> similarly covered.
On 12.11.2021 13:43, Ian Jackson wrote:
> Jan Beulich writes ("[PATCH RESEND 1/3][4.16] VT-d: per-domain IOMMU bitmap
> needs to have dynamic size"):
>> With no upper bound (anymore) on the number of IOMMUs, a fixed-size
>> 64-bit map may be insufficient (systems with 40 IOMMUs have already been
On 11/11/2021 14:04, Roger Pau Monné wrote:
> On Thu, Nov 11, 2021 at 10:26:29AM +0100, Jan Beulich wrote:
>> On 10.11.2021 19:17, Andrew Cooper wrote:
>>> On 10/11/2021 17:40, Roger Pau Monne wrote:
diff --git a/tools/libs/guest/xg_cpuid_x86.c
b/tools/libs/guest/xg_cpuid_x86.c
Jan Beulich writes ("[PATCH RESEND 0/3][4.16?] VT-d: misc (regression) fixes"):
> (re-sending upon Ian's request with his address adjusted, including
> Kevin's R-b at this occasion)
>
> 1: per-domain IOMMU bitmap needs to have dynamic size
...
> As to patch 1: Without the earlier change, systems
Jan Beulich writes ("[PATCH RESEND 1/3][4.16] VT-d: per-domain IOMMU bitmap
needs to have dynamic size"):
> With no upper bound (anymore) on the number of IOMMUs, a fixed-size
> 64-bit map may be insufficient (systems with 40 IOMMUs have already been
> observed).
>
> Fixes: 27713fa2aa21 ("VT-d:
On Fri, Nov 12, 2021 at 10:48:19AM +0100, Jan Beulich wrote:
> This logic will want invoking from elsewhere.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Might be worth to explicitly note this is a non functional change.
Thanks, Roger.
On Fri, Nov 12, 2021 at 10:47:59AM +0100, Jan Beulich wrote:
> Merely setting bit 0 in the bitmap is insufficient, as then Dom0 will
> still have DID 0 allocated to it, because of the zero-filling of
> domid_map[]. Set slot 0 to DOMID_INVALID to keep DID 0 from getting
> used.
>
> Fixes:
On Fri, Nov 12, 2021 at 01:07:33PM +0100, Jan Beulich wrote:
> On 12.11.2021 12:23, Roger Pau Monné wrote:
> > On Fri, Nov 12, 2021 at 10:47:59AM +0100, Jan Beulich wrote:
> >> Merely setting bit 0 in the bitmap is insufficient, as then Dom0 will
> >> still have DID 0 allocated to it, because of
On 12.11.2021 12:23, Roger Pau Monné wrote:
> On Fri, Nov 12, 2021 at 10:47:59AM +0100, Jan Beulich wrote:
>> Merely setting bit 0 in the bitmap is insufficient, as then Dom0 will
>> still have DID 0 allocated to it, because of the zero-filling of
>> domid_map[]. Set slot 0 to DOMID_INVALID to
This reverts commit 228ab9992ffb1d8f9d2475f2581e68b2913acb88.
Performance analysis has shown that dropping the domctl lock during
domain destruction greatly increases the contention in the heap_lock,
thus making parallel destruction of domains slower.
The following lockperf data shows the
flight 166119 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166119/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail like 166115
On 10/11/2021 11:48, Ian Jackson wrote:
[CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
unless you have verified the sender and know the content is safe.
Jane Malalane writes ("[PATCH] xen/cpufreq: Reset policy after
enabling/disabling turbo status"):
Before, user
On Fri, Nov 12, 2021 at 10:47:59AM +0100, Jan Beulich wrote:
> Merely setting bit 0 in the bitmap is insufficient, as then Dom0 will
> still have DID 0 allocated to it, because of the zero-filling of
> domid_map[]. Set slot 0 to DOMID_INVALID to keep DID 0 from getting
> used.
Shouldn't the whole
On 11.11.2021 18:57, Andrew Cooper wrote:
> Function pointers are expensive, and the raw parameter is a constant from all
> callers, meaning that it predicts very well with local branch history.
The code change is fine, but I'm having trouble with "all" here: Both
functions aren't even static, so
On 11.11.2021 18:57, Andrew Cooper wrote:
> There is no need for this to be an indirect jump at all. Execution always
> returns to a specific location, so use a direct jump instead.
>
> Use a named label for the jump. As both 1 and 2 have disappeared as labels,
> rename 3 to skip to better
The quarantine domain doesn't count as a DomU, as it won't itself
trigger any bad behavior. The workaround only needs enabling when an
actual DomU is about to gain control of a device. This then also means
enabling of the workaround can be deferred until immediately ahead of
the call to
domain_pgd_maddr() contains logic to adjust the root address to be put
in the context entry in case 4-level page tables aren't supported by an
IOMMU. This logic may not be bypassed when sharing page tables.
Fixes: 25ccd093425c ("iommu: remove the share_p2m operation")
Signed-off-by: Jan Beulich
With no upper bound (anymore) on the number of IOMMUs, a fixed-size
64-bit map may be insufficient (systems with 40 IOMMUs have already been
observed).
Fixes: 27713fa2aa21 ("VT-d: improve save/restore of registers across S3")
Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
---
(re-sending upon Ian's request with his address adjusted, including
Kevin's R-b at this occasion)
1: per-domain IOMMU bitmap needs to have dynamic size
2: fix reduced page table levels support when sharing tables
3: don't needlessly engage the untrusted-MSI workaround
As to 4.16 considerations:
flight 166123 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166123/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4c495e5e3d387b26e1f22d708ff707eee6898c17
baseline version:
ovmf
On 11.11.2021 18:57, Andrew Cooper wrote:
> There are exactly 3 callers of sort() in the hypervisor.
>
> Both arm callers pass in NULL for the swap function. While this might seem
> like an attractive option at first, it causes generic_swap() to be used which
> forced a byte-wise copy. Provide
On 11.11.2021 18:57, Andrew Cooper wrote:
> free_pirq_struct() has no external users, so shouldn't be exposed.
This has been the case from its very introduction. Which iirc was done
that way because its alloc counterpart is non-static. Not an objection,
just an observation.
> Making it
> static
On 11.11.2021 18:57, Andrew Cooper wrote:
> Retpolines are expensive, and all these do are select between the sync and
> nosync helpers. Pass a boolean instead, and use direct calls everywhere.
>
> Pause/unpause operations on behalf of dom0 are not fastpaths, so avoid
> exposing the
When an IOMMU implements the full 16 bits worth of DID in context
entries, there's no point going through a memory base translation table.
For IOMMUs not using Caching Mode we can simply use the domain IDs
verbatim, while for Caching Mode we need to avoid DID 0.
Signed-off-by: Jan Beulich
---
flight 166118 xen-unstable real [real]
flight 166124 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/166118/
http://logs.test-lab.xenproject.org/osstest/logs/166124/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
cap_super_page_val() and cap_super_offset() are unused (apart from the
latter using the former). I don't see how cap_super_offset() can be
useful in its current shape: cap_super_page_val()'s result is not an
lvalue and hence can't have its address taken. Plus a user would have
to check the
This is in preparation of adding another "translation" method. Take the
combination of the extra validation both previously open-coded have been
doing: Bounds check and bitmap check. But don't propagate the previous
pointless check of whether ->domid_map[] was actually allocated, as
failure there
- Correct struct field type.
- Use unsigned int when that suffices.
- Eliminate a (badly typed) local variable from
context_set_domain_id().
- Don't use -EFAULT inappropriately.
- Move set_bit() such that it won't be done redundantly.
- Constification.
- Reduce scope of some variables.
- Coding
While domain_context_mapping() invokes domain_context_unmap() in a sub-
case of handling DEV_TYPE_PCI when encountering an error, thus avoiding
a leak, individual calls to domain_context_mapping_one() aren't
similarly covered. Such a leak might persist until domain destruction.
Leverage that these
This logic will want invoking from elsewhere.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -157,6 +157,51 @@ static void cleanup_domid_map(struct dom
}
}
+static bool any_pdev_behind_iommu(const struct domain *d,
+
Merely setting bit 0 in the bitmap is insufficient, as then Dom0 will
still have DID 0 allocated to it, because of the zero-filling of
domid_map[]. Set slot 0 to DOMID_INVALID to keep DID 0 from getting
used.
Fixes: b9c20c78789f ("VT-d: per-iommu domain-id")
Signed-off-by: Jan Beulich
---
Two bug fixes, some cleanup, and a simplification for modern hardware.
1: properly reserve DID 0 for caching mode IOMMUs
2: split domid map cleanup check into a function
3: don't leak domid mapping on error path
4: tidy domid map handling
5: introduce helper to convert DID to domid_t
6: avoid
Hi Andrew,
On 11/11/2021 17:57, Andrew Cooper wrote:
There are exactly 3 callers of sort() in the hypervisor.
Both arm callers pass in NULL for the swap function. While this might seem
like an attractive option at first, it causes generic_swap() to be used which
forced a byte-wise copy.
~/works/oss/linux/scripts/bloat-o-meter xen-syms-old xen-syms
On 11/11/2021 17:57, Andrew Cooper wrote:
Retpolines are expensive, and all these do are select between the sync and
nosync helpers. Pass a boolean instead, and use direct calls everywhere.
To be honest, I much prefer to read the
71 matches
Mail list logo
