On 11.07.20 00:34, Stefano Stabellini wrote:
Hi all,
This series is a collection of fixes to get Linux running on the RPi4 as
dom0. Conceptually there are only two significant changes:
- make sure not to call virt_to_page on vmalloc virt addresses (patch
#1)
- use phys_to_dma and
On 11.07.20 00:34, Stefano Stabellini wrote:
From: Stefano Stabellini
xen_dma_sync_for_cpu, xen_dma_sync_for_device, xen_arch_need_swiotlb are
getting called passing dma addresses. On some platforms dma addresses
could be different from physical addresses. Before doing any operations
on these
On 11.07.20 00:34, Stefano Stabellini wrote:
From: Stefano Stabellini
XEN_PFN_PHYS is only used in one place in swiotlb-xen making things more
complex than need to be.
Remove the definition of XEN_PFN_PHYS and open code the cast in the one
place where it is needed.
Signed-off-by: Stefano
On 11.07.20 00:34, Stefano Stabellini wrote:
From: Stefano Stabellini
With some devices physical addresses are different than dma addresses.
To be able to deal with these cases, we need to call phys_to_dma on
physical addresses (including machine addresses in Xen terminology)
before returning
flight 152411 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152411/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail REGR. vs. 151065
> -Original Message-
> From: Jan Beulich
> Sent: 03 August 2020 16:59
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
>
> Subject: RE: [EXTERNAL] [PATCH v3 02/11] x86/iommu: add common page-table
> allocator
>
>
On Mon, 3 Aug 2020 at 17:53, Anthony PERARD wrote:
>
> xen patches
>
> bug fix
>
>
> Philippe Mathieu-Daudé (1):
> accel/xen: Fix xen_enabled() behavior on
From: Oleksandr Tyshchenko
Without "dma-coherent" property present in virtio-mmio device node,
guest assumes it is non-coherent and making non-cacheable accesses
to the vring when the DMA API is used for vring operations.
But virtio-mmio device which runs at the host size is making cacheable
From: Oleksandr Tyshchenko
When two or more VirtIO devices are passed to DomU the
following message is observed:
OF: Duplicate name in base, renamed to "virtio#1"
Signed-off-by: Oleksandr Tyshchenko
---
tools/libxl/libxl_arm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff
From: Oleksandr Tyshchenko
This patch adds basic support for configuring and assisting virtio-disk
backend (emualator) which is intended to run out of Qemu and could be run
in any domain.
Xenstore was chosen as a communication interface for the emulator running
in non-toolstack domain to be
From: Oleksandr Tyshchenko
As a lot of x86 code can be re-used on Arm later on, this patch
splits IOREQ support into common and arch specific parts.
This support is going to be used on Arm to be able run device
emulator outside of Xen hypervisor.
Please note, this is a split/cleanup of
From: Oleksandr Tyshchenko
This patch makes possible to forward Guest MMIO accesses
to a device emulator on Arm and enables that support for
Arm64.
Also update XSM code a bit to let DM op be used on Arm.
New arch DM op will be introduced in the follow-up patch.
Please note, at the moment build
From: Oleksandr Tyshchenko
This patch makes possible to use device passthrough again.
Signed-off-by: Oleksandr Tyshchenko
---
tools/libxl/libxl_arm.c | 33 +++--
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/tools/libxl/libxl_arm.c
From: Oleksandr Tyshchenko
This patch adds ability to the device emulator to notify otherend
(some entity running in the guest) using a SPI and implements Arm
specific bits for it. Proposed interface allows emulator to set
the logical level of a one of a domain's IRQ lines.
Please note, this is
From: Oleksandr Tyshchenko
As a lot of x86 code can be re-used on Arm later on, this patch
splits devicemodel support into common and arch specific parts.
This support is going to be used on Arm to be able run device
emulator outside of Xen hypervisor.
Please note, this is a split/cleanup of
From: Oleksandr Tyshchenko
Trying to run emulator in driver domain I ran into various issues
mostly policy-related. So this patch tries to resolve all them
plobably in a hackish way. I would like to get feedback how
to implement them properly as having an emulator in driver domain
is a
From: Oleksandr Tyshchenko
Borrow x86's logic to invalidate qemu mapcache.
TODO: Move send_invalidate_req() to common code (ioreq.c?).
Signed-off-by: Oleksandr Tyshchenko
---
xen/arch/arm/ioreq.c| 14 ++
xen/arch/arm/traps.c| 6 ++
xen/common/memory.c
From: Oleksandr Tyshchenko
As x86 implementation of XENMEM_resource_ioreq_server can be
re-used on Arm later on, this patch makes it common and removes
arch_acquire_resource as unneeded.
This support is going to be used on Arm to be able run device
emulator outside of Xen hypervisor.
Please
From: Oleksandr Tyshchenko
Hello all.
The purpose of this patch series is to add IOREQ/DM support to Xen on Arm.
You can find an initial discussion at [1]. Xen on Arm requires some
implementation
to forward guest MMIO access to a device model in order to implement virtio-mmio
backend or even
From: Oleksandr Tyshchenko
This patch creates specific device node in the Guest device-tree
with allocated MMIO range and SPI interrupt if specific 'virtio'
property is present in domain config.
Please note, this patch breaks device passthrough use-case which
will be fixed in one of the
flight 152428 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152428/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
flight 152398 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152398/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 152332
From: Philippe Mathieu-Daudé
CONFIG_XEN is generated by configure and stored in "config-target.h",
which is (obviously) only include for target-specific objects.
This is a problem for target-agnostic objects as CONFIG_XEN is never
defined and xen_enabled() is always inlined as 'false'.
Fix by
-dm.git
tags/pull-xen-20200803
for you to fetch changes up to b3fcc98f391e9a60a369d825333b852871cf67b0:
accel/xen: Fix xen_enabled() behavior on target-agnostic objects (2020-08-03
17:39:38 +0100)
xen patches
bug fix
On Mon, 3 Aug 2020 at 17:35, Anthony PERARD wrote:
>
> On Tue, Jul 28, 2020 at 12:09:25PM +0200, Philippe Mathieu-Daudé wrote:
> > CONFIG_XEN is generated by configure and stored in "config-target.h",
> > which is (obviously) only include for target-specific objects.
> > This is a problem for
On 03/08/2020 15:50, Jan Beulich wrote:
> IOW just legacy encoded ones. For 3dNow! just one example is used, as
> they're all similar in nature both encoding- and operand-wise.
>
> Adjust a slightly misleading (but not wrong) memcpy() invocation, as
> noticed while further cloning that code.
I
On 03/08/2020 15:47, Jan Beulich wrote:
> ... and a few fixes resulting from this work. This completes what
> was started for legacy encoded GPR insns in a rush before 4.14.
>
> There's one thing I'm still planning on top of both this and the
> EVEX-disp8 checking: For all encodings we produce via
On Tue, Jul 28, 2020 at 12:09:25PM +0200, Philippe Mathieu-Daudé wrote:
> CONFIG_XEN is generated by configure and stored in "config-target.h",
> which is (obviously) only include for target-specific objects.
> This is a problem for target-agnostic objects as CONFIG_XEN is never
> defined and
On 03.08.2020 14:29, Paul Durrant wrote:
> From: Paul Durrant
>
> This patch converts the AMD IOMMU code to use the new page table allocator
> function. This allows all the free-ing code to be removed (since it is now
> handled by the general x86 code) which reduces TLB and cache thrashing as
On 03.08.2020 14:29, Paul Durrant wrote:
> From: Paul Durrant
>
> The VT-d and AMD IOMMU both use the general x86 IOMMU page table allocator
> and ARM always shares page tables with CPU. Hence there is no need to retain
> the free_page_table() method or the tasklet which invokes it.
>
>
On 03.08.2020 14:29, Paul Durrant wrote:
> From: Paul Durrant
>
> This patch converts the VT-d code to use the new IOMMU page table allocator
> function. This allows all the free-ing code to be removed (since it is now
> handled by the general x86 code) which reduces TLB and cache thrashing as
On 03.08.2020 14:29, Paul Durrant wrote:
> From: Paul Durrant
>
> Instead of having separate page table allocation functions in VT-d and AMD
> IOMMU code, we could use a common allocation function in the general x86 code.
>
> This patch adds a new allocation function, iommu_alloc_pgtable(), for
On 03.08.2020 14:29, Paul Durrant wrote:
> From: Paul Durrant
>
> ... from those specific to VT-d or AMD IOMMU, and put the latter in a union.
>
> There is no functional change in this patch, although the initialization of
> the 'mapped_rmrrs' list occurs slightly later in iommu_domain_init()
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulator/predicates.c
@@ -1564,9 +1564,469 @@ static const struct {
{ xop_0a, ARRAY_SIZE(xop_0a), 4 },
};
-#undef Wn
#undef Ln
+static const struct evex {
+uint8_t opc[3];
+uint8_t
The leading 'v' ought to be omitted from the table entries.
Fixes: 7ff66809ccd5 ("x86emul: support AVX512_BF16 insns")
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -551,9 +551,9 @@ static const struct test avx512_4vnniw_5
These are prefetches, so should be treated just like other prefetches.
Fixes: ("x86emul: support AVX512PF insns")
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -12265,6 +12265,8 @@ x86_insn_is_mem_access(const struct
While the custom handling renders the "to_mem" field generally unused,
x86_insn_is_mem_write() still (indirectly) consumes that information,
and hence the table entries want to be correct.
Fixes: ("x86emul: support AVX512F scatter insns")
Signed-off-by: Jan Beulich
---
For this to be properly reported, the case labels need to move to a
different switch() block.
Fixes: 30e0bdf79828 ("x86emul: support AVX512{F,BW} down conversion moves")
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulator/predicates.c
@@ -1474,6 +1474,96 @@ static const struct {
{ vex_0f3a, ARRAY_SIZE(vex_0f3a) },
};
+static const struct xop {
+uint8_t opc[2];
+uint8_t w:2;
+uint8_t l:2;
+}
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulator/predicates.c
@@ -1034,6 +1034,449 @@ static const struct {
{ { 0xdf, 0xe8 }, F, N }, /* fucomip */
{ { 0xdf, 0xf0 }, F, N }, /* fcomip */
};
+
+#define VSIB(n) 0x04 | ((n) << 3), 0x38
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulator/predicates.c
@@ -517,6 +517,138 @@ static const struct {
};
#undef CND
#undef REG
+static const struct {
+uint8_t opc[2];
+bool modrm:1; /* Should register form (also) be tested? */
+
IOW just legacy encoded ones. For 3dNow! just one example is used, as
they're all similar in nature both encoding- and operand-wise.
Adjust a slightly misleading (but not wrong) memcpy() invocation, as
noticed while further cloning that code.
Rename pfx_none to pfx_no, so it can be used to
The combination of specifying a ModR/M byte with the upper two bits set
and the modrm field set to T is pointless - the same test will be
executed twice, i.e. overall things will be slower for no extra gain. I
can only assume this was a copy-and-paste-without-enough-editing mistake
of mine.
... and a few fixes resulting from this work. This completes what
was started for legacy encoded GPR insns in a rush before 4.14.
There's one thing I'm still planning on top of both this and the
EVEX-disp8 checking: For all encodings we produce via general
logic (and in particular without
flight 152408 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152408/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777
build-arm64-libvirt
On 31.07.2020 14:35, Jan Beulich wrote:
> On 31.07.2020 14:27, George Dunlap wrote:
>>> On Jul 31, 2020, at 1:25 PM, Jan Beulich wrote:
>>> On 30.07.2020 17:41, George Dunlap wrote:
> On Jul 30, 2020, at 4:17 PM, George Dunlap
> wrote:
>
> Hey all,
>
> The community call
From: Paul Durrant
Paul Durrant (4):
tools/hotplug: add remove_from_bridge() and improve debug output
tools/hotplug: combine add/online and remove/offline in vif-bridge...
public/io/netif: specify MTU override node
tools/hotplug: modify set_mtu() to inform the frontend via xenstore
From: Paul Durrant
set_mtu() currently sets the backend vif MTU but does not inform the frontend
what it is. This patch adds code to write the MTU into a xenstore node. See
netif.h for a specification of the node.
NOTE: There is also a small modification replacing '$mtu' with '${mtu}'
for
From: Paul Durrant
... as they are in vif-route.
The script is invoked with online/offline for vifs and add/remove for taps.
The operations that are necessary, however, are the same in both cases. This
patch therefore combines the cases.
The open-coded bridge removal code is also replaced with
From: Paul Durrant
There is currently no documentation to state what MTU a frontend should
adertise to its network stack. It has however long been assumed that the
default value of 1500 is correct.
This patch specifies a mechanism to allow the tools to set the MTU via a
xenstore node in the
From: Paul Durrant
This patch adds a remove_from_bridge() function into xen-network-common.sh
to partner with the existing add_to_bridge() function. The code in
add_to_bridge() is also slightly re-arranged to avoid duplication calls of
'ip link'.
Both add_to_bridge() and remove_from_bridge()
From: Paul Durrant
It's confusing and not consistent with the terminology introduced with 'dfn_t'.
Just call them IOMMU page tables.
Also remove a pointless check of the 'acpi_drhd_units' list in
vtd_dump_page_table_level(). If the list is empty then IOMMU mappings would
not have been enabled
From: Paul Durrant
Sharing of HAP tables is now VT-d specific so the operation is never defined
for AMD IOMMU any more. There's also no need to pro-actively set vtd.pgd_maddr
when using shared EPT as it is straightforward to simply define a helper
function to return the appropriate value in the
On 29.07.2020 00:16, Marek Marczykowski-Górecki wrote:
On Tue, Jul 28, 2020 at 10:01:33PM +0100, Andrew Cooper wrote:
On 28/07/2020 21:00, Jan Beulich wrote:
> On 28.07.2020 09:41, Norbert Kaminski wrote:
>> I'm trying to add support for the firmware updates with the UEFI
>> capsule in
>> Qubes
From: Paul Durrant
At the moment iommu_map() and iommu_unmap() take a page order but not a
count, whereas iommu_iotlb_flush() takes a count but not a page order.
This patch simply makes them consistent with each other.
Signed-off-by: Paul Durrant
---
Cc: Jun Nakajima
Cc: Kevin Tian
Cc: Jan
From: Paul Durrant
This patch adds a full I/O TLB flush to the error paths of iommu_map() and
iommu_unmap().
Without this change callers need constructs such as:
rc = iommu_map/unmap(...)
err = iommu_flush(...)
if ( !rc )
rc = err;
With this change, it can be simplified to:
rc =
From: Paul Durrant
Paul Durrant (11):
x86/iommu: re-arrange arch_iommu to separate common fields...
x86/iommu: add common page-table allocator
x86/iommu: convert VT-d code to use new page table allocator
x86/iommu: convert AMD IOMMU code to use new page table allocator
iommu: remove
From: Paul Durrant
The VT-d and AMD IOMMU both use the general x86 IOMMU page table allocator
and ARM always shares page tables with CPU. Hence there is no need to retain
the free_page_table() method or the tasklet which invokes it.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
v2:
- New
From: Paul Durrant
The 'legacy' functions do implicit flushing so amend the callers to do the
appropriate flushing.
Unfortunately, because of the structure of the P2M code, we cannot remove
the per-CPU 'iommu_dont_flush_iotlb' global and the optimization it
facilitates. It is now checked
From: Paul Durrant
This patch converts the VT-d code to use the new IOMMU page table allocator
function. This allows all the free-ing code to be removed (since it is now
handled by the general x86 code) which reduces TLB and cache thrashing as well
as shortening the code.
The scope of the
From: Paul Durrant
... from those specific to VT-d or AMD IOMMU, and put the latter in a union.
There is no functional change in this patch, although the initialization of
the 'mapped_rmrrs' list occurs slightly later in iommu_domain_init() since
it is now done (correctly) in VT-d specific code
From: Paul Durrant
This patch converts the AMD IOMMU code to use the new page table allocator
function. This allows all the free-ing code to be removed (since it is now
handled by the general x86 code) which reduces TLB and cache thrashing as well
as shortening the code.
Signed-off-by: Paul
From: Paul Durrant
This patch avoids calling iommu_iotlb_flush() for each individual GNTTABOP and
insteads calls iommu_iotlb_flush_all() at the end of the hypercall. This
should mean batched map/unmap operations perform better but may be slightly
detrimental to singleton performance.
From: Paul Durrant
Instead of having separate page table allocation functions in VT-d and AMD
IOMMU code, we could use a common allocation function in the general x86 code.
This patch adds a new allocation function, iommu_alloc_pgtable(), for this
purpose. The function adds the page table pages
flight 152389 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152389/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail pass in 152342
> -Original Message-
> From: Jürgen Groß
> Sent: 03 August 2020 06:09
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Durrant, Paul
> Subject: RE: [EXTERNAL] [PATCH 3/4] public/io/netif: specify MTU override node
>
> On 30.07.20 21:48, Paul Durrant wrote:
> > From: Paul
While this doesn't address the real problem I've run into (attempting to
update r/o source files), not recursing into tools/golang/xenlight/ is
enough to fix the build for me for the moment. I don't currently see why
60db5da62ac0 ("libxl: Generate golang bindings in libxl Makefile") found
it
flight 152380 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152380/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail REGR. vs. 151065
On 27.07.20 11:13, Roger Pau Monne wrote:
So it can be killed, or else processes can get hung indefinitely
waiting for balloon pages.
Signed-off-by: Roger Pau Monné
Reviewed-by: Juergen Gross
Cc: sta...@vger.kernel.org
Pushed to: xen/tip.git for-linus-5.9
Juergen
On 27.07.20 11:13, Roger Pau Monne wrote:
target_unpopulated is incremented with nr_pages at the start of the
function, but the call to free_xenballooned_pages will only subtract
pgno number of pages, and thus the rest need to be subtracted before
returning or else accounting will be skewed.
On 27.07.20 11:13, Roger Pau Monne wrote:
This reverts commit dfd74a1edfaba5864276a2859190a8d242d18952.
This has been fixed by commit dca4436d1cf9e0d237c which added the out
of bounds check to __add_memory, so that trying to add blocks past
MAX_PHYSMEM_BITS will fail.
Note the check in the Xen
71 matches
Mail list logo
