On 21.10.2021 11:58, Jan Beulich wrote:
> x2apic_bsp_setup() gets called ahead of iommu_setup(), and since x2APIC
> mode (physical vs clustered) depends on iommu_intremap, that variable
> needs to be set to off as soon as we know we can't / won't enable
> interrupt remapping, i.e. in particular
PAGE_KERNEL_IO is only defined for x86 and nowadays is the same as
PAGE_KERNEL. It was different for some time, OR'ing a `_PAGE_IOMAP` flag
in commit be43d72835ba ("x86: add _PAGE_IOMAP pte flag for IO
mappings"). This got removed in commit f955371ca9d3 ("x86: remove the
Xen-specific _PAGE_IOMAP
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 commits needed for that.
Lucas De Marchi
PAGE_KERNEL_IO is only defined for x86 and nowadays is the same as
PAGE_KERNEL. It was different for some time, OR'ing a `_PAGE_IOMAP` flag
in commit be43d72835ba ("x86: add _PAGE_IOMAP pte flag for IO
mappings"). This got removed in commit f955371ca9d3 ("x86: remove the
Xen-specific _PAGE_IOMAP
Hi,
> -Original Message-
> From: Julien Grall
> Sent: 2021年10月22日 1:16
> To: Hongda Deng ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Bertrand Marquis ; Wei Chen
> ; Ian Jackson
> Subject: Re: [for-4.16] Re: [PATCH v4] xen/arm: vgic: Ignore write access to
> ICPENDR*
flight 165712 xen-unstable real [real]
flight 165727 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165712/
http://logs.test-lab.xenproject.org/osstest/logs/165727/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 165721 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165721/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 165682
build-i386-xsm
From: Stefano Stabellini
It is the same as the existing ARM64 alpine 3.12 test-artifact. It is
used to export an Alpine rootfs for Dom0 used for testing.
Also add the exporting job to build.yaml so that the binaries can be
used during gitlab-ci runs.
Signed-off-by: Stefano Stabellini
---
From: Stefano Stabellini
Introduce a test based on QEMU to run Xen, Dom0 and start a DomU.
This is similar to the existing qemu-alpine-arm64.sh script and test.
The only differences are:
- use Debian's qemu-system-x86_64 (on ARM we build our own)
- use ipxe instead of u-boot and ImageBuilder
From: Stefano Stabellini
Build a 5.10 kernel to be used as Dom0 and DomU kernel for testing. This
is almost the same as the existing ARM64 recipe for Linux 5.9, the
only differences are:
- upgrade to latest 5.10.x stable
- force Xen modules to built-in (on ARM it was already done by defconfig)
Hi all,
This small patch series introduces a new QEMU-based test to Gitlab-CI.
It uses QEMU to emulate an x86_64 machine and run Xen, Dom0 and start a
DomU. It is very similar to the existing qemu-alpine-arm64-gcc test but
based on x86_64 rather than ARM64. I think it is important because all
the
flight 165719 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165719/
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
flight 165714 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165714/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2f286930a8280f4d817460020110009938f695b6
baseline version:
ovmf
Hi Vikram,
On 02/09/2021 07:06, Vikram Garhwal wrote:
Introduce domctl XEN_DOMCTL_addfpga to add a device-tree node through device
XEN_DOMCTL_* are hypercalls to manage a given domain. However, here you
are modifying the system.
This is similar to managing PCI devices, except here we are
flight 165703 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165703/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 165682
build-i386-xsm
flight 165700 linux-linus real [real]
flight 165715 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165700/
http://logs.test-lab.xenproject.org/osstest/logs/165715/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 21/10/2021 16:14, Julien Grall wrote:
On the previous version, we discussed to include the patch for 4.16. So
please tag it with for-4.16 and CC the Release Manager (Ian). This will
help him to track what's outstanding for the release.
On 21/10/2021 13:03, Hongda Deng wrote:
Currently,
flight 165701 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165701/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 305fd6bee0bfe1602163d1f8841954f84aa31b68
baseline version:
ovmf
On 15.10.2021 14:51, Juergen Gross wrote:
> The HVM hypercall handler is missing incrementing the per hypercall
> counters. Add that.
>
> The counters for PV are handled wrong, as they are not using
> perf_incra() with the number of the hypercall as index, but are
> incrementing the total number
Hello Hongda,
On the previous version, we discussed to include the patch for 4.16. So
please tag it with for-4.16 and CC the Release Manager (Ian). This will
help him to track what's outstanding for the release.
On 21/10/2021 13:03, Hongda Deng wrote:
Currently, Xen will return IO unhandled
On Fri, 15 Oct 2021 16:30:19 -0700, Luis Chamberlain wrote:
> Jens,
>
> I had last split up patches into 7 groups, but at this point now
> most changes are merged except a few more drivers. Instead of creating
> a new patch set for each of the 7 groups I'm creating 3 new groups of
> patches now:
It's been a while...
Daniel P. Berrangé writes:
> On Thu, Sep 09, 2021 at 01:20:16AM +0200, Philippe Mathieu-Daudé wrote:
>> Add the AccelClass::secure_policy_supported field to classify
>> safe (within security boundary) vs unsafe accelerators.
>>
>> Signed-off-by: Philippe Mathieu-Daudé
>>
On 15.10.2021 14:51, Juergen Gross wrote:
> Instead of using a function table use the generated switch statement
> macros for calling the appropriate hypercall handlers.
>
> This is beneficial to performance and avoids speculation issues.
>
> With calling the handlers using the correct number of
flight 165699 xen-unstable real [real]
flight 165710 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165699/
http://logs.test-lab.xenproject.org/osstest/logs/165710/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 21.10.2021 15:54, Anthony PERARD wrote:
> On Thu, Oct 21, 2021 at 01:24:27PM +0200, Jan Beulich wrote:
>> On 21.10.2021 13:03, Anthony PERARD wrote:
>>> On Mon, Oct 18, 2021 at 10:48:26AM +0200, Jan Beulich wrote:
On 15.10.2021 18:29, Anthony PERARD wrote:
> On Thu, Oct 14, 2021 at
On Mon, Oct 18, 2021 at 12:36:45PM +0200, Jan Beulich wrote:
> On 18.10.2021 12:28, Juergen Gross wrote:
> > On 18.10.21 11:51, Anthony PERARD wrote:
> >> On Mon, Oct 18, 2021 at 11:02:20AM +0200, Jan Beulich wrote:
> >>> Oh, now I'm curious as to the why here. I thought use of $(srctree)
> >>>
flight 165708 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165708/
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 Thu, Oct 21, 2021 at 01:24:27PM +0200, Jan Beulich wrote:
> On 21.10.2021 13:03, Anthony PERARD wrote:
> > On Mon, Oct 18, 2021 at 10:48:26AM +0200, Jan Beulich wrote:
> >> On 15.10.2021 18:29, Anthony PERARD wrote:
> >>> On Thu, Oct 14, 2021 at 10:51:44AM +0200, Jan Beulich wrote:
> On
On Thu, Oct 21, 2021 at 01:53:06PM +0200, Juergen Gross wrote:
> Marek,
>
> could you please test whether the attached patch is fixing your
> problem?
Sure. In fact, I made a similar patch in the meantime (attached) to
experiment with this a bit.
> BTW, I don't think this couldn't happen before
Hi Julien,
> On 21 Oct 2021, at 14:47, Julien Grall wrote:
>
>
>
> On 21/10/2021 14:15, Bertrand Marquis wrote:
>> Hi Julien,
>
> Hi Bertand,
>
>>> On 21 Oct 2021, at 10:28, Julien Grall wrote:
>>>
>>> Hi all,
>>>
>>> While going through the passthrough code. I noticed that we don't have
On 21/10/2021 14:15, Bertrand Marquis wrote:
Hi Julien,
Hi Bertand,
On 21 Oct 2021, at 10:28, Julien Grall wrote:
Hi all,
While going through the passthrough code. I noticed that we don't have a common
lock for the IOMMU between the PCI and DT code.
This is going to be an issue given
On Mon, Oct 18, 2021 at 10:21:28AM +0200, Jan Beulich wrote:
> On 24.08.2021 23:11, Andrew Cooper wrote:
> > On 18/08/2021 13:44, Andrew Cooper wrote:
> >> On 18/08/2021 12:30, Marek Marczykowski-Górecki wrote:
> >>> set_xcr0() and set_msr_xss() use cached value to avoid setting the
> >>> register
Hi Julien,
> On 21 Oct 2021, at 10:28, Julien Grall wrote:
>
> Hi all,
>
> While going through the passthrough code. I noticed that we don't have a
> common lock for the IOMMU between the PCI and DT code.
>
> This is going to be an issue given it would technically be possible to add a
> PCI
Commit 406f42fa0d3c ("net-next: When a bond have a massive amount
of VLANs...") introduced a rbtree for faster Ethernet address look
up. To maintain netdev->dev_addr in this tree we need to make all
the writes to it got through appropriate helpers.
Signed-off-by: Jakub Kicinski
---
CC:
Currently, Xen will return IO unhandled when guests write ICPENDR*
virtual registers, which will raise a data abort inside the guest.
For Linux guest, these virtual registers will not be accessed. But
for Zephyr, these virtual registers will be accessed during the
initialization. Zephyr guest will
Marek,
could you please test whether the attached patch is fixing your
problem?
BTW, I don't think this couldn't happen before kernel 5.15. I guess
my modification to use a kernel thread instead of a workqueue just
made the issue more probable.
I couldn't reproduce the crash you are seeing,
flight 165702 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165702/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On 21.10.2021 13:03, Anthony PERARD wrote:
> On Mon, Oct 18, 2021 at 10:48:26AM +0200, Jan Beulich wrote:
>> On 15.10.2021 18:29, Anthony PERARD wrote:
>>> On Thu, Oct 14, 2021 at 10:51:44AM +0200, Jan Beulich wrote:
On 24.08.2021 12:50, Anthony PERARD wrote:
> ---
On Mon, Oct 18, 2021 at 10:48:26AM +0200, Jan Beulich wrote:
> On 15.10.2021 18:29, Anthony PERARD wrote:
> > On Thu, Oct 14, 2021 at 10:51:44AM +0200, Jan Beulich wrote:
> >> On 24.08.2021 12:50, Anthony PERARD wrote:
> >>> --- a/xen/arch/arm/efi/Makefile
> >>> +++ b/xen/arch/arm/efi/Makefile
>
On 29.09.2021 15:13, Jan Beulich wrote:
> @@ -337,53 +336,65 @@ unsigned long __init dom0_compute_nr_pag
> avail -= d->max_vcpus - 1;
>
> /* Reserve memory for iommu_dom0_init() (rough estimate). */
> -if ( is_iommu_enabled(d) )
> +if ( is_iommu_enabled(d) &&
Thanks everyone, committed.
Ian.
The two are really meant to be independent settings; iov_supports_xt()
using || instead of && was simply wrong. The corrected check is,
however, redundant, just like the (correct) one in iov_detect(): These
hook functions are unreachable without acpi_ivrs_init() installing the
iommu_init_ops
The value it returns may change from true to false in case
iommu_enable_x2apic() fails and, as a side effect, clears iommu_intremap
(as can happen at least on AMD). Latch the return value from the first
invocation to replace the second one.
Signed-off-by: Jan Beulich
---
v2: New.
---
x2apic_bsp_setup() gets called ahead of iommu_setup(), and since x2APIC
mode (physical vs clustered) depends on iommu_intremap, that variable
needs to be set to off as soon as we know we can't / won't enable
interrupt remapping, i.e. in particular when parsing of the respective
ACPI tables failed.
In the course of reading the response to v1 (patch 1 only) I realized
that not only that patch needs further adjustment, but that also
further changes are needed (and there's likely yet more amiss).
1: x86/IOMMU: mark IOMMU / intremap not in use when ACPI tables are missing
2: x86/APIC: avoid
Hi Vikram,
On 02/09/2021 07:05, Vikram Garhwal wrote:
iommu_remove_dt_device function is introduced for supporting dynamic programming
i.e. adding and removing a node during runtime. When user removes the device
node, iommu_remove_dt_device() removes the device entry from smmu-masters too
using
Hi all,
While going through the passthrough code. I noticed that we don't have a
common lock for the IOMMU between the PCI and DT code.
This is going to be an issue given it would technically be possible to
add a PCI device while assigning a DT.
Rahul, Bertrand, Oleksandr, can you have a
Hi Vikram,
On 02/09/2021 07:05, Vikram Garhwal wrote:
Add dt_print_node_names() to print all nodes under a dt_device_node.
dt_print_node_names() takes a dt_device_node type input and prints the node name
of all the subsequent nodes. This is added for debugging purpose for device tree
overlays.
flight 165696 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165696/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 165616
test-amd64-amd64-xl-qemut-win7-amd64
On 10/20/21 16:03, Jason Andryuk wrote:
> Hi, Marc,
>
> Adding Juergen and Boris since this involves Xen.
>
> On Wed, Oct 20, 2021 at 8:51 AM Marc Zyngier wrote:
>> On Tue, 19 Oct 2021 22:48:19 +0100,
>> Josef Johansson wrote:
>>> From: Josef Johansson
>>>
>>>
>>> PCI/MSI: Re-add checks for
On 21.10.2021 09:21, Jan Beulich wrote:
> On 20.10.2021 22:01, Andrew Cooper wrote:
>> However, I don't think skipping parsing is a sensible move. Intremap is
>> utterly mandatory if during boot, we discover that our APIC ID is >254,
>> and iommu=no-intremap must be ignored in this case, or if
On 20.10.2021 22:01, Andrew Cooper wrote:
> On 20/10/2021 11:36, Jan Beulich wrote:
>> x2apic_bsp_setup() gets called ahead of iommu_setup(), and since x2APIC
>> mode (physical vs clustered) depends on iommu_intremap, that variable
>> needs to be set to off as soon as we know we can't / won't
> On 20 Oct 2021, at 15:45, Julien Grall wrote:
>
> From: Julien Grall
>
> Commit 939775cfd3 "handle dying domains in live update" was meant to
> handle gracefully dying domain. However, the @releaseDomain watch
> will end up to be sent as soon as we finished to restore Xenstored
> state.
>
On 20.10.21 16:45, Julien Grall wrote:
From: Julien Grall
Commit 939775cfd3 "handle dying domains in live update" was meant to
handle gracefully dying domain. However, the @releaseDomain watch
will end up to be sent as soon as we finished to restore Xenstored
state.
This may be before Xen
54 matches
Mail list logo
